The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

iouring: fix memleak in ioinitwqoffload()

I got memory leak report when doing fuzz test:

BUG: memory leak unreferenced object 0xffff888107310a80 (size 96): comm "syz-executor.6", pid 4610, jiffies 4295140240 (age 20.135s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... backtrace: [<000000001974933b>] kmalloc include/linux/slab.h:591 [inline] [<000000001974933b>] kzalloc include/linux/slab.h:721 [inline] [<000000001974933b>] ioinitwqoffload fs/iouring.c:7920 [inline] [<000000001974933b>] iouringalloctaskcontext+0x466/0x640 fs/iouring.c:7955 [<0000000039d0800d>] _iouringaddtctxnode+0x256/0x360 fs/iouring.c:9016 [<000000008482e78c>] iouringaddtctxnode fs/iouring.c:9052 [inline] [<000000008482e78c>] _dosysiouringenter fs/iouring.c:9354 [inline] [<000000008482e78c>] _sesysiouringenter fs/iouring.c:9301 [inline] [<000000008482e78c>] _x64sysiouringenter+0xabc/0xc20 fs/iouring.c:9301 [<00000000b875f18f>] dosyscallx64 arch/x86/entry/common.c:50 [inline] [<00000000b875f18f>] dosyscall64+0x3b/0x90 arch/x86/entry/common.c:80 [<000000006b0a8484>] entrySYSCALL64afterhwframe+0x44/0xae

CPU0 CPU1 iouringenter iouringenter iouringaddtctxnode iouringaddtctxnode _iouringaddtctxnode _iouringaddtctxnode iouringalloctaskcontext iouringalloctaskcontext ioinitwqoffload ioinitwqoffload hash = kzalloc hash = kzalloc ctx->hashmap = hash ctx->hashmap = hash <- one of the hash is leaked

When calling iouringenter() in parallel, the 'hashmap' will be leaked, add uringlock to protect 'hash_map'.(CVE-2021-47292)

In the Linux kernel, the following vulnerability has been resolved:

iouring: ensure taskwork gets run as part of cancelations

If we successfully cancel a work item but that work item needs to be processed through taskwork, then we can be sleeping uninterruptibly in iouringcancelgeneric() and never process it. Hence we don't make forward progress and we end up with an uninterruptible sleep warning.

While in there, correct a comment that should be IFF, not IIF.(CVE-2021-47504)

In the Linux kernel, the following vulnerability has been resolved:

ethtool: ioctl: fix potential NULL deref in ethtoolsetcoalesce()

ethtoolsetcoalesce() now uses both the .getcoalesce() and .setcoalesce() callbacks. But the check for their availability is buggy, so changing the coalesce settings on a device where the driver provides only one of the callbacks results in a NULL pointer dereference instead of an -EOPNOTSUPP.

Fix the condition so that the availability of both callbacks is ensured. This also matches the netlink code.

Note that reproducing this requires some effort - it only affects the legacy ioctl path, and needs a specific combination of driver options: - have .getcoalesce() and .coalescesupported but no .setcoalesce(), or - have .setcoalesce() but no .getcoalesce(). Here eg. ethtool doesn't cause the crash as it first attempts to call ethtoolget_coalesce() and bails out on error.(CVE-2021-47556)

In the Linux kernel, the following vulnerability has been resolved:

drm/gma500: Fix BUG: sleeping function called from invalid context errors

gmacrtcpageflip() was holding the eventlock spinlock while calling crtcfuncs->modesetbase() which takes wwmutex.

The only reason to hold eventlock is to clear gmacrtc->pageflipevent on modesetbase() errors.

Instead unlock it after setting gmacrtc->pageflipevent and on errors re-take the lock and clear gmacrtc->pageflipevent it it is still set.

This fixes the following WARN/stacktrace:

[ 512.122953] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:870 [ 512.123004] inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 1253, name: gnome-shell [ 512.123031] preemptcount: 1, expected: 0 [ 512.123048] RCU nest depth: 0, expected: 0 [ 512.123066] INFO: lockdep is turned off. [ 512.123080] irq event stamp: 0 [ 512.123094] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 512.123134] hardirqs last disabled at (0): [<ffffffff8d0ec28c>] copyprocess+0x9fc/0x1de0 [ 512.123176] softirqs last enabled at (0): [<ffffffff8d0ec28c>] copyprocess+0x9fc/0x1de0 [ 512.123207] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 512.123233] Preemption disabled at: [ 512.123241] [<0000000000000000>] 0x0 [ 512.123275] CPU: 3 PID: 1253 Comm: gnome-shell Tainted: G W 5.19.0+ #1 [ 512.123304] Hardware name: Packard Bell dot s/SJE01CT, BIOS V1.10 07/23/2013 [ 512.123323] Call Trace: [ 512.123346] <TASK> [ 512.123370] dumpstacklvl+0x5b/0x77 [ 512.123412] _mightresched.cold+0xff/0x13a [ 512.123458] wwmutexlock+0x1e/0xa0 [ 512.123495] psbgempin+0x2c/0x150 [gma500gfx] [ 512.123601] gmapipesetbase+0x76/0x240 [gma500gfx] [ 512.123708] gmacrtcpageflip+0x95/0x130 [gma500gfx] [ 512.123808] drmmodepageflipioctl+0x57d/0x5d0 [ 512.123897] ? drmmodecursor2ioctl+0x10/0x10 [ 512.123936] drmioctlkernel+0xa1/0x150 [ 512.123984] drmioctl+0x21f/0x420 [ 512.124025] ? drmmodecursor2ioctl+0x10/0x10 [ 512.124070] ? rcureadlockbhheld+0xb/0x60 [ 512.124104] ? lockrelease+0x1ef/0x2d0 [ 512.124161] _x64sysioctl+0x8d/0xd0 [ 512.124203] dosyscall64+0x58/0x80 [ 512.124239] ? dosyscall64+0x67/0x80 [ 512.124267] ? tracehardirqsonprepare+0x55/0xe0 [ 512.124300] ? dosyscall64+0x67/0x80 [ 512.124340] ? rcureadlockschedheld+0x10/0x80 [ 512.124377] entrySYSCALL64afterhwframe+0x63/0xcd [ 512.124411] RIP: 0033:0x7fcc4a70740f [ 512.124442] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00 [ 512.124470] RSP: 002b:00007ffda73f5390 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 512.124503] RAX: ffffffffffffffda RBX: 000055cc9e474500 RCX: 00007fcc4a70740f [ 512.124524] RDX: 00007ffda73f5420 RSI: 00000000c01864b0 RDI: 0000000000000009 [ 512.124544] RBP: 00007ffda73f5420 R08: 000055cc9c0b0cb0 R09: 0000000000000034 [ 512.124564] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c01864b0 [ 512.124584] R13: 0000000000000009 R14: 000055cc9df484d0 R15: 000055cc9af5d0c0 [ 512.124647] </TASK>(CVE-2022-48634)

