The Linux Kernel, the operating system core itself.

Security Fix(es):

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:

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:

ocfs2: add bounds checking to ocfs2checkdir_entry()

This adds sanity checks for ocfs2direntry to make sure all members of ocfs2direntry don't stray beyond valid memory region.(CVE-2024-41015)

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

hfsplus: fix uninit-value in copy_name

[syzbot reported] BUG: KMSAN: uninit-value in sizedstrscpy+0xc4/0x160 sizedstrscpy+0xc4/0x160 copyname+0x2af/0x320 fs/hfsplus/xattr.c:411 hfspluslistxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750 vfslistxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 pathlistxattr fs/xattr.c:864 [inline] _dosyslistxattr fs/xattr.c:876 [inline] _sesyslistxattr fs/xattr.c:873 [inline] _x64syslistxattr+0x16b/0x2f0 fs/xattr.c:873 x64syscall+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls64.h:195 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Uninit was created at: slabpostallochook mm/slub.c:3877 [inline] slaballocnode mm/slub.c:3918 [inline] kmalloctrace+0x57b/0xbe0 mm/slub.c:4065 kmalloc include/linux/slab.h:628 [inline] hfspluslistxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699 vfslistxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 pathlistxattr fs/xattr.c:864 [inline] _dosyslistxattr fs/xattr.c:876 [inline] _sesyslistxattr fs/xattr.c:873 [inline] _x64syslistxattr+0x16b/0x2f0 fs/xattr.c:873 x64syscall+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls64.h:195 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f [Fix] When allocating memory to strbuf, initialize memory to 0.(CVE-2024-41059)

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:

scsi: qla2xxx: Fix for possible memory corruption

Init Control Block is dereferenced incorrectly. Correctly dereference ICB(CVE-2024-42288)

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:

PCI/DPC: Fix use-after-free on concurrent DPC and hot-removal

Keith reports a use-after-free when a DPC event occurs concurrently to hot-removal of the same portion of the hierarchy:

The dpchandler() awaits readiness of the secondary bus below the Downstream Port where the DPC event occurred. To do so, it polls the config space of the first child device on the secondary bus. If that child device is concurrently removed, accesses to its struct pcidev cause the kernel to oops.

That's because pcibridgewaitforsecondarybus() neglects to hold a reference on the child device. Before v6.3, the function was only called on resume from system sleep or on runtime resume. Holding a reference wasn't necessary back then because the pciehp IRQ thread could never run concurrently. (On resume from system sleep, IRQs are not enabled until after the resumenoirq phase. And runtime resume is always awaited before a PCI device is removed.)

However starting with v6.3, pcibridgewaitforsecondarybus() is also called on a DPC event. Commit 53b54ad074de ("PCI/DPC: Await readiness of secondary bus after reset"), which introduced that, failed to appreciate that pcibridgewaitforsecondarybus() now needs to hold a reference on the child device because dpc_handler() and pciehp may indeed run concurrently. The commit was backported to v5.10+ stable kernels, so that's the oldest one affected.

Add the missing reference acquisition.

Abridged stack trace:

BUG: unable to handle page fault for address: 00000000091400c0 CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0 RIP: pcibusreadconfigdword+0x17/0x50 pcidevwait() pcibridgewaitforsecondarybus() dpcresetlink() pciedorecovery() dpchandler()(CVE-2024-42302)

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:

landlock: Don't lose track of restrictions on cred_transfer

When a process' cred struct is replaced, this almost always invokes the credprepare LSM hook; but in one special case (when KEYCTLSESSIONTOPARENT updates the parent's credentials), the credtransfer LSM hook is used instead. Landlock only implements the credprepare hook, not credtransfer, so KEYCTLSESSIONTOPARENT causes all information on Landlock restrictions to be lost.

This basically means that a process with the ability to use the fork() and keyctl() syscalls can get rid of all Landlock restrictions on itself.

Fix it by adding a credtransfer hook that does the same thing as the existing credprepare hook. (Implemented by having hookcredprepare() call hookcredtransfer() so that the two functions are less likely to accidentally diverge in the future.)(CVE-2024-42318)

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)