OESA-2024-2495

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don't use timerpending() in reqskqueueunlink(). Martin KaFai Lau reported use-after-free [0] in reqsktimerhandler(). """ We are seeing a use-after-free from a bpf prog attached to tracetcpretransmitsynack. The program passes the req->sk to the bpfskstoragegettracing kernel helper which does check for null before using it. """ The commit 83fccfc3940c ("inet: fix potential deadlock in reqskqueueunlink()") added timerpending() in reqskqueueunlink() not to call deltimersync() from reqsktimerhandler(), but it introduced a small race window. Before the timer is called, expiretimers() calls detachtimer(timer, true) to clear timer->entry.pprev and marks it as not pending. If reqskqueueunlink() checks timerpending() just after expiretimers() calls detachtimer(), TCP will miss deltimersync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inetcskcompletehashdance() calls inetcskreqskqueuedrop(), but deltimersync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqskput() decrements rskrefcnt, but reqsk timer still has another one, and inetcskaccept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->sk Let's not use timerpending() by passing the caller context to _inetcskreqskqueuedrop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpfskstoragegettracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpfskstoragegettracing+0x2e/0x1b0 bpfprog5ea3e95db6da0438tcpretransmitsynack+0x1d20/0x1dda bpftracerun2+0x4c/0xc0 tcprtxsynack+0xf9/0x100 reqsktimerhandler+0xda/0x3d0 runtimersoftirq+0x292/0x8a0 irqexitrcu+0xf5/0x320 sysvecapictimerinterrupt+0x6d/0x80 asmsysvecapictimerinterrupt+0x16/0x20 intelidleirq+0x5a/0xa0 cpuidleenterstate+0x94/0x273 cpustartupentry+0x15e/0x260 startsecondary+0x8a/0x90 secondarystartup64noverify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: skprotalloc+0x35/0x140 skclonelock+0x1f/0x3f0 inetcskclonelock+0x15/0x160 tcpcreateopenreqchild+0x1f/0x410 tcpv6synrecvsock+0x1da/0x700 tcpcheckreq+0x1fb/0x510 tcpv6rcv+0x98b/0x1420 ipv6listrcv+0x2258/0x26e0 napicompletedone+0x5b1/0x2990 mlx5enapipoll+0x2ae/0x8d0 netrxaction+0x13e/0x590 irqexitrcu+0xf5/0x320 commoninterrupt+0x80/0x90 asmcommoninterrupt+0x22/0x40 cpuidleenterstate+0xfb/0x273 cpustartupentry+0x15e/0x260 startsecondary+0x8a/0x90 secondarystartup64noverify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcucoresi+0x4ff/0xf10 irqexitrcu+0xf5/0x320 sysvecapictimerinterrupt+0x6d/0x80 asmsysvecapictimerinterrupt+0x16/0x20 cpuidleenterstate+0xfb/0x273 cpustartupentry+0x15e/0x260 startsecondary+0x8a/0x90 secondarystartup64noverify+0xfa/0xfb(CVE-2024-50154)

In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.(CVE-2024-50179)

In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfsfindentry() Syzbot reported that a task hang occurs in vcsopen() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfsfindentry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfsgetfolio() fails. If the filesystem images is corrupted, and the isize of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfscheckfolio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfsfindentry(). The current interface of nilfsfindentry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfsfindentry(), so fix it together.(CVE-2024-50202)

In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small gsomaxsize/gsoipv4maxsize Config a small gsomaxsize/gsoipv4maxsize will lead to an underflow in skdstgsomaxsize(), which may trigger a BUGON crash, because sk->skgsomaxsize would be much bigger than device limits. Call Trace: tcpwritexmit tsosegs = tcpinittsosegs(skb, mssnow); tcpsetskbtsosegs tcpskbpcountset // skb->len = 524288, mssnow = 8 // u16 tsosegs = 524288/8 = 65535 -> 0 tsosegs = DIVROUNDUP(skb->len, mssnow) BUGON(!tsosegs) Add check for the minimum value of gsomaxsize and gsoipv4max_size.(CVE-2024-50258)

In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insertdelayedref() if we need to update the action of an existing ref to BTRFSDROPDELAYEDREF, we delete the ref from its ref head's refaddlist using listdel(), which leaves the ref's addlist member not reinitialized, as listdel() sets the next and prev members of the list to LISTPOISON1 and LISTPOISON2, respectively. If later we end up calling dropdelayedref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at dropdelayedref() we call listempty() against the ref's addlist, which returns false since the list was not reinitialized after the listdel() and as a consequence we call listdel() again at dropdelayedref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIGLISTHARDENED and CONFIGDEBUGLIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with listdelinit() instead.(CVE-2024-50273)

In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in keytaskpermission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in _kuidval include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uideq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in keytaskpermission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: _dumpstack lib/dumpstack.c:82 [inline] dumpstack+0x107/0x167 lib/dumpstack.c:123 printaddressdescription.constprop.0+0x19/0x170 mm/kasan/report.c:400 _kasanreport.cold+0x6c/0x84 mm/kasan/report.c:560 kasanreport+0x3a/0x50 mm/kasan/report.c:585 _kuidval include/linux/uidgid.h:36 [inline] uideq include/linux/uidgid.h:63 [inline] keytaskpermission+0x394/0x410 security/keys/permission.c:54 searchnestedkeyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the searchnestedkeyrings function, when it iterates through the slots in a node(below tag ascendtonode), if the slot pointer is meta and node->backpointer != NULL(it means a root), it will proceed to descendtonode. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyringptriskeyring function. However, KEYRINGPTRSUBTYPE is 0x2UL, the same as ASSOCARRAYPTRSUBTYPEMASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descendtonode if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ jarkko: tweaked the commit message a bit to have an appropriate closes tag.

In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.(CVE-2024-53061)

In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decodegetfattrattrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BADPAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decodegetfattrattrs+0x2d6d/0x2f90 decodegetfattrattrs+0x2d6d/0x2f90 decodegetfattrgeneric+0x806/0xb00 nfs4xdrdecgetattr+0x1de/0x240 rpcauthunwraprespdecode+0xab/0x100 rpcauthunwrapresp+0x95/0xc0 calldecode+0x4ff/0xb50 _rpcexecute+0x57b/0x19d0 rpcexecute+0x368/0x5e0 rpcruntask+0xcfe/0xee0 nfs4procgetattr+0x5b5/0x990 _nfsrevalidateinode+0x477/0xd00 nfsaccessgetcached+0x1021/0x1cc0 nfsdoaccess+0x9f/0xae0 nfspermission+0x1e4/0x8c0 inodepermission+0x356/0x6c0 linkpathwalk+0x958/0x1330 pathlookupat+0xce/0x6b0 filenamelookup+0x23e/0x770 vfsstatx+0xe7/0x970 vfsfstatat+0x1f2/0x2c0 _sesysnewfstatat+0x67/0x880 _x64sysnewfstatat+0xbd/0x120 x64syscall+0x1826/0x3cf0 dosyscall64+0xd0/0x1b0 entrySYSCALL64afterhwframe+0x77/0x7f The KMSAN warning is triggered in decodegetfattrattrs(), when calling decodeattrmdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfsfattr_init().(CVE-2024-53066)