In the Linux kernel, the following vulnerability has been resolved:

net: sched: fix possible refcount leak in tcnewtfilter()

tfilterput need to be called to put the refount got by tp->ops->get to avoid possible refcount leak when chain->tmpltops != NULL and chain->tmplt_ops != tp->ops.(CVE-2022-48639)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nftables: fix percpu memory leak at nftables_addchain()

It seems to me that percpu memory for chain stats started leaking since commit 3bc158f8d0330f0a ("netfilter: nftables: map basechain priority to hardware priority") when nftchainoffloadpriority() returned an error.(CVE-2022-48642)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nftables: fix nftcountersenabled underflow at nftables_addchain()

syzbot is reporting underflow of nftcountersenabled counter at nftablesaddchain() [1], for commit 43eb8949cfdffa76 ("netfilter: nftables: do not leave chain stats enabled on error") missed that nftableschaindestroy() after nftbasechaininit() in the error path of nftablesaddchain() decrements the counter because nftbasechaininit() makes nftisbasechain() return true by setting NFTCHAIN_BASE flag.

Increment the counter immediately after returning from nftbasechaininit().(CVE-2022-48643)

In the Linux kernel, the following vulnerability has been resolved:

net/sched: taprio: avoid disabling offload when it was never enabled

In an incredibly strange API design decision, qdisc->destroy() gets called even if qdisc->init() never succeeded, not exclusively since commit 87b60cfacf9f ("netsched: fix error recovery at qdisc creation"), but apparently also earlier (in the case of qdisccreate_dflt()).

The taprio qdisc does not fully acknowledge this when it attempts full offload, because it starts off with q->flags = TAPRIOFLAGSINVALID in taprioinit(), then it replaces q->flags with TCATAPRIOATTRFLAGS parsed from netlink (in tapriochange(), tail called from taprioinit()).

But in tapriodestroy(), we call tapriodisableoffload(), and this determines what to do based on FULLOFFLOADISENABLED(q->flags).

But looking at the implementation of FULLOFFLOADISENABLED() (a bitwise check of bit 1 in q->flags), it is invalid to call this macro on q->flags when it contains TAPRIOFLAGSINVALID, because that is set to U32MAX, and therefore FULLOFFLOADIS_ENABLED() will return true on an invalid set of flags.

As a result, it is possible to crash the kernel if user space forces an error between setting q->flags = TAPRIOFLAGSINVALID, and the calling of taprioenableoffload(). This is because drivers do not expect the offload to be disabled when it was never enabled.

The error that we force here is to attach taprio as a non-root qdisc, but instead as child of an mqprio root qdisc:

$ tc qdisc add dev swp0 root handle 1: \ mqprio numtc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 $ tc qdisc replace dev swp0 parent 1:1 \ taprio numtc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \ sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \ flags 0x0 clockid CLOCKTAI Unable to handle kernel paging request at virtual address fffffffffffffff8 [fffffffffffffff8] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Call trace: tapriodump+0x27c/0x310 vsc9959portsetuptc+0x1f4/0x460 felixportsetuptc+0x24/0x3c dsaslavesetuptc+0x54/0x27c tapriodisableoffload.isra.0+0x58/0xe0 tapriodestroy+0x80/0x104 qdisccreate+0x240/0x470 tcmodifyqdisc+0x1fc/0x6b0 rtnetlinkrcvmsg+0x12c/0x390 netlinkrcvskb+0x5c/0x130 rtnetlinkrcv+0x1c/0x2c

Fix this by keeping track of the operations we made, and undo the offload only if we actually did it.

I've added "bool offloaded" inside a 4 byte hole between "int clockid" and "atomic64t picosper_byte". Now the first cache line looks like below:

$ pahole -C tapriosched net/sched/schtaprio.o struct tapriosched { struct Qdisc * * qdiscs; /* 0 8 */ struct Qdisc * root; /* 8 8 */ u32 flags; /* 16 4 */ enum tkoffsets tk_offset; /* 20 4 / int clockid; / 24 4 / bool offloaded; / 28 1 */

    /* XXX 3 bytes hole, try to pack */

    atomic64_t                 picos_per_byte;       /*    32     0 */

    /* XXX 8 bytes hole, try to pack */

    spinlock_t                 current_entry_lock;   /*    40     0 */

    /* XXX 8 bytes hole, try to pack */

    struct sched_entry *       current_entry;        /*    48     8 */
    struct sched_gate_list *   oper_sched;           /*    56     8 */
    /* --- cacheline 1 boundary (64 bytes) --- */(CVE-2022-48644)

In the Linux kernel, the following vulnerability has been resolved:

sfc: fix TX channel offset when using legacy interrupts

In legacy interrupt mode the txchanneloffset was hardcoded to 1, but that's not correct if efxsepparatetx_channels is false. In that case, the offset is 0 because the tx queues are in the single existing channel at index 0, together with the rx queue.

Without this fix, as soon as you try to send any traffic, it tries to get the tx queues from an uninitialized channel getting these errors: WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efxhardstartxmit+0x12e/0x170 [sfc] [...] RIP: 0010:efxhardstartxmit+0x12e/0x170 [sfc] [...] Call Trace: <IRQ> devhardstartxmit+0xd7/0x230 schdirectxmit+0x9f/0x360 _devqueuexmit+0x890/0xa40 [...] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efxhardstartxmit+0x153/0x170 [sfc] [...] Call Trace: <IRQ> devhardstartxmit+0xd7/0x230 schdirectxmit+0x9f/0x360 _devqueue_xmit+0x890/0xa40 ...

In the Linux kernel, the following vulnerability has been resolved:

sfc: fix null pointer dereference in efxhardstart_xmit

Trying to get the channel from the txqueue variable here is wrong because we can only be here if txqueue is NULL, so we shouldn't dereference it. As the above comment in the code says, this is very unlikely to happen, but it's wrong anyway so let's fix it.

I hit this issue because of a different bug that caused txqueue to be NULL. If that happens, this is the error message that we get here: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efxhardstartxmit+0x153/0x170 sfc

In the Linux kernel, the following vulnerability has been resolved:

dmaengine: ti: k3-udma-private: Fix refcount leak bug in ofxudmadev_get()

We should call ofnodeput() for the reference returned by ofparsephandle() in fail path or when it is not used anymore. Here we only need to move the ofnodeput() before the check.(CVE-2022-48656)

In the Linux kernel, the following vulnerability has been resolved:

gpio: mockup: fix NULL pointer dereference when removing debugfs

We now remove the device's debugfs entries when unbinding the driver. This now causes a NULL-pointer dereference on module exit because the platform devices are unregistered after the global debugfs directory has been recursively removed. Fix it by unregistering the devices first.(CVE-2022-48663)

In the Linux kernel, the following vulnerability has been resolved:

cgroup: Add missing cpusreadlock() to cgroupattachtask_all()

syzbot is hitting percpurwsemassertheld(&cpuhotpluglock) warning at cpusetattach() [1], for commit 4f7e7236435ca0ab ("cgroup: Fix threadgrouprwsem <-> cpusreadlock() deadlock") missed that cpusetattach() is also called from cgroupattachtaskall(). Add cpusreadlock() like what cgroupprocswritestart() does.(CVE-2022-48671)

In the Linux kernel, the following vulnerability has been resolved:

of: fdt: fix off-by-one error in unflattendtnodes()

Commit 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree") forgot to fix up the depth check in the loop body in unflattendtnodes() which makes it possible to overflow the nps[] buffer...

Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.(CVE-2022-48672)

In the Linux kernel, the following vulnerability has been resolved:

IB/core: Fix a nested dead lock as part of ODP flow

Fix a nested dead lock as part of ODP flow by using mmput_async().

From the below call trace [1] can see that calling mmput() once we have the umemodp->umemmutex locked as required by ibumemodpmapdmaandlock() might trigger in the same task the exitmmap()->mmunotifierrelease()->mlx5ibinvalidaterange() which may dead lock when trying to lock the same mutex.

Moving to use mmputasync() will solve the problem as the above exitmmap() flow will be called in other task and will be executed once the lock will be available.

[1] [64843.077665] task:kworker/u133:2 state:D stack: 0 pid:80906 ppid: 2 flags:0x00004000 [64843.077672] Workqueue: mlx5ibpagefault mlx5ibeqepfaction [mlx5ib] [64843.077719] Call Trace: [64843.077722] <TASK> [64843.077724] _schedule+0x23d/0x590 [64843.077729] schedule+0x4e/0xb0 [64843.077735] schedulepreemptdisabled+0xe/0x10 [64843.077740] _mutexlock.constprop.0+0x263/0x490 [64843.077747] _mutexlockslowpath+0x13/0x20 [64843.077752] mutexlock+0x34/0x40 [64843.077758] mlx5ibinvalidaterange+0x48/0x270 [mlx5ib] [64843.077808] _mmunotifierrelease+0x1a4/0x200 [64843.077816] exitmmap+0x1bc/0x200 [64843.077822] ? walkpagerange+0x9c/0x120 [64843.077828] ? _condresched+0x1a/0x50 [64843.077833] ? mutexlock+0x13/0x40 [64843.077839] ? uprobeclearstate+0xac/0x120 [64843.077860] mmput+0x5f/0x140 [64843.077867] ibumemodpmapdmaandlock+0x21b/0x580 [ibcore] [64843.077931] pagefaultrealmr+0x9a/0x140 [mlx5ib] [64843.077962] pagefaultmr+0xb4/0x550 [mlx5ib] [64843.077992] pagefaultsingledatasegment.constprop.0+0x2ac/0x560 [mlx5ib] [64843.078022] mlx5ibeqepfaction+0x528/0x780 [mlx5ib] [64843.078051] processonework+0x22b/0x3d0 [64843.078059] workerthread+0x53/0x410 [64843.078065] ? processonework+0x3d0/0x3d0 [64843.078073] kthread+0x12a/0x150 [64843.078079] ? setkthreadstruct+0x50/0x50 [64843.078085] retfromfork+0x22/0x30 [64843.078093] </TASK>(CVE-2022-48675)

In the Linux kernel, the following vulnerability has been resolved:

nvme-tcp: fix UAF when detecting digest errors

We should also bail from the iowork loop when we set rdenabled to true, so we don't attempt to read data from the socket when the TCP stream is already out-of-sync or corrupted.(CVE-2022-48686)

In the Linux kernel, the following vulnerability has been resolved:

ipv6: sr: fix out-of-bounds read when setting HMAC data.

The SRv6 layer allows defining HMAC data that can later be used to sign IPv6 Segment Routing Headers. This configuration is realised via netlink through four attributes: SEG6ATTRHMACKEYID, SEG6ATTRSECRET, SEG6ATTRSECRETLEN and SEG6ATTRALGID. Because the SECRETLEN attribute is decoupled from the actual length of the SECRET attribute, it is possible to provide invalid combinations (e.g., secret = "", secretlen = 64). This case is not checked in the code and with an appropriately crafted netlink message, an out-of-bounds read of up to 64 bytes (max secret length) can occur past the skb end pointer and into skbsharedinfo:

Breakpoint 1, seg6genlsethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208 208 memcpy(hinfo->secret, secret, slen); (gdb) bt #0 seg6genlsethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208 #1 0xffffffff81e012e9 in genlfamilyrcvmsgdoit (skb=skb@entry=0xffff88800b1f9f00, nlh=nlh@entry=0xffff88800b1b7600, extack=extack@entry=0xffffc90000ba7af0, ops=ops@entry=0xffffc90000ba7a80, hdrlen=4, net=0xffffffff84237580 <initnet>, family=<optimized out>, family=<optimized out>) at net/netlink/genetlink.c:731 #2 0xffffffff81e01435 in genlfamilyrcvmsg (extack=0xffffc90000ba7af0, nlh=0xffff88800b1b7600, skb=0xffff88800b1f9f00, family=0xffffffff82fef6c0 <seg6genlfamily>) at net/netlink/genetlink.c:775 #3 genlrcvmsg (skb=0xffff88800b1f9f00, nlh=0xffff88800b1b7600, extack=0xffffc90000ba7af0) at net/netlink/genetlink.c:792 #4 0xffffffff81dfffc3 in netlinkrcvskb (skb=skb@entry=0xffff88800b1f9f00, cb=cb@entry=0xffffffff81e01350 <genlrcvmsg>) at net/netlink/afnetlink.c:2501 #5 0xffffffff81e00919 in genlrcv (skb=0xffff88800b1f9f00) at net/netlink/genetlink.c:803 #6 0xffffffff81dff6ae in netlinkunicastkernel (ssk=0xffff888010eec800, skb=0xffff88800b1f9f00, sk=0xffff888004aed000) at net/netlink/afnetlink.c:1319 #7 netlinkunicast (ssk=ssk@entry=0xffff888010eec800, skb=skb@entry=0xffff88800b1f9f00, portid=portid@entry=0, nonblock=<optimized out>) at net/netlink/afnetlink.c:1345 #8 0xffffffff81dff9a4 in netlinksendmsg (sock=<optimized out>, msg=0xffffc90000ba7e48, len=<optimized out>) at net/netlink/afnetlink.c:1921 ... (gdb) p/x ((struct skbuff *)0xffff88800b1f9f00)->head + ((struct sk_buff *)0xffff88800b1f9f00)->end $1 = 0xffff88800b1b76c0 (gdb) p/x secret $2 = 0xffff88800b1b76c0 (gdb) p slen $3 = 64 '@'

The OOB data can then be read back from userspace by dumping HMAC state. This commit fixes this by ensuring SECRETLEN cannot exceed the actual length of SECRET.(CVE-2022-48687)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: clean up hook list when offload flags check fails

splice back the hook list so nftchainrelease_hook() has a chance to release the hooks.

BUG: memory leak unreferenced object 0xffff88810180b100 (size 96): comm "syz-executor133", pid 3619, jiffies 4294945714 (age 12.690s) hex dump (first 32 bytes): 28 64 23 02 81 88 ff ff 28 64 23 02 81 88 ff ff (d#.....(d#..... 90 a8 aa 83 ff ff ff ff 00 00 b5 0f 81 88 ff ff ................ backtrace: [<ffffffff83a8c59b>] kmalloc include/linux/slab.h:600 [inline] [<ffffffff83a8c59b>] nftnetdevhookalloc+0x3b/0xc0 net/netfilter/nftablesapi.c:1901 [<ffffffff83a9239a>] nftchainparsenetdev net/netfilter/nftablesapi.c:1998 [inline] [<ffffffff83a9239a>] nftchainparsehook+0x33a/0x530 net/netfilter/nftablesapi.c:2073 [<ffffffff83a9b14b>] nftablesaddchain.constprop.0+0x10b/0x950 net/netfilter/nftablesapi.c:2218 [<ffffffff83a9c41b>] nftablesnewchain+0xa8b/0xc60 net/netfilter/nftablesapi.c:2593 [<ffffffff83a3d6a6>] nfnetlinkrcvbatch+0xa46/0xd20 net/netfilter/nfnetlink.c:517 [<ffffffff83a3db79>] nfnetlinkrcvskbbatch net/netfilter/nfnetlink.c:638 [inline] [<ffffffff83a3db79>] nfnetlinkrcv+0x1f9/0x220 net/netfilter/nfnetlink.c:656 [<ffffffff83a13b17>] netlinkunicastkernel net/netlink/afnetlink.c:1319 [inline] [<ffffffff83a13b17>] netlinkunicast+0x397/0x4c0 net/netlink/afnetlink.c:1345 [<ffffffff83a13fd6>] netlinksendmsg+0x396/0x710 net/netlink/afnetlink.c:1921 [<ffffffff83865ab6>] socksendmsgnosec net/socket.c:714 [inline] [<ffffffff83865ab6>] socksendmsg+0x56/0x80 net/socket.c:734 [<ffffffff8386601c>] syssendmsg+0x36c/0x390 net/socket.c:2482 [<ffffffff8386a918>] syssendmsg+0xa8/0x110 net/socket.c:2536 [<ffffffff8386aaa8>] _syssendmsg+0x88/0x100 net/socket.c:2565 [<ffffffff845e5955>] dosyscallx64 arch/x86/entry/common.c:50 [inline] [<ffffffff845e5955>] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] entrySYSCALL64afterhwframe+0x63/0xcd(CVE-2022-48691)

In the Linux kernel, the following vulnerability has been resolved:

misc: fastrpc: Don't remove map on createrprocess and devicerelease

Do not remove the map from the list on error path in fastrpcinitcreateprocess, instead call fastrpcmapput, to avoid use-after-free. Do not remove it on fastrpcdevicerelease either, call fastrpcmap_put instead.

The fastrpcfreemap is the only proper place to remove the map. This is called only after the reference count is 0.(CVE-2022-48873)

In the Linux kernel, the following vulnerability has been resolved:

ixgbe: fix pci device refcount leak

As the comment of pcigetdomainbusandslot() says, it returns a PCI device with refcount incremented, when finish using it, the caller must decrement the reference count by calling pcidev_put().

In ixgbegetfirstsecondarydevfn() and ixgbex550emahasmii(), pcidevput() is called to avoid leak.(CVE-2022-48896)

In the Linux kernel, the following vulnerability has been resolved:

drm/msm/dp: do not complete dpauxcmdfifotx() if irq is not for aux transfer

There are 3 possible interrupt sources are handled by DP controller, HPDstatus, Controller state changes and Aux read/write transaction. At every irq, DP controller have to check isr status of every interrupt sources and service the interrupt if its isr status bits shows interrupts are pending. There is potential race condition may happen at current aux isr handler implementation since it is always complete dpauxcmdfifotx() even irq is not for aux read or write transaction. This may cause aux read transaction return premature if host aux data read is in the middle of waiting for sink to complete transferring data to host while irq happen. This will cause host's receiving buffer contains unexpected data. This patch fixes this problem by checking aux isr and return immediately at aux isr handler if there are no any isr status bits set.

Current there is a bug report regrading eDP edid corruption happen during system booting up. After lengthy debugging to found that VIDEOREADY interrupt was continuously firing during system booting up which cause dpauxisr() to complete dpauxcmdfifo_tx() prematurely to retrieve data from aux hardware buffer which is not yet contains complete data transfer from sink. This cause edid corruption.

Follows are the signature at kernel logs when problem happen, EDID has corrupt header panel-simple-dp-aux aux-aea0000.edp: Couldn't identify panel via EDID

Changes in v2: -- do complete if (ret == IRQHANDLED) ay dp-auxisr() -- add more commit text

Changes in v3: -- add Stephen suggested -- dpauxisr() return IRQXXX back to caller -- dpctrlisr() return IRQXXX back to caller

Changes in v4: -- split into two patches

Changes in v5: -- delete empty line between tags

Changes in v6: -- remove extra "that" and fixed line more than 75 char at commit text

Patchwork: https://patchwork.freedesktop.org/patch/516121/(CVE-2022-48898)

In the Linux kernel, the following vulnerability has been resolved:

drm/virtio: Fix GEM handle creation UAF

Userspace can guess the handle value and try to race GEM object creation with handle close, resulting in a use-after-free if we dereference the object after dropping the handle's reference. For that reason, dropping the handle's reference must be done after we are done dereferencing the object.(CVE-2022-48899)

In the Linux kernel, the following vulnerability has been resolved:

btrfs: get rid of warning on transaction commit when using flushoncommit

When using the flushoncommit mount option, during almost every transaction commit we trigger a warning from _writebackinodessbnr():

$ cat fs/fs-writeback.c: (...) static void _writebackinodessbnr(struct superblock *sb, ... { (...) WARNON(!rwsemislocked(&sb->s_umount)); (...) } (...)

The trace produced in dmesg looks like the following:

[947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 writebackinodessbnr+0x7e/0xb3 [947.481623] Modules linked in: nfsd nlscp437 cifs asn1decoder cifsarc4 fscache cifsmd4 ipmissif [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186 [947.497969] RIP: 0010:writebackinodessbnr+0x7e/0xb3 [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...) [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246 [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000 [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50 [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000 [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488 [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460 [947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000 [947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0 [947.571072] Call Trace: [947.572354] <TASK> [947.573266] btrfscommittransaction+0x1f1/0x998 [947.576785] ? starttransaction+0x3ab/0x44e [947.579867] ? scheduletimeout+0x8a/0xdd [947.582716] transactionkthread+0xe9/0x156 [947.585721] ? btrfscleanuptransaction.isra.0+0x407/0x407 [947.590104] kthread+0x131/0x139 [947.592168] ? setkthreadstruct+0x32/0x32 [947.595174] retfromfork+0x22/0x30 [947.597561] </TASK> [947.598553] ---[ end trace 644721052755541c ]---

This is because we started using writebackinodessb() to flush delalloc when committing a transaction (when using -o flushoncommit), in order to avoid deadlocks with filesystem freeze operations. This change was made by commit ce8ea7cc6eb313 ("btrfs: don't call btrfsstartdelalloc_roots in flushoncommit"). After that change we started producing that warning, and every now and then a user reports this since the warning happens too often, it spams dmesg/syslog, and a user is unsure if this reflects any problem that might compromise the filesystem's reliability.

We can not just lock the sb->sumount semaphore before calling writebackinodessb(), because that would at least deadlock with filesystem freezing, since at fs/super.c:freezesuper() sync_filesystem() is called while we are holding that semaphore in write mode, and that can trigger a transaction commit, resulting in a deadlock. It would also trigger the same type of deadlock in the unmount path. Possibly, it could also introduce some other locking dependencies that lockdep would report.

To fix this call trytowritebackinodessb() instead of writebackinodessb(), because that will try to read lock sb->sumount and then will only call writebackinodessb() if it was able to lock it. This is fine because the cases where it can't read lock sb->sumount are during a filesystem unmount or during a filesystem freeze - in those cases sb->sumount is write locked and syncfilesystem() is called, which calls writebackinodessb(). In other words, in all cases where we can't take a read lock on sb->s_umount, writeback is already being triggered elsewhere.

An alternative would be to call btrfsstartdelallocroots() with a number of pages different from LONGMAX, for example matching the number of delalloc bytes we currently have, in ---truncated---(CVE-2022-48920)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: unregister flowtable hooks on netns exit

Unregister flowtable hooks before they are releases via nftablesflowtable_destroy() otherwise hook core reports UAF.

BUG: KASAN: use-after-free in nfhookentries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142 Read of size 4 at addr ffff8880736f7438 by task syz-executor579/3666

CPU: 0 PID: 3666 Comm: syz-executor579 Not tainted 5.16.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] _dumpstack lib/dumpstack.c:88 [inline] lib/dumpstack.c:106 dumpstacklvl+0x1dc/0x2d8 lib/dumpstack.c:106 lib/dumpstack.c:106 printaddressdescription+0x65/0x380 mm/kasan/report.c:247 mm/kasan/report.c:247 _kasanreport mm/kasan/report.c:433 [inline] _kasanreport mm/kasan/report.c:433 [inline] mm/kasan/report.c:450 kasanreport+0x19a/0x1f0 mm/kasan/report.c:450 mm/kasan/report.c:450 nfhookentriesgrow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142 _nfregisternethook+0x27e/0x8d0 net/netfilter/core.c:429 net/netfilter/core.c:429 nfregisternethook+0xaa/0x180 net/netfilter/core.c:571 net/netfilter/core.c:571 nftregisterflowtablenethooks+0x3c5/0x730 net/netfilter/nftablesapi.c:7232 net/netfilter/nftablesapi.c:7232 nftablesnewflowtable+0x2022/0x2cf0 net/netfilter/nftablesapi.c:7430 net/netfilter/nftablesapi.c:7430 nfnetlinkrcvbatch net/netfilter/nfnetlink.c:513 [inline] nfnetlinkrcvskbbatch net/netfilter/nfnetlink.c:634 [inline] nfnetlinkrcvbatch net/netfilter/nfnetlink.c:513 [inline] net/netfilter/nfnetlink.c:652 nfnetlinkrcvskbbatch net/netfilter/nfnetlink.c:634 [inline] net/netfilter/nfnetlink.c:652 nfnetlink_rcv+0x10e6/0x2550 net/netfilter/nfnetlink.c:652 net/netfilter/nfnetlink.c:652

_nftreleasehook() calls nftunregisterflowtablenethooks() which only unregisters the hooks, then after RCU grace period, it is guaranteed that no packets add new entries to the flowtable (no flow offload rules and flowtable hooks are reachable from packet path), so it is safe to call nfflowtablefree() which cleans up the remaining entries from the flowtable (both software and hardware) and it unbinds the flow_block.(CVE-2022-48935)

In the Linux kernel, the following vulnerability has been resolved:

gsmi: fix null-deref in gsmigetvariable

We can get EFI variables without fetching the attribute, so we must allow for that in gsmi.

commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore access layer") added a new get_variable call with attr=NULL, which triggers panic in gsmi.(CVE-2023-52893)

In the Linux kernel, the following vulnerability has been resolved:

xhci: Fix null pointer dereference when host dies

Make sure xhcifreedev() and xhcikillendpoint_urbs() do not race and cause null pointer dereference when host suddenly dies.

Usb core may call xhcifreedev() which frees the xhci->devs[slotid] virt device at the same time that xhcikillendpointurbs() tries to loop through all the device's endpoints, checking if there are any cancelled urbs left to give back.

hold the xhci spinlock while freeing the virt device(CVE-2023-52898)

In the Linux kernel, the following vulnerability has been resolved:

usb: xhci: Check endpoint is valid before dereferencing it

When the host controller is not responding, all URBs queued to all endpoints need to be killed. This can cause a kernel panic if we dereference an invalid endpoint.

Fix this by using xhcigetvirt_ep() helper to find the endpoint and checking if the endpoint is valid before dereferencing it.

[233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead [233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8

[233311.853964] pc : xhcihcdied+0x10c/0x270 [233311.853971] lr : xhcihcdied+0x1ac/0x270

[233311.854077] Call trace: [233311.854085] xhcihcdied+0x10c/0x270 [233311.854093] xhcistopendpointcommandwatchdog+0x100/0x1a4 [233311.854105] calltimerfn+0x50/0x2d4 [233311.854112] expiretimers+0xac/0x2e4 [233311.854118] runtimersoftirq+0x300/0xabc [233311.854127] _dosoftirq+0x148/0x528 [233311.854135] irqexit+0x194/0x1a8 [233311.854143] _handledomainirq+0x164/0x1d0 [233311.854149] gichandleirq.22273+0x10c/0x188 [233311.854156] el1irq+0xfc/0x1a8 [233311.854175] lpmcpuidleenter+0x25c/0x418 [msmpm] [233311.854185] cpuidleenterstate+0x1f0/0x764 [233311.854194] doidle+0x594/0x6ac [233311.854201] cpustartupentry+0x7c/0x80 [233311.854209] secondarystartkernel+0x170/0x198(CVE-2023-52901)

In the Linux kernel, the following vulnerability has been resolved:

io_uring: lock overflowing for IOPOLL

syzbot reports an issue with overflow filling for IOPOLL:

WARNING: CPU: 0 PID: 28 at iouring/iouring.c:734 iocqringeventoverflow+0x1c0/0x230 iouring/iouring.c:734 CPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0 Workqueue: eventsunbound ioringexitwork Call trace:  iocqringeventoverflow+0x1c0/0x230 iouring/iouring.c:734  ioreqcqeoverflow+0x5c/0x70 iouring/iouring.c:773  iofillcqereq iouring/iouring.h:168 [inline]  iodoiopoll+0x474/0x62c iouring/rw.c:1065  ioiopolltryreapevents+0x6c/0x108 iouring/iouring.c:1513  iouringtrycancelrequests+0x13c/0x258 iouring/iouring.c:3056  ioringexitwork+0xec/0x390 iouring/iouring.c:2869  processonework+0x2d8/0x504 kernel/workqueue.c:2289  workerthread+0x340/0x610 kernel/workqueue.c:2436  kthread+0x12c/0x158 kernel/kthread.c:376  retfrom_fork+0x10/0x20 arch/arm64/kernel/entry.S:863

There is no real problem for normal IOPOLL as flush is also called with uringlock taken, but it's getting more complicated for IOPOLL|SQPOLL, for which _iocqringoverflow_flush() happens from the CQ waiting path.(CVE-2023-52903)

A race condition was found in the Linux kernel's drm/exynos device driver in exynosdrmcrtcatomicdisable() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.

(CVE-2024-22386)

In the Linux kernel, the following vulnerability has been resolved:

phonet: fix rtmphonetnotify() skb allocation

fill_route() stores three components in the skb:

• struct rtmsg
• RTA_DST (u8)
• RTA_OIF (u32)

Therefore, rtmphonetnotify() should use

NLMSGALIGN(sizeof(struct rtmsg)) + nlatotalsize(1) + nlatotal_size(4)(CVE-2024-36946)

In the Linux kernel, the following vulnerability has been resolved:

m68k: Fix spinlock race in kernel thread creation

Context switching does take care to retain the correct lock owner across the switch from 'prev' to 'next' tasks. This does rely on interrupts remaining disabled for the entire duration of the switch.

This condition is guaranteed for normal process creation and context switching between already running processes, because both 'prev' and 'next' already have interrupts disabled in their saved copies of the status register.

The situation is different for newly created kernel threads. The status register is set to PSS in copythread(), which does leave the IPL at 0. Upon restoring the 'next' thread's status register in switchto() aka resume(), interrupts then become enabled prematurely. resume() then returns via retfromkernelthread() and scheduletail() where run queue lock is released (see finishtaskswitch() and finishlock_switch()).

A timer interrupt calling schedulertick() before the lock is released in finishtask_switch() will find the lock already taken, with the current task as lock owner. This causes a spinlock recursion warning as reported by Guenter Roeck.

As far as I can ascertain, this race has been opened in commit 533e6903bea0 ("m68k: split retfromfork(), simplify kernel_thread()") but I haven't done a detailed study of kernel history so it may well predate that commit.

Interrupts cannot be disabled in the saved status register copy for kernel threads (init will complain about interrupts disabled when finally starting user space). Disable interrupts temporarily when switching the tasks' register sets in resume().

Note that a simple oriw 0x700,%sr after restoring sr is not enough here - this leaves enough of a race for the 'spinlock recursion' warning to still be observed.

Tested on ARAnyM and qemu (Quadra 800 emulation).(CVE-2024-38613)

In the Linux kernel, the following vulnerability has been resolved:

ipv6: sr: fix missing skbuff release in seg6input_core

The seg6input() function is responsible for adding the SRH into a packet, delegating the operation to the seg6inputcore(). This function uses the skbcowhead() to ensure that there is sufficient headroom in the skbuff for accommodating the link-layer header. In the event that the skbcowheader() function fails, the seg6inputcore() catches the error but it does not release the sk_buff, which will result in a memory leak.

This issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG due to headroom too small after SRH push") and persists even after commit 7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"), where the entire seg6_input() code was refactored to deal with netfilter hooks.

The proposed patch addresses the identified memory leak by requiring the seg6inputcore() function to release the skbuff in the event that skbcow_head() fails.(CVE-2024-39490)

In the Linux kernel, the following vulnerability has been resolved:

crypto: hisilicon/sec - Fix memory leak for sec resource release

The AIV is one of the SEC resources. When releasing resources, it need to release the AIV resources at the same time. Otherwise, memory leakage occurs.

The aiv resource release is added to the sec resource release function.(CVE-2024-41002)

In the Linux kernel, the following vulnerability has been resolved:

s390/sclp: Fix sclp_init() cleanup on failure

If sclpinit() fails it only partially cleans up: if there are multiple failing calls to sclpinit() sclpstatechangeevent will be added several times to sclpreg_list, which results in the following warning:

------------[ cut here ]------------ listadd double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10. WARNING: CPU: 0 PID: 1 at lib/listdebug.c:35 listaddvalidorreport+0xde/0xf8 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3 Krnl PSW : 0404c00180000000 000003ffe0d6076a (listaddvalidorreport+0xe2/0xf8) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 ... Call Trace: [<000003ffe0d6076a>] _listaddvalidorreport+0xe2/0xf8 ([<000003ffe0d60766>] _listaddvalidorreport+0xde/0xf8) [<000003ffe0a8d37e>] sclpinit+0x40e/0x450 [<000003ffe00009f2>] dooneinitcall+0x42/0x1e0 [<000003ffe15b77a6>] doinitcalls+0x126/0x150 [<000003ffe15b7a0a>] kernelinitfreeable+0x1ba/0x1f8 [<000003ffe0d6650e>] kernelinit+0x2e/0x180 [<000003ffe000301c>] _retfromfork+0x3c/0x60 [<000003ffe0d759ca>] retfromfork+0xa/0x30

Fix this by removing sclpstatechangeevent from sclpreglist when sclpinit() fails.(CVE-2024-41068)

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check pipe offset before setting vblank

pipectx has a size of MAXPIPES so checking its index before accessing the array.

This fixes an OVERRUN issue reported by Coverity.(CVE-2024-42120)

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add NULL pointer check for kzalloc

[Why & How] Check return pointer of kzalloc before using it.(CVE-2024-42122)

In the Linux kernel, the following vulnerability has been resolved:

protect the fetch of ->fd[fd] in do_dup2() from mispredictions

both callers have verified that fd is not greater than ->maxfds; however, misprediction might end up with tofree = fdt->fd[fd]; being speculatively executed. That's wrong for the same reasons why it's wrong in closefd()/fileclosefdlocked(); the same solution applies - arrayindexnospec(fd, fdt->maxfds) could differ from fd only in case of speculative execution on mispredicted path.(CVE-2024-42265)

In the Linux kernel, the following vulnerability has been resolved:

net/iucv: fix use after free in iucvsockclose()

iucvseverpath() is called from process context and from bh context. iucv->path is used as indicator whether somebody else is taking care of severing the path (or it is already removed / never existed). This needs to be done with atomic compare and swap, otherwise there is a small window where iucvsockclose() will try to work with a path that has already been severed and freed by iucvcallbackconnrej() called by iucvtaskletfn().

Example: [452744.123844] Call Trace: [452744.123845] ([<0000001e87f03880>] 0x1e87f03880) [452744.123966] [<00000000d593001e>] iucvpathsever+0x96/0x138 [452744.124330] [<000003ff801ddbca>] iucvseverpath+0xc2/0xd0 [afiucv] [452744.124336] [<000003ff801e01b6>] iucvsockclose+0xa6/0x310 [afiucv] [452744.124341] [<000003ff801e08cc>] iucvsockrelease+0x3c/0xd0 [afiucv] [452744.124345] [<00000000d574794e>] _sockrelease+0x5e/0xe8 [452744.124815] [<00000000d5747a0c>] sockclose+0x34/0x48 [452744.124820] [<00000000d5421642>] _fput+0xba/0x268 [452744.124826] [<00000000d51b382c>] taskworkrun+0xbc/0xf0 [452744.124832] [<00000000d5145710>] donotifyresume+0x88/0x90 [452744.124841] [<00000000d5978096>] systemcall+0xe2/0x2c8 [452744.125319] Last Breaking-Event-Address: [452744.125321] [<00000000d5930018>] iucvpathsever+0x90/0x138 [452744.125324] [452744.125325] Kernel panic - not syncing: Fatal exception in interrupt

Note that bhlocksock() is not serializing the tasklet context against process context, because the check for sockownedby_user() and corresponding handling is missing.

Ideas for a future clean-up patch: A) Correct usage of bhlocksock() in tasklet context, as described in Re-enqueue, if needed. This may require adding return values to the tasklet functions and thus changes to all users of iucv.

B) Change iucv tasklet into worker and use only locksock() in afiucv.(CVE-2024-42271)

In the Linux kernel, the following vulnerability has been resolved:

mISDN: Fix a use after free in hfcmulti_tx()

Don't dereference sp after calling dev_kfree_skb(sp).(CVE-2024-42280)

In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix a segment issue when downgrading gso_size

Linearize the skb when downgrading gsosize because it may trigger a BUGON() later when the skb is segmented as described in [1,2].(CVE-2024-42281)

In the Linux kernel, the following vulnerability has been resolved:

tipc: Return non-zero value from tipcudpaddr2str() on error

tipcudpaddr2str() should return non-zero value if the UDP media address is invalid. Otherwise, a buffer overflow access can occur in tipcmediaaddr_printf(). Fix this by returning 1 on an invalid UDP media address.(CVE-2024-42284)

In the Linux kernel, the following vulnerability has been resolved:

RDMA/iwcm: Fix a use-after-free related to destroying CM IDs

iwconnreqhandler() associates a new struct rdmaidprivate (connid) with an existing struct iwcmid (cm_id) as follows:

    conn_id->cm_id.iw = cm_id;
    cm_id->context = conn_id;
    cm_id->cm_handler = cma_iw_handler;

rdmadestroyid() frees both the cmid and the struct rdmaidprivate. Make sure that cmworkhandler() does not trigger a use-after-free by only freeing of the struct rdmaid_private after all pending work has finished.(CVE-2024-42285)

In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to don't dirty inode for readonly filesystem

syzbot reports f2fs bug as below:

kernel BUG at fs/f2fs/inode.c:933! RIP: 0010:f2fsevictinode+0x1576/0x1590 fs/f2fs/inode.c:933 Call Trace: evict+0x2a4/0x620 fs/inode.c:664 disposelist fs/inode.c:697 [inline] evictinodes+0x5f8/0x690 fs/inode.c:747 genericshutdownsuper+0x9d/0x2c0 fs/super.c:675 killblocksuper+0x44/0x90 fs/super.c:1667 killf2fssuper+0x303/0x3b0 fs/f2fs/super.c:4894 deactivatelockedsuper+0xc1/0x130 fs/super.c:484 cleanupmnt+0x426/0x4c0 fs/namespace.c:1256 taskworkrun+0x24a/0x300 kernel/taskwork.c:180 ptracenotify+0x2cd/0x380 kernel/signal.c:2399 ptracereportsyscall include/linux/ptrace.h:411 [inline] ptracereportsyscallexit include/linux/ptrace.h:473 [inline] syscallexitwork kernel/entry/common.c:251 [inline] syscallexittousermodeprepare kernel/entry/common.c:278 [inline] _syscallexittousermodework kernel/entry/common.c:283 [inline] syscallexittousermode+0x15c/0x280 kernel/entry/common.c:296 dosyscall64+0x50/0x110 arch/x86/entry/common.c:88 entrySYSCALL64after_hwframe+0x63/0x6b

The root cause is: - dosysopen - f2fslookup - _f2fsfindentry - f2fsidepthwrite - f2fsmarkinodedirtysync - f2fsdirtyinode - setinodeflag(inode, FIDIRTY_INODE)

• umount
  • killf2fssuper
    • killblocksuper
      • genericshutdownsuper
        • syncfilesystem : sb is readonly, skip syncfilesystem()
        • evictinodes
          • iput
            • f2fsevictinode
              • f2fsbugon(sbi, isinodeflagset(inode, FIDIRTYINODE)) : trigger kernel panic

When we try to repair icurrentdepth in readonly filesystem, let's skip dirty inode to avoid panic in later f2fsevictinode().(CVE-2024-42297)

In the Linux kernel, the following vulnerability has been resolved:

ext4: check dot and dotdot of dx_root before making dir indexed

Syzbot reports a issue as follows:

BUG: unable to handle page fault for address: ffffed11022e24fe PGD 23ffee067 P4D 23ffee067 PUD 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0 Call Trace: <TASK> makeindexeddir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4addentry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4rename fs/ext4/namei.c:3936 [inline] ext4rename2+0x26e5/0x4370 fs/ext4/namei.c:4214

[...]

The immediate cause of this problem is that there is only one valid dentry for the block to be split during do_split, so split==0 results in out of bounds accesses to the map triggering the issue.

do_split
  unsigned split
  dx_make_map
   count = 1
  split = count/2 = 0;
  continued = hash2 == map[split - 1].hash;
   ---> map[4294967295]

The maximum length of a filename is 255 and the minimum block size is 1024, so it is always guaranteed that the number of entries is greater than or equal to 2 when do_split() is called.

But syzbot's crafted image has no dot and dotdot in dir, and the dentry distribution in dirblock is as follows:

bus dentry1 hole dentry2 free |xx--|xx-------------|...............|xx-------------|...............| 0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024

So when renaming dentry1 increases its namelen length by 1, neither hole nor free is sufficient to hold the new dentry, and makeindexed_dir() is called.

In makeindexeddir() it is assumed that the first two entries of the dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root because they are treated as dot and dotdot, and only dentry2 is moved to the new leaf block. That's why count is equal to 1.

Therefore add the ext4checkdx_root() helper function to add more sanity checks to dot and dotdot before starting the conversion to avoid the above issue.(CVE-2024-42305)

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check for NULL pointer

[why & how] Need to make sure plane_state is initialized before accessing its members.

(cherry picked from commit 295d91cbc700651782a60572f83c24861607b648)(CVE-2024-42308)

In the Linux kernel, the following vulnerability has been resolved:

kvm: s390: Reject memory region operations for ucontrol VMs

This change rejects the KVMSETUSERMEMORYREGION and KVMSETUSERMEMORYREGION2 ioctls when called on a ucontrol VM. This is necessary since ucontrol VMs have kvm->arch.gmap set to 0 and would thus result in a null pointer dereference further in. Memory management needs to be performed in userspace and using the ioctls KVMS390UCASMAP and KVMS390UCASUNMAP.

Also improve s390 specific documentation for KVMSETUSERMEMORYREGION and KVMSETUSERMEMORYREGION2.

frankja@linux.ibm.com: commit message spelling fix, subject prefix fix

In the Linux kernel, the following vulnerability has been resolved:

ext4: fix infinite loop when replaying fast_commit

When doing fastcommit replay an infinite loop may occur due to an uninitialized extentstatus struct. ext4extdetermineinserthole() does not detect the replay and calls ext4esfindextentrange(), which will return immediately without initializing the 'es' variable.

Because 'es' contains garbage, an integer overflow may happen causing an infinite loop in this function, easily reproducible using fstest generic/039.

This commit fixes this issue by unconditionally initializing the structure in function ext4esfindextentrange().

Thanks to Zhang Yi, for figuring out the real problem!(CVE-2024-43828)

In the Linux kernel, the following vulnerability has been resolved:

media: mediatek: vcodec: Handle invalid decoder vsi

Handle an invalid decoder vsi in vpudecinit to ensure the decoder vsi is valid for future use.(CVE-2024-43831)

In the Linux kernel, the following vulnerability has been resolved:

cgroup/cpuset: Prevent UAF in proccpusetshow()

An UAF can happen when /proc/cpuset is read as reported in [1].

This can be reproduced by the following methods: 1.add an mdelay(1000) before acquiring the cgrouplock In the cgrouppath_ns function. 2.$cat /proc/<pid>/cpuset repeatly. 3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/ $umount /sys/fs/cgroup/cpuset/ repeatly.

The race that cause this bug can be shown as below:

(umount) | (cat /proc/<pid>/cpuset) cssrelease | proccpusetshow cssreleaseworkfn | css = taskgetcss(tsk, cpusetcgrpid); cssfreerworkfn | cgrouppathns(css->cgroup, ...); cgroupdestroyroot | mutexlock(&cgroupmutex); rebindsubsystems | cgroupfreeroot | | // cgrp was freed, UAF | cgrouppathns_locked(cgrp,..);

When the cpuset is initialized, the root node topcpuset.css.cgrp will point to &cgrpdflroot.cgrp. In cgroup v1, the mount operation will allocate cgrouproot, and topcpuset.css.cgrp will point to the allocated &cgrouproot.cgrp. When the umount operation is executed, topcpuset.css.cgrp will be rebound to &cgrpdfl_root.cgrp.

The problem is that when rebinding to cgrpdflroot, there are cases where the cgrouproot allocated by setting up the root for cgroup v1 is cached. This could lead to a Use-After-Free (UAF) if it is subsequently freed. The descendant cgroups of cgroup v1 can only be freed after the css is released. However, the css of the root will never be released, yet the cgrouproot should be freed when it is unmounted. This means that obtaining a reference to the css of the root does not guarantee that css.cgrp->root will not be freed.

Fix this problem by using rcureadlock in proccpusetshow(). As cgrouproot is kfreercu after commit d23b5c577715 ("cgroup: Make operations on the cgroup rootlist RCU safe"), css->cgroup won't be freed during the critical section. To call cgrouppathnslocked, csssetlock is needed, so it is safe to replace taskgetcss with task_css.

[1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd(CVE-2024-43853)

In the Linux kernel, the following vulnerability has been resolved:

remoteproc: imx_rproc: Skip over memory region when node value is NULL

In imxrprocaddrinit() "nph = ofcountphandlewithargs()" just counts number of phandles. But phandles may be empty. So ofparse_phandle() in the parsing loop (0 < a < nph) may return NULL which is later dereferenced. Adjust this issue by adding NULL-return check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixed title to fit within the prescribed 70-75 charcters

In the Linux kernel, the following vulnerability has been resolved:

net: usb: qmi_wwan: fix memory leak for not ip packets

Free the unused skb when not ip packets arrive.(CVE-2024-43861)

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Always drain health in shutdown callback

There is no point in recovery during device shutdown. if health work started need to wait for it to avoid races and NULL pointer access.

Hence, drain health WQ on shutdown callback.(CVE-2024-43866)

In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: handle 2x996 RU allocation in cfg80211calculatebitrate_he()

Currently NL80211RATEINFOHERUALLOC2x996 is not handled in cfg80211calculatebitrate_he(), leading to below warning:

kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211calculatebitrate_he+0x22b/0x270 [cfg80211]

Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.(CVE-2024-43879)

In the Linux kernel, the following vulnerability has been resolved:

exec: Fix ToCToU between perm check and set-uid/gid usage

When opening a file for exec via dofilpopen(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges.

For example, if a file could change permissions from executable and not set-id:

---------x 1 root root 16048 Aug 7 13:16 target

to set-id and non-executable:

---S------ 1 root root 16048 Aug 7 13:16 target

it is possible to gain root privileges when execution should have been disallowed.

While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root:

-rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target

becomes:

-rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target

But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpmfilluid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root".

Re-check that we still have execute permissions in case the metadata has changed. It would be better to keep a copy from the perm-check time, but until we can do that refactoring, the least-bad option is to do a full inode_permission() call (under inode lock). It is understood that this is safe against dead-locks, but hardly optimal.(CVE-2024-43882)