OESA-2024-2492

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved: bpf: support non-r10 register spill/fill to/from stack in precision tracking Use instruction (jump) history to record instructions that performed register spill/fill to/from stack, regardless if this was done through read-only r10 register, or any other register after copying r10 into it and potentially adjusting offset. To make this work reliably, we push extra per-instruction flags into instruction history, encoding stack slot index (spi) and stack frame number in extra 10 bit flags we take away from previdx in instruction history. We don't touch idx field for maximum performance, as it's checked most frequently during backtracking. This change removes basically the last remaining practical limitation of precision backtracking logic in BPF verifier. It fixes known deficiencies, but also opens up new opportunities to reduce number of verified states, explored in the subsequent patches. There are only three differences in selftests' BPF object files according to veristat, all in the positive direction (less states). File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) -------------------------------------- ------------- --------- --------- ------------- ---------- ---------- ------------- testclsredirectdynptr.bpf.linked3.o clsredirect 2987 2864 -123 (-4.12%) 240 231 -9 (-3.75%) xdpsynproxykern.bpf.linked3.o syncookietc 82848 82661 -187 (-0.23%) 5107 5073 -34 (-0.67%) xdpsynproxykern.bpf.linked3.o syncookiexdp 85116 84964 -152 (-0.18%) 5162 5130 -32 (-0.62%) Note, I avoided renaming jmphistory to more generic insnhist to minimize number of lines changed and potential merge conflicts between bpf and bpf-next trees. Notice also curhistentry pointer reset to NULL at the beginning of instruction verification loop. This pointer avoids the problem of relying on last jump history entry's insnidx to determine whether we already have entry for current instruction or not. It can happen that we added jump history entry because current instruction isjmppoint(), but also we need to add instruction flags for stack access. In this case, we don't want to entries, so we need to reuse last added entry, if it is present. Relying on insn_idx comparison has the same ambiguity problem as the one that was fixed recently in [0], so we avoid that. [0] https://patchwork.kernel.org/project/netdevbpf/patch/20231110002638.4168352-3-andrii@kernel.org/(CVE-2023-52920)

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

mptcp: pm: only mark 'subflow' endp as available

Adding the following warning ...

WARNONONCE(msk->pm.localaddrused == 0)

... before decrementing the localaddrused counter helped to find a bug when running the "remove single address" subtest from the mptcp_join.sh selftests.

Removing a 'signal' endpoint will trigger the removal of all subflows linked to this endpoint via mptcppmnlrmaddrorsubflow() with rmtype == MPTCPMIBRMSUBFLOW. This will decrement the localaddr_used counter, which is wrong in this case because this counter is linked to 'subflow' endpoints, and here it is a 'signal' endpoint that is being removed.

Now, the counter is decremented, only if the ID is being used outside of mptcppmnlrmaddrorsubflow(), only for 'subflow' endpoints, and if the ID is not 0 -- localaddrused is not taking into account these ones. This marking of the ID as being available, and the decrement is done no matter if a subflow using this ID is currently available, because the subflow could have been closed before.(CVE-2024-45010)

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

video/aperture: optionally match the device in sysfb_disable()

In apertureremoveconflictingpcidevices(), we currently only call sysfb_disable() on vga class devices. This leads to the following problem when the pimary device is not VGA compatible:

1. A PCI device with a non-VGA class is the boot display
2. That device is probed first and it is not a VGA device so sysfbdisable() is not called, but the device resources are freed by aperturedetachplatformdevice()
3. Non-primary GPU has a VGA class and it ends up calling sysfb_disable()
4. NULL pointer dereference via sysfbdisable() since the resources have already been freed by aperturedetachplatformdevice() when it was called by the other device.

Fix this by passing a device pointer to sysfb_disable() and checking the device to determine if we should execute it or not.

v2: Fix build when CONFIGSCREENINFO is not set v3: Move device check into the mutex Drop primary variable in apertureremoveconflictingpcidevices() Drop _init on pci sysfbpcidevis_enabled()(CVE-2024-46698)

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

perf/aux: Fix AUX buffer serialization

Ole reported that event->mmap_mutex is strictly insufficient to serialize the AUX buffer, add a per RB mutex to fully serialize it.

Note that in the lock order comment the perfevent::mmapmutex order was already wrong, that is, it nesting under mmap_lock is not new with this patch.(CVE-2024-46713)

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

ice: protect XDP configuration with a mutex

The main threat to data consistency in ice_xdp() is a possible asynchronous PF reset. It can be triggered by a user or by TX timeout handler.

XDP setup and PF reset code access the same resources in the following sections: * icevsiclose() in iceprepareforreset() - already rtnl-locked * icevsirebuild() for the PF VSI - not protected * icevsi_open() - already rtnl-locked

With an unfortunate timing, such accesses can result in a crash such as the one below:

[ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEMTYPEXSKBUFFPOOL on Rx ring 14 [ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEMTYPEXSKBUFFPOOL on Rx ring 18 [Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms [ +0.000093] ice 0000:b1:00.0 ens801f0np0: txtimeout: VSInum: 6, Q 14, NTC: 0x0, HWHEAD: 0x0, NTU: 0x0, INT: 0x4000001 [ +0.000012] ice 0000:b1:00.0 ens801f0np0: txtimeout recovery level 1, txqueue 14 [ +0.394718] ice 0000:b1:00.0: PTP reset successful [ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ +0.000045] #PF: supervisor read access in kernel mode [ +0.000023] #PF: errorcode(0x0000) - not-present page [ +0.000023] PGD 0 P4D 0 [ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI [ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1 [ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021 [ +0.000036] Workqueue: ice iceservicetask [ice] [ +0.000183] RIP: 0010:icecleantxring+0xa/0xd0 [ice] [...] [ +0.000013] Call Trace: [ +0.000016] <TASK> [ +0.000014] ? _die+0x1f/0x70 [ +0.000029] ? pagefaultoops+0x171/0x4f0 [ +0.000029] ? schedule+0x3b/0xd0 [ +0.000027] ? excpagefault+0x7b/0x180 [ +0.000022] ? asmexcpagefault+0x22/0x30 [ +0.000031] ? icecleantxring+0xa/0xd0 [ice] [ +0.000194] icefreetxring+0xe/0x60 [ice] [ +0.000186] icedestroyxdprings+0x157/0x310 [ice] [ +0.000151] icevsidecfg+0x53/0xe0 [ice] [ +0.000180] icevsirebuild+0x239/0x540 [ice] [ +0.000186] icevsirebuildbytype+0x76/0x180 [ice] [ +0.000145] icerebuild+0x18c/0x840 [ice] [ +0.000145] ? delaytsc+0x4a/0xc0 [ +0.000022] ? delaytsc+0x92/0xc0 [ +0.000020] icedoreset+0x140/0x180 [ice] [ +0.000886] iceservicetask+0x404/0x1030 [ice] [ +0.000824] processonework+0x171/0x340 [ +0.000685] workerthread+0x277/0x3a0 [ +0.000675] ? preemptcountadd+0x6a/0xa0 [ +0.000677] ? _rawspinlockirqsave+0x23/0x50 [ +0.000679] ? _pfxworkerthread+0x10/0x10 [ +0.000653] kthread+0xf0/0x120 [ +0.000635] ? _pfxkthread+0x10/0x10 [ +0.000616] retfromfork+0x2d/0x50 [ +0.000612] ? _pfxkthread+0x10/0x10 [ +0.000604] retfromforkasm+0x1b/0x30 [ +0.000604] </TASK>

The previous way of handling this through returning -EBUSY is not viable, particularly when destroying AF_XDP socket, because the kernel proceeds with removal anyway.

There is plenty of code between those calls and there is no need to create a large critical section that covers all of them, same as there is no need to protect icevsirebuild() with rtnl_lock().

Add xdpstatelock mutex to protect icevsirebuild() and ice_xdp().

Leaving unprotected sections in between would result in two states that have to be considered: 1. when the VSI is closed, but not yet rebuild 2. when VSI is already rebuild, but not yet open

The latter case is actually already handled through !netifrunning() case, we just need to adjust flag checking a little. The former one is not as trivial, because between icevsiclose() and icevsi_rebuild(), a lot of hardware interaction happens, this can make adding/deleting rings exit with an error. Luckily, VSI rebuild is pending and can apply new configuration for us in a managed fashion.

Therefore, add an additional VSI state flag ICEVSIREBUILDPENDING to indicate that icex ---truncated---(CVE-2024-46765)

In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmpglobalallow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmpglobalallow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmpglobalconsume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.(CVE-2024-47678)

In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6uncachedlistflushdev() Blamed commit accidentally removed a check for rt->rt6iidev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6uncachedlistflushdev net/ipv6/route.c:177 [inline] RIP: 0010:rt6disableip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> addrconfifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconfnotify+0x3cb/0x1020 notifiercallchain+0x19f/0x3e0 kernel/notifier.c:93 callnetdevicenotifiersextack net/core/dev.c:2032 [inline] callnetdevicenotifiers net/core/dev.c:2046 [inline] unregisternetdevicemanynotify+0xd81/0x1c40 net/core/dev.c:11352 unregisternetdevicemany net/core/dev.c:11414 [inline] unregisternetdevicequeue+0x303/0x370 net/core/dev.c:11289 unregisternetdevice include/linux/netdevice.h:3129 [inline] _tundetach+0x6b9/0x1600 drivers/net/tun.c:685 tundetach drivers/net/tun.c:701 [inline] tunchrclose+0x108/0x1b0 drivers/net/tun.c:3510 _fput+0x24a/0x8a0 fs/filetable.c:422 taskworkrun+0x24f/0x310 kernel/taskwork.c:228 exittaskwork include/linux/taskwork.h:40 [inline] doexit+0xa2f/0x27f0 kernel/exit.c:882 dogroupexit+0x207/0x2c0 kernel/exit.c:1031 _dosysexitgroup kernel/exit.c:1042 [inline] _sesysexitgroup kernel/exit.c:1040 [inline] _x64sysexitgroup+0x3f/0x40 kernel/exit.c:1040 x64syscall+0x2634/0x2640 arch/x86/include/generated/asm/syscalls64.h:232 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIGRAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6uncachedlistflushdev net/ipv6/route.c:177 [inline] RIP: 0010:rt6disableip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---(CVE-2024-47707)

In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilcparsejoinbssparam In the wilc_parse_join_bss_param function, the TSF field of the ies structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable ies_tsf before the RCU lock is released. The param->tsf_lo field is then assigned using this local variable, ensuring that the TSF value is safely accessed.(CVE-2024-47712)

In the Linux kernel, the following vulnerability has been resolved: mm: call the securitymmapfile() LSM hook in remapfilepages() The remapfilepages syscall handler calls dommap() directly, which doesn't contain the LSM security check. And if the process has called personality(READIMPLIESEXEC) before and remapfilepages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by securitymmapfile LSM hook in the remapfilepages syscall handler before dommap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { sizet pagesz = sysconf(SCPAGESIZE); int mfd = syscall(SYSmemfdcreate, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROTREAD | PROTWRITE, MAPSHARED, mfd, 0); unsigned int old = syscall(SYSpersonality, 0xffffffff); syscall(SYSpersonality, READIMPLIESEXEC | old); syscall(SYSremapfilepages, buf, pagesz, 0, 2, 0); syscall(SYSpersonality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", ORDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) PM: subject line tweaks

In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3probe function, a timer is initialized with a callback function ether3ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3ledoff ether3remove | freenetdev(dev); | putdevic | kfree(dev); | | ether3outw(priv(dev)->regs.config2 |= CFG2CTRLO, REGCONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.(CVE-2024-47747)

In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookupatid The lookupatid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the act_establish() and act_open_rpl() functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47749)

In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nidofcurrent will never be equal to nid in that while loop because nidofcurrent is not set in sgxnumamask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on a node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.(CVE-2024-49856)

In the Linux kernel, the following vulnerability has been resolved: mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 ("mm/slub: extend redzone check to extra allocated kmalloc space than requested"), setting origsize treats the wasted space (objectsize - origsize) as a redzone. However with initonfree=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored origsize, making it zero, which makes checkobject() treat the whole object as a redzone. These issues lead to the following BUG report with "slubdebug=FUZ initonfree=1": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dumpbacktrace+0x90/0xe8 [ 0.000000] showstack+0x18/0x24 [ 0.000000] dumpstacklvl+0x74/0x8c [ 0.000000] dumpstack+0x18/0x24 [ 0.000000] printtrailer+0x150/0x218 [ 0.000000] checkobject+0xe4/0x454 [ 0.000000] freetopartiallist+0x2f8/0x5ec To address the issue, use origsize to clear the used area. And restore the value of origsize after clear the remaining area. When CONFIGSLUBDEBUG not defined, (getorigsize()' directly returns s->objectsize. So when using memset to init the area, the size can simply be origsize, as origsize returns objectsize when CONFIGSLUBDEBUG not enabled. And origsize can never be bigger than objectsize.(CVE-2024-49885)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDEBYZERO issues reported by Coverity.(CVE-2024-49899)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipectx->planestate in dcn20programpipe This commit addresses a null pointer dereference issue in the dcn20_program_pipe function. The issue could occur when pipe_ctx->plane_state is null. The fix adds a check to ensure pipe_ctx->plane_state is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20hwseq.c:1925 dcn20programpipe() error: we previously assumed 'pipectx->plane_state' could be null (see line 1877)(CVE-2024-49914)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clkmgr in dcn32inithw This commit addresses a potential null pointer dereference issue in the dcn32_init_hw function. The issue could occur when dc->clk_mgr is null. The fix adds a check to ensure dc->clk_mgr is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32hwseq.c:961 dcn32inithw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)(CVE-2024-49915)

In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlinkupdatesocketmc+0x3c/0xc0 LR [c000000000c0f764] _netlinkclearmulticastusers+0x74/0xc0 Call Trace: _netlinkclearmulticastusers+0x74/0xc0 genlunregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.(CVE-2024-50024)

In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running kmscube with one or more performance monitors enabled via GALLIUM_HUD, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d sndsochdmicodec drmdisplayhelper gpusched drmshmemhelper cec drmdmahelper drmkmshelper i2cbrcmstb drm drmpanelorientationquirks sndsoccore sndcompress sndpcmdmaengine sndpcm sndtimer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3dbin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : _mutexlock.constprop.0+0x90/0x608 [ 55.008879] lr : _mutexlock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] _mutexlock.constprop.0+0x90/0x608 [ 55.014646] _mutexlockslowpath+0x1c/0x30 [ 55.015317] mutexlock+0x50/0x68 [ 55.015961] v3dperfmonstop+0x40/0xe0 [v3d] [ 55.016627] v3dbinjobrun+0x10c/0x2d8 [v3d] [ 55.017282] drmschedmain+0x178/0x3f8 [gpusched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] retfromfork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3dbin[166] exited with preemptcount 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt kmscube), the active performance monitor is not stopped. Although all perfmons are destroyed in v3d_perfmon_close_file(), the active performance monitor's pointer (v3d->active_perfmon) is still retained. If kmscube is run again, the driver will attempt to stop the active performance monitor using the stale pointer in v3d->active_perfmon. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.(CVE-2024-50031)

In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTOUNSPEC where needed syzbot managed to call xtcluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xtcluster.c:72 xtclustermt+0x196/0x780 [..] ebtdotable+0x174b/0x2a40 Module registers to NFPROTOUNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skbnetworkheader() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XTCONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBTCONTINUE is a completely different value than XTCONTINUE. Most matches/targets are changed to register for NFPROTOIPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.(CVE-2024-50038)

In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCASTAB only for root qdisc Most qdiscs maintain their backlog using qdiscpktlen(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCASTAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: errorcode(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfqdequeue (net/sched/schsfq.c:272 net/sched/schsfq.c:499) schsfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0: 0f b7 50 12 movzwl 0x12(%rax),%edx 4: 48 8d 04 d5 00 00 00 lea 0x0(,%rdx,8),%rax b: 00 c: 48 89 d6 mov %rdx,%rsi f: 48 29 d0 sub %rdx,%rax 12: 48 8b 91 c0 01 00 00 mov 0x1c0(%rcx),%rdx 19: 48 c1 e0 03 shl $0x3,%rax 1d: 48 01 c2 add %rax,%rdx 20: 66 83 7a 1a 00 cmpw $0x0,0x1a(%rdx) 25: 7e c0 jle 0xffffffffffffffe7 27: 48 8b 3a mov (%rdx),%rdi 2a:* 4c 8b 07 mov (%rdi),%r8 <-- trapping instruction 2d: 4c 89 02 mov %r8,(%rdx) 30: 49 89 50 08 mov %rdx,0x8(%r8) 34: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 3b: 00 3c: 48 rex.W 3d: c7 .byte 0xc7 3e: 07 (bad) ... Code starting with the faulting instruction =========================================== 0: 4c 8b 07 mov (%rdi),%r8 3: 4c 89 02 mov %r8,(%rdx) 6: 49 89 50 08 mov %rdx,0x8(%r8) a: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 11: 00 12: 48 rex.W 13: c7 .byte 0xc7 14: 07 (bad) ... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] <TASK> [ 88.808710] ? _die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? pagefaultoops (arch/x86/mm/fault.c:715) [ 88.809561] ? excpagefault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asmexcpagefault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfqdequeue (net/sched/schsfq.c:272 net/sched/schsfq.c:499) schsfq [ 88.810411] sfqreset (net/sched/schsfq.c:525) schsfq [ 88.810671] qdiscreset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/schg ---truncated---(CVE-2024-50039)

In the Linux kernel, the following vulnerability has been resolved: netfilter: brnetfilter: fix panic with metadatadst skb Fix a kernel panic in the brnetfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in brnfdevqueuexmit. It is dependent on: 1) the brnetfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, brhandleegressvlantunnel is called and changes the skbdst to the tunnel dst. The tunneldst is a metadata type of dst, i.e., skbvaliddst(skb) is false, and metadata->dst.dev is NULL. Then in the brnetfilter hooks, in brnfdevqueuexmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling brnfipfragment, which in turns call ipskbdstmtu. The ipdstmtu tries to use the skbdst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6udptunnel udptunnel veth brnetfilter bridge stp llc ipv6 crct10difce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : brnfdevqueuexmit+0x390/0x4ec [brnetfilter] [ 176.297382] lr : brnfdevqueuexmit+0x2ac/0x4ec [brnetfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] brnfdevqueuexmit+0x390/0x4ec [brnetfilter] [ 176.301411] brnfpostrouting+0x2a8/0x3e4 [brnetfilter] [ 176.301703] nfhookslow+0x48/0x124 [ 176.302060] brforwardfinish+0xc8/0xe8 [bridge] [ 176.302371] brnfhookthresh+0x124/0x134 [brnetfilter] [ 176.302605] brnfforwardfinish+0x118/0x22c [brnetfilter] [ 176.302824] brnfforwardip.part.0+0x264/0x290 [brnetfilter] [ 176.303136] brnfforward+0x2b8/0x4e0 [brnetfilter] [ 176.303359] nfhook_slow+0x48/0x124 [ 176.303 ---truncated---(CVE-2024-50045)

In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes connum of connections. After establishing all its connections, the information is exchanged between the client and server through the inforeq message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.(CVE-2024-50062)

In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcppmnlrmaddrorsubflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcppmnlrmaddrorsubflow+0xb44/0xcc0 net/mptcp/pmnetlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc3/0x620 mm/kasan/report.c:488 kasanreport+0xd9/0x110 mm/kasan/report.c:601 mptcppmnlrmaddrorsubflow+0xb44/0xcc0 net/mptcp/pmnetlink.c:881 mptcppmnlrmsubflowreceived net/mptcp/pmnetlink.c:914 [inline] mptcpnlremoveidzeroaddress+0x305/0x4a0 net/mptcp/pmnetlink.c:1572 mptcppmnldeladdrdoit+0x5c9/0x770 net/mptcp/pmnetlink.c:1603 genlfamilyrcvmsgdoit+0x202/0x2f0 net/netlink/genetlink.c:1115 genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0x565/0x800 net/netlink/genetlink.c:1210 netlinkrcvskb+0x165/0x410 net/netlink/afnetlink.c:2551 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1331 [inline] netlinkunicast+0x53c/0x7f0 net/netlink/afnetlink.c:1357 netlinksendmsg+0x8b8/0xd70 net/netlink/afnetlink.c:1901 socksendmsgnosec net/socket.c:729 [inline] _socksendmsg net/socket.c:744 [inline] _syssendmsg+0x9ae/0xb40 net/socket.c:2607 _syssendmsg+0x135/0x1e0 net/socket.c:2661 _syssendmsg+0x117/0x1f0 net/socket.c:2690 dosyscall32irqson arch/x86/entry/common.c:165 [inline] _dofastsyscall32+0x73/0x120 arch/x86/entry/common.c:386 dofastsyscall32+0x32/0x80 arch/x86/entry/common.c:411 entrySYSENTERcompatafterhwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIGRAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Allocated by task 5387: kasansavestack+0x33/0x60 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:377 [inline] _kasankmalloc+0xaa/0xb0 mm/kasan/common.c:394 kmallocnoprof include/linux/slab.h:878 [inline] kzallocnoprof include/linux/slab.h:1014 [inline] subflowcreatectx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflowulpinit+0xc3/0x4d0 net/mptcp/subflow.c:1956 _tcpsetulp net/ipv4/tcpulp.c:146 [inline] tcpsetulp+0x326/0x7f0 net/ipv4/tcpulp.c:167 mptcpsubflowcreatesocket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 _mptcpsubflowconnect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcppmcreatesubfloworsignaladdr+0xbda/0x23a0 net/mptcp/pmnetlink.c:642 mptcppmnlfullyestablished net/mptcp/pmnetlink.c:650 [inline] mptcppmnlwork+0x3a1/0x4f0 net/mptcp/pmnetlink.c:943 mptcpworker+0x15a/0x1240 net/mptcp/protocol.c:2777 processonework+0x958/0x1b30 kernel/workqueue.c:3229 processscheduledworks kernel/workqueue.c:3310 [inline] workerthread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 retfrom_fork+0x45/0x80 arch/x86/ke ---truncated---(CVE-2024-50085)

In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processorthermal driver uses pcimdeviceenable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pcidisabledevice() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 ("PCI: Remove legacy pcimrelease()"), this problem is exposed and triggers the warining below. [ 224.010735] procthermalpci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pcidisabledevice+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] <TASK> [ 224.010847] ? showregs+0x6d/0x80 [ 224.010851] ? _warn+0x8c/0x140 [ 224.010854] ? pcidisabledevice+0xe5/0x100 [ 224.010856] ? reportbug+0x1c9/0x1e0 [ 224.010859] ? handlebug+0x46/0x80 [ 224.010862] ? excinvalidop+0x1d/0x80 [ 224.010863] ? asmexcinvalidop+0x1f/0x30 [ 224.010867] ? pcidisabledevice+0xe5/0x100 [ 224.010869] ? pcidisabledevice+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcimdisabledevice+0x20/0x30 [ 224.010875] devmactionrelease+0x16/0x20 [ 224.010878] releasenodes+0x47/0xc0 [ 224.010880] devresreleaseall+0x9f/0xe0 [ 224.010883] deviceunbindcleanup+0x12/0x80 [ 224.010885] devicereleasedriverinternal+0x1ca/0x210 [ 224.010887] driverdetach+0x4e/0xa0 [ 224.010889] busremovedriver+0x6f/0xf0 [ 224.010890] driverunregister+0x35/0x60 [ 224.010892] pciunregisterdriver+0x44/0x90 [ 224.010894] procthermalpcidriverexit+0x14/0x5f0 [processorthermaldevicepci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pcidisabledevice() calls. rjw: Subject and changelog edits

In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEVOFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEVQUIESCE was set for all LU's scsidevices by UFS shutdown, and at that time the audio driver was waiting on blkmqsubmitbio() holding a mutexlock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutexunlock of blkmqsubmitbio(). To solve this, set SDEVOFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [deviceshutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] switchto+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] _schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedulepreemptdisabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] _mutexlock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] _mutexlockslowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutexlock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] deviceshutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernelrestart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] _arm64sysreboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invokesyscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0svccommon+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] doel0svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t64synchandler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t64sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [bioqueueenter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] _switchto+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] _schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] _bioqueueenter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blkmqsubmitbio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] _submitbio+0xb8/0x19c(CVE-2024-50098)

In the Linux kernel, the following vulnerability has been resolved: ACPI: PRM: Find EFIMEMORYRUNTIME block for PRM handler and context PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services. The issue arises because the PRMT is finding a block of type EFICONVENTIONALMEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called. [Firmware Bug]: Unable to handle paging request in EFI runtime service WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341 _efiqueuework+0x11c/0x170 Call trace: Let PRMT find a block with EFIMEMORYRUNTIME for PRM handler and PRM context. If no suitable block is found, a warning message will be printed, but the procedure continues to manage the next PRM handler. However, if the PRM handler is actually called without proper allocation, it would result in a failure during error handling. By using the correct memory types for runtime services, ensure that the PRM handler and the context are properly mapped in the virtual address space during runtime, preventing the paging request error. The issue is really that only memory that has been remapped for runtime by the firmware can be used by the PRM handler, and so the region needs to have the EFIMEMORY_RUNTIME attribute. rjw: Subject and changelog edits

In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udfgetfileshortad Check for overflow when computing alen in udfcurrentaext to mitigate later uninit-value use in udfgetfileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000(CVE-2024-50143)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: fix wild-memory-access in protounregister There's issue as follows: KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP: 0010:protounregister+0xee/0x400 Call Trace: <TASK> _dosysdeletemodule+0x318/0x580 dosyscall64+0xc1/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f As bnepinit() ignore bnepsockinit()'s return value, and bnepsockinit() will cleanup all resource. Then when remove bnep module will call bnepsockcleanup() to cleanup sock's resource. To solve above issue just return bnepsockinit()'s return value in bnepexit().(CVE-2024-50148)

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: RDMA/bnxtre: Avoid CPU lockups due fifo occupancy check loop Driver waits indefinitely for the fifo occupancy to go below a threshold as soon as the pacing interrupt is received. This can cause soft lockup on one of the processors, if the rate of DB is very high. Add a loop count for FPGA and exit the _waitforfifooccupancybelowth if the loop is taking more time. Pacing will be continuing until the occupancy is below the threshold. This is ensured by the checks in bnxtrepacingtimer_exp and further scheduling the work for pacing based on the fifo occupancy.(CVE-2024-50157)

In the Linux kernel, the following vulnerability has been resolved: bpf: devmap: provide rxq after redirect rxq contains a pointer to the device from where the redirect happened. Currently, the BPF program that was executed after a redirect via BPFMAPTYPEDEVMAP* does not have it set. This is particularly bad since accessing ingressifindex, e.g. SEC("xdp") int prog(struct xdpmd *pkt) { return bpfredirectmap(&devredirectmap, 0, 0); } SEC("xdp/devmap") int progafterredirect(struct xdpmd *pkt) { bpfprintk("ifindex %i", pkt->ingressifindex); return XDPPASS; } depends on access to rxq, so a NULL pointer gets dereferenced: <1>[ 574.475170] BUG: kernel NULL pointer dereference, address: 0000000000000000 <1>[ 574.475188] #PF: supervisor read access in kernel mode <1>[ 574.475194] #PF: errorcode(0x0000) - not-present page <6>[ 574.475199] PGD 0 P4D 0 <4>[ 574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4>[ 574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 Not tainted 6.11.0-rc5-reduced-00859-g780801200300 #23 <4>[ 574.475226] Hardware name: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 03/14/2023 <4>[ 574.475231] Workqueue: mld mldifcwork <4>[ 574.475247] RIP: 0010:bpfprog5e13354d9cf5018aprogafterredirect+0x17/0x3c <4>[ 574.475257] Code: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 <48> 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b <4>[ 574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206 <4>[ 574.475269] RAX: ffffa62440280cd8 RBX: 0000000000000001 RCX: 0000000000000000 <4>[ 574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0 <4>[ 574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001 <4>[ 574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000 <4>[ 574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000 <4>[ 574.475289] FS: 0000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000 <4>[ 574.475294] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0 <4>[ 574.475303] PKRU: 55555554 <4>[ 574.475306] Call Trace: <4>[ 574.475313] <IRQ> <4>[ 574.475318] ? _die+0x23/0x70 <4>[ 574.475329] ? pagefaultoops+0x180/0x4c0 <4>[ 574.475339] ? skbppcowdata+0x34c/0x490 <4>[ 574.475346] ? kmemcachefree+0x257/0x280 <4>[ 574.475357] ? excpagefault+0x67/0x150 <4>[ 574.475368] ? asmexcpagefault+0x26/0x30 <4>[ 574.475381] ? bpfprog5e13354d9cf5018aprogafterredirect+0x17/0x3c <4>[ 574.475386] bqxmitall+0x158/0x420 <4>[ 574.475397] _devflush+0x30/0x90 <4>[ 574.475407] vethpoll+0x216/0x250 [veth] <4>[ 574.475421] _napipoll+0x28/0x1c0 <4>[ 574.475430] netrxaction+0x32d/0x3a0 <4>[ 574.475441] handlesoftirqs+0xcb/0x2c0 <4>[ 574.475451] dosoftirq+0x40/0x60 <4>[ 574.475458] </IRQ> <4>[ 574.475461] <TASK> <4>[ 574.475464] _localbhenableip+0x66/0x70 <4>[ 574.475471] _devqueuexmit+0x268/0xe40 <4>[ 574.475480] ? selinuxippostroute+0x213/0x420 <4>[ 574.475491] ? allocskbwithfrags+0x4a/0x1d0 <4>[ 574.475502] ip6finishoutput2+0x2be/0x640 <4>[ 574.475512] ? nfhookslow+0x42/0xf0 <4>[ 574.475521] ip6finishoutput+0x194/0x300 <4>[ 574.475529] ? _pfxip6finishoutput+0x10/0x10 <4>[ 574.475538] mldsendpack+0x17c/0x240 <4>[ 574.475548] mldifcwork+0x192/0x410 <4>[ 574.475557] processonework+0x15d/0x380 <4>[ 574.475566] workerthread+0x29d/0x3a0 <4>[ 574.475573] ? _pfxworkerthread+0x10/0x10 <4>[ 574.475580] ? _pfxworkerthread+0x10/0x10 <4>[ 574.475587] kthread+0xcd/0x100 <4>[ 574.475597] ? _pfxkthread+0x10/0x10 <4>[ 574.475606] retfromfork+0x31/0x50 <4>[ 574.475615] ? _pfxkthread+0x10/0x10 <4>[ 574.475623] retfromfork_asm+0x1a/0x ---truncated---(CVE-2024-50162)

In the Linux kernel, the following vulnerability has been resolved: fsl/fman: Fix refcount handling of fman-related devices In macprobe() there are multiple calls to offinddevicebynode(), fmanbind() and fmanportbind() which takes references to ofdev->dev. Not all references taken by these calls are released later on error path in macprobe() and in mac_remove() which lead to reference leaks. Add references release.(CVE-2024-50166)

In the Linux kernel, the following vulnerability has been resolved: vsock: Update rxbytes on readskb() Make sure virtiotransportincrxpkt() and virtiotransportdecrxpkt() calls are balanced (i.e. virtiovsocksock::rxbytes doesn't lie) after vsocktransport::readskb(). While here, also inform the peer that we've freed up space and it has more credit. Failing to update rxbytes after packet is dequeued leads to a warning on SOCKSTREAM recv(): [ 233.396654] rxqueue is empty, but rxbytes is non-zero [ 233.396702] WARNING: CPU: 11 PID: 40601 at net/vmwvsock/virtiotransportcommon.c:589(CVE-2024-50169)

In the Linux kernel, the following vulnerability has been resolved: net: bcmasp: fix potential memory leak in bcmaspxmit() The bcmaspxmit() returns NETDEVTXOK without freeing skb in case of mapping fails, add devkfreeskb() to fix it.(CVE-2024-50170)

In the Linux kernel, the following vulnerability has been resolved: net: systemport: fix potential memory leak in bcmsysportxmit() The bcmsysportxmit() returns NETDEVTXOK without freeing skb in case of dmamapsingle() fails, add devkfreeskb() to fix it.(CVE-2024-50171)

In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfdsecret() if arch cannot set direct map Return -ENOSYS from memfdsecret() syscall if !cansetdirectmap(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !cansetdirectmap(), setdirectmapinvalidnoflush() is a no-op, however it returns success (0) instead of an error. This means that memfdsecret will seemingly "work" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfdsecret() will start erroring on systems where cansetdirectmap() returns false (arm64 with CONFIGRODATAFULLDEFAULTENABLED=n, CONFIGDEBUGPAGEALLOC=n and CONFIGKFENCE=n), but that still seems better than the current silent failure. Since CONFIGRODATAFULLDEFAULTENABLED defaults to 'y', most arm64 systems actually have a working memfdsecret() and aren't be affected. From going through the iterations of the original memfdsecret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having setdirectmapinvalidnoflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/(CVE-2024-50182)

In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SBRDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SBRDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->sumount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SBRDONLY changing under its hands. Since these days we set EXT4FLAGSSHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that.(CVE-2024-50191)

In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmappcount, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmappcount common to both GICv4.1 and its v4.0 ancestor.(CVE-2024-50192)

In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pcclocksettime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tvsec and tvnsec range before calling ptp->info->settime64(). As the man manual of clocksettime() said, if tp.tvsec is negative or tp.tvnsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64valid(). As Thomas suggested, timespec64valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64validstrict() in pcclocksettime() and return -EINVAL if not valid. There are some drivers that use tp->tvsec and tp->tvnsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclgeptpsettime(), igbptpsettimei210(), rcargen4ptpsettime(), and some drivers can remove the checks of itself.(CVE-2024-50195)

In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Fix address emission with tag-based KASAN enabled When BPFTRAMPFCALLORIG is enabled, the address of a bpftrampimage struct on the stack is passed during the size calculation pass and an address on the heap is passed during code generation. This may cause a heap buffer overflow if the heap address is tagged because emita64movi64() will emit longer code than it did during the size calculation pass. The same problem could occur without tag-based KASAN if one of the 16-bit words of the stack address happened to be all-ones during the size calculation pass. Fix the problem by assuming the worst case (4 instructions) when calculating the size of the bpftramp_image address emission.(CVE-2024-50203)

In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in applyconstrainttosize() The step variable is initialized to zero. It is changed in the loop, but if it's not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b ("ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size"), and it is difficult to show that any of the interval parameters will satisfy the sndintervaltest() condition with data from the amdtprate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50205)

In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxtre: Fix a bug while setting up Level-2 PBL pages Avoid memory corruption while setting up Level-2 PBL pages for the non MR resources when numpages > 256K. There will be a single PDE page address (contiguous pages in the case of > PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid memory access after 256K PBL entries in the PDE.(CVE-2024-50208)

In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxtre: Add a check for memory allocation _alloc_pbl() can return error when memory allocation fails. Driver is not checking the status on one of the instances.(CVE-2024-50209)

In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfsfilestreampickag When the main loop in xfsfilestreampickag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory.(CVE-2024-50216)

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in _btrfsfreeextradevids() Mounting btrfs from two images (which have the same one fsid and two different devuuids) in certain executing order may trigger an UAF for variable 'device->bdevfile' in _btrfsfreeextradevids(). And following are the details: 1. Attach image1 to loop0, attach image2 to loop1, and scan btrfs devices by ioctl(BTRFSIOCSCANDEV): / btrfsdevice1 → loop0 fsdevice \ btrfsdevice2 → loop1 2. mount /dev/loop0 /mnt btrfsopendevices btrfsdevice1->bdevfile = btrfsgetbdevandsb(loop0) btrfsdevice2->bdevfile = btrfsgetbdevandsb(loop1) btrfsfillsuper openctree fail: btrfsclosedevices // -ENOMEM btrfsclosebdev(btrfsdevice1) fput(btrfsdevice1->bdevfile) // btrfsdevice1->bdevfile is freed btrfsclosebdev(btrfsdevice2) fput(btrfsdevice2->bdevfile) 3. mount /dev/loop1 /mnt btrfsopendevices btrfsgetbdevandsb(&bdevfile) // EIO, btrfsdevice1->bdevfile is not assigned, // which points to a freed memory area btrfsdevice2->bdevfile = btrfsgetbdevandsb(loop1) btrfsfillsuper openctree btrfsfreeextradevids if (btrfsdevice1->bdevfile) fput(btrfsdevice1->bdevfile) // UAF ! Fix it by setting 'device->bdevfile' as 'NULL' after closing the btrfsdevice in btrfscloseonedevice().(CVE-2024-50217)

In the Linux kernel, the following vulnerability has been resolved: sched/numa: Fix the potential null pointer dereference in tasknumawork() When running stress-ng-vm-segv test, we found a null pointer dereference error in tasknumawork(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vmamigratable+0x1c/0xd0 [323676.067122] lr : tasknumawork+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vmamigratable+0x1c/0xd0 [323676.067155] tasknumawork+0x1ec/0x4e0 [323676.067157] taskworkrun+0x78/0xd8 [323676.067161] donotifyresume+0x1ec/0x290 [323676.067163] el0svc+0x150/0x160 [323676.067167] el0t64synchandler+0xf8/0x128 [323676.067170] el0t64sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel... stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process. Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential tasknumawork() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vmanext() in tasknumawork() will return a null pointer even if the vma iterator restarts from 0. Recheck the vma pointer before dereferencing it in tasknuma_work().(CVE-2024-50223)

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, _blockwritebeginint(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the "checked" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.(CVE-2024-50230)

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: ilisr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965irqtasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RFKILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965irqtasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965macstart enter [ 12.052212] ieee80211 phy0: ilprepstation Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965sethwready hardware ready [ 12.052324] ieee80211 phy0: ilapminit Init card's basic functions [ 12.052348] ieee80211 phy0: ilapminit L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965loadbsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965verifybsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965verifybsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965loadbsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: _il4965up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965macstart Start UP work done. [ 12.058757] ieee80211 phy0: _il4965down iwl4965 is going down [ 12.058761] ieee80211 phy0: ilscancanceltimeout Scan cancel timeout [ 12.058762] ieee80211 phy0: ildoscanabort Not performing scan to abort [ 12.058765] ieee80211 phy0: ilclearucodestations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: ilclearucodestations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _ilapmstop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _ilapmstopmaster stop master [ 12.058864] ieee80211 phy0: il4965clearfreeframes 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: STARTALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm schfqcodel xttcpudp xtmultiport xtstate iptablefilter iptablenat nfnat nfconntrack nfdefragipv4 iptables xtables binfmtmisc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdhgeneric ecc iTCOwdt i2cdev iwl4965 iwlegacy coretemp sndhdacodecanalog pcspkr psmouse mac80211 sndhdacodecgeneric libarc4 sdhcipci cqhci sha256generic sdhci libsha256 firewireohci sndhdaintel sndinteldspcfg mmccore sndhdacodec sndhwdep firewirecore ledclass iosfmbi sndhdacore uhcihcd lpcich crcitut cfg80211 ehcipci ehcihcd sndpcm usbcore mfdcore rfkill sndtimer snd usbcommon soundcore video parportpc parport intelagp wmi intelgtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async asyncrunentryfn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---(CVE-2024-50234)

In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [<ffffffe6e7b245dc>] _kmemcacheallocnode+0x1e4/0x2d8 [<ffffffe6e7adde88>] kmalloctrace+0x48/0x110 [<ffffffe6bbd765fc>] ath10kwmitlvopgenmgmttxsend+0xd4/0x1d8 [ath10kcore] [<ffffffe6bbd3eed4>] ath10kmgmtoverwmitxwork+0x134/0x298 [ath10kcore] [<ffffffe6e78d5974>] processscheduledworks+0x1ac/0x400 [<ffffffe6e78d60b8>] workerthread+0x208/0x328 [<ffffffe6e78dc890>] kthread+0x100/0x1c0 [<ffffffe6e78166c0>] retfromfork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmtpendingtx idrremove() operation in ath10kwmitlvopcleanupmgmttxsend() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1(CVE-2024-50236)

In the Linux kernel, the following vulnerability has been resolved: NFSD: Initialize struct nfsd4copy earlier Ensure the refcount and asynccopies fields are initialized early. cleanupasynccopy() will reference these fields if an error occurs in nfsd4_copy(). If they are not correctly initialized, at the very least, a refcount underflow occurs.(CVE-2024-50241)

In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mienumattr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.(CVE-2024-50248)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci: fix null-ptr-deref in hcireadsupportedcodecs Fix _hcicmdsyncsk() to return not NULL for unknown opcodes. _hcicmdsyncsk() returns NULL if a command returns a status event. However, it also returns NULL where an opcode doesn't exist in the hcicc table because hcicmdcompleteevt() assumes status = skb->data[0] for unknown opcodes. This leads to null-ptr-deref in cmdsync for HCIOPREADLOCALCODECS as there is no hcicc for HCIOPREADLOCALCODECS, which always assumes status = skb->data[0]. KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hcipoweron RIP: 0010:hcireadsupportedcodecs+0xb9/0x870 net/bluetooth/hcicodec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> hcireadlocalcodecssync net/bluetooth/hcisync.c:4546 [inline] hciinitstagesync net/bluetooth/hcisync.c:3441 [inline] hciinit4sync net/bluetooth/hcisync.c:4706 [inline] hciinitsync net/bluetooth/hcisync.c:4742 [inline] hcidevinitsync net/bluetooth/hcisync.c:4912 [inline] hcidevopensync+0x19a9/0x2d30 net/bluetooth/hcisync.c:4994 hcidevdoopen net/bluetooth/hcicore.c:483 [inline] hcipoweron+0x11e/0x560 net/bluetooth/hcicore.c:1015 processonework kernel/workqueue.c:3267 [inline] processscheduledworks+0x8ef/0x14f0 kernel/workqueue.c:3348 workerthread+0x91f/0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 retfromfork+0x4d/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244(CVE-2024-50255)

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: bpf: Fix out-of-bounds write in triegetnextkey() triegetnextkey() allocates a node stack with size trie->maxprefixlen, while it writes (trie->maxprefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with maxprefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to triegetnextkey with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.(CVE-2024-50262)

In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2xaremove() Syzkaller is able to provoke null-ptr-dereference in ocfs2xaremove(): [ 57.319872] (a.out,1161,7):ocfs2xaremove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2xacleanupvaluetruncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2xablockwipenamevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] <TASK> [...] [ 57.333511] ? douseraddrfault+0x3e5/0x740 [ 57.333778] ? excpagefault+0x70/0x170 [ 57.334016] ? asmexcpagefault+0x2b/0x30 [ 57.334263] ? _pfxocfs2xablockwipenamevalue+0x10/0x10 [ 57.334596] ? ocfs2xablockwipenamevalue+0x2a/0xc0 [ 57.334913] ocfs2xaremoveentry+0x23/0xc0 [ 57.335164] ocfs2xaset+0x704/0xcf0 [ 57.335381] ? _rawspinunlock+0x1a/0x40 [ 57.335620] ? ocfs2inodecacheunlock+0x16/0x20 [ 57.335915] ? tracepreempton+0x1e/0x70 [ 57.336153] ? startthishandle+0x16c/0x500 [ 57.336410] ? preemptcountsub+0x50/0x80 [ 57.336656] ? rawreadunlock+0x20/0x40 [ 57.336906] ? startthishandle+0x16c/0x500 [ 57.337162] ocfs2xattrblockset+0xa6/0x1e0 [ 57.337424] _ocfs2xattrsethandle+0x1fd/0x5d0 [ 57.337706] ? ocfs2starttrans+0x13d/0x290 [ 57.337971] ocfs2xattrset+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2xattrtrustedset+0x28/0x30 [ 57.338665] ? ocfs2xattrtrustedset+0x28/0x30 [ 57.338948] _vfsremovexattr+0x92/0xc0 [ 57.339182] _vfsremovexattrlocked+0xd5/0x190 [ 57.339456] ? preemptcountsub+0x50/0x80 [ 57.339705] vfsremovexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2xaremove() -> ocfs2xavaluetruncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2xacleanupvaluetruncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2xaremoveentry(loc);' twice: * 1st: in ocfs2xacleanupvaluetruncate(); * 2nd: returning back to ocfs2xaremove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.(CVE-2024-50265)

In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY on exit") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunximusbdriver // get the usb phy @glue->xceiv sunximusbprobe() -> devmusbgetphy(). 2) register and unregister platform driver @musbdriver musbprobe() -> sunximusbinit() use the phy here //the phy is released here musbremove() -> sunximusbexit() -> devmusbputphy() 3) register @musbdriver again musbprobe() -> sunximusbinit() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devmusbputphy() from sunximusbexit().(CVE-2024-50269)

In the Linux kernel, the following vulnerability has been resolved: signal: restore the overriderlimit logic Prior to commit d64696905554 ("Reimplement RLIMITSIGPENDING on top of ucounts") UCOUNTRLIMITSIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if overriderlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueuealloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing overriderlimit into incrlimitgetucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior.(CVE-2024-50271)

In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemapread() If the caller supplies an iocb->kipos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the "localio" optimisation for loopback NFS mounts.(CVE-2024-50272)

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: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIFSVE set and TIFFOREIGNFPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from dosveacc() where SVE traps are not expected while TIFSVE is set: | if (testandsetthreadflag(TIFSVE)) | WARNON(1); /* SVE access shouldn't have trapped / Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIF_FOREIGN_FPSTATE is set. | | get_cpu_fpsimd_context(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); / SVE access shouldn't have trapped */ | | sveinitregs() { | if (!testthreadflag(TIFFOREIGNFPSTATE)) { | ... | } else { | fpsimdtosve(current); | current->thread.fptype = FPSTATESVE; | } | } | | putcpufpsimdcontext(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimdcpu is still 0 | // If percpuptr(&fpsimdlaststate, 0) is still task then: | // - Stale HW state is reused (with SVE traps enabled) | // - TIFFOREIGNFPSTATE is cleared | // - A return to userspace skips HW state restore | } Fix the case where the state is not live and TIFFOREIGNFPSTATE is set by calling fpsimdflushtaskstate() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIFFOREIGNFPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace.(CVE-2024-50275)

In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102xtxframespi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102xtxwork(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102xtxwork [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skbreleasedata+0xb8/0x1d8 lr : skbreleasedata+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skbreleasedata+0xb8/0x1d8 kfreeskbreason+0x48/0xb0 mse102xtxwork+0x164/0x35c [mse102x] processonework+0x138/0x260 workerthread+0x32c/0x438 kthread+0x118/0x11c retfromfork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)(CVE-2024-50276)

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3preauthhashrsp ksmbdusersessionput should be called under smb3preauthhashrsp(). It will avoid freeing session before calling smb3preauthhashrsp().(CVE-2024-50283)

In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix the missing xastore error check xastore() can fail, it return xaerr(-EINVAL) if the entry cannot be stored in an XArray, or xaerr(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.(CVE-2024-50284)

In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: drivers/staging/media/av7110/av7110ca.c:270 dvbcaioctl() warn: potential spectre issue 'av7110->cislot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.(CVE-2024-50289)

In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing locking causing hanging calls If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->newclientcalls by rxrpcdisconnectclientcall() without a lock being held. This may cause other calls on the list to disappear if a race occurs. Fix this by taking the clientcalllock when removing a call from whatever list its ->waitlink happens to be on.(CVE-2024-50294)

In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vfstate during PF probes In the previous implementation, vfstate is allocated memory only when VF is enabled. However, netdeviceops::ndosetvfmac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetcpfsetvfmac() will access vfstate, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetcpfsetvfmac+0x3c/0x80 Message from sy [ 173.641973] lr : dosetlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetcpfsetvfmac+0x3c/0x80 [ 173.738847] _rtnlnewlink+0x530/0x89c [ 173.742692] rtnlnewlink+0x50/0x7c [ 173.746189] rtnetlinkrcvmsg+0x128/0x390 [ 173.750298] netlinkrcvskb+0x60/0x130 [ 173.754145] rtnetlinkrcv+0x18/0x24 [ 173.757731] netlinkunicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8(CVE-2024-50298)

In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctpsfootb() A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add size validation when walking chunks") is also required in sctpsfootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctpsfootb+0x7f5/0xce0 net/sctp/smstatefuns.c:3712 sctpsfootb+0x7f5/0xce0 net/sctp/smstatefuns.c:3712 sctpdosm+0x181/0x93d0 net/sctp/smsideeffect.c:1166 sctpendpointbhrcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctpinqpush+0x2ef/0x380 net/sctp/inqueue.c:88 sctprcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4rcv+0x42/0x50 net/sctp/protocol.c:1159 ipprotocoldeliverrcu+0xb51/0x13d0 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x336/0x500 net/ipv4/ipinput.c:233(CVE-2024-50299)

In the Linux kernel, the following vulnerability has been resolved: mctp i2c: handle NULL header address daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped. saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.(CVE-2024-53043)

In the Linux kernel, the following vulnerability has been resolved: arm64: dts: imx8ulp: correct the flexspi compatible string The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxpfspiexecop+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxpfspiexecop+0xb04/0xb64 [ 1.163496] lr : nxpfspiexecop+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxpfspiexecop+0xb04/0xb64 [ 1.253031] spimemexecop+0x3a0/0x430 [ 1.257139] spinorreadid+0x80/0xcc [ 1.261065] spinorscan+0x1ec/0xf10 [ 1.264901] spinorprobe+0x108/0x2fc [ 1.268828] spimemprobe+0x6c/0xbc [ 1.272574] spiprobe+0x84/0xe4 [ 1.275958] reallyprobe+0xbc/0x29c [ 1.279713] _driverprobedevice+0x78/0x12c [ 1.284277] driverprobedevice+0xd8/0x15c [ 1.288660] _deviceattachdriver+0xb8/0x134 [ 1.293316] busforeachdrv+0x88/0xe8 [ 1.297337] _deviceattach+0xa0/0x190 [ 1.301353] deviceinitialprobe+0x14/0x20 [ 1.305734] busprobedevice+0xac/0xb0 [ 1.309752] deviceadd+0x5d0/0x790 [ 1.313408] _spiadddevice+0x134/0x204 [ 1.317606] ofregisterspidevice+0x3b4/0x590 [ 1.322348] spiregistercontroller+0x47c/0x754 [ 1.327181] devmspiregistercontroller+0x4c/0xa4 [ 1.332289] nxpfspiprobe+0x1cc/0x2b0 [ 1.336307] platformprobe+0x68/0xc4 [ 1.340145] reallyprobe+0xbc/0x29c [ 1.343893] _driverprobedevice+0x78/0x12c [ 1.348457] driverprobedevice+0xd8/0x15c [ 1.352838] _driverattach+0x90/0x19c [ 1.356857] busforeachdev+0x7c/0xdc [ 1.360877] driverattach+0x24/0x30 [ 1.364624] busadddriver+0xe4/0x208 [ 1.368552] driverregister+0x5c/0x124 [ 1.372573] _platformdriverregister+0x28/0x34 [ 1.377497] nxpfspidriverinit+0x1c/0x28 [ 1.381888] dooneinitcall+0x80/0x1c8 [ 1.385908] kernelinitfreeable+0x1c4/0x28c [ 1.390472] kernelinit+0x20/0x1d8 [ 1.394138] retfromfork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------(CVE-2024-53046)

In the Linux kernel, the following vulnerability has been resolved: mptcp: init: protect sched with rcureadlock Enabling CONFIGPROVERCULIST with its dependence CONFIGRCUEXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcuscheduleractive = 2, debuglocks = 1 no locks held by mptcpconnect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcpconnect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:123) lockdeprcususpicious (kernel/locking/lockdep.c:6822) mptcpschedfind (net/mptcp/sched.c:44 (discriminator 7)) mptcpinitsock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sockinitdatauid (arch/x86/include/asm/atomic.h:28) inetcreate.part.0.constprop.0 (net/ipv4/afinet.c:386) ? sockcreate (include/linux/rcupdate.h:347 (discriminator 1)) _sockcreate (net/socket.c:1576) _syssocket (net/socket.c:1671) ? _pfxsyssocket (net/socket.c:1712) ? douseraddrfault (arch/x86/mm/fault.c:1419 (discriminator 1)) _x64syssocket (net/socket.c:1728) dosyscall64 (arch/x86/entry/common.c:52 (discriminator 1)) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) That's because when the socket is initialised, rcureadlock() is not used despite the explicit comment written above the declaration of mptcpsched_find() in sched.c. Adding the missing lock/unlock avoids the warning.(CVE-2024-53047)

In the Linux kernel, the following vulnerability has been resolved: iouring/rw: fix missing NOWAIT check for ODIRECT start write When iouring starts a write, it'll call kiocbstartwrite() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But iouring unconditionally uses kiocbstartwrite(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: _switchto+0x1d8/0x348 _schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpurwsemwait+0x1e8/0x3f8 _percpudownread+0xe8/0x500 iowrite+0xbb8/0xff8 ioissuesqe+0x10c/0x1020 iosubmitsqes+0x614/0x2110 _arm64sysiouringenter+0x524/0x1038 invokesyscall+0x74/0x268 el0svccommon.constprop.0+0x160/0x238 doel0svc+0x44/0x60 el0svc+0x44/0xb0 el0t64synchandler+0x118/0x128 el0t64sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: _switchto+0x1d8/0x348 _schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpudownwrite+0x2b0/0x680 freezesuper+0x248/0x8a8 dovfsioctl+0x149c/0x1b18 _arm64sysioctl+0xd0/0x1a0 invokesyscall+0x74/0x268 el0svccommon.constprop.0+0x160/0x238 doel0svc+0x44/0x60 el0svc+0x44/0xb0 el0t64synchandler+0x118/0x128 el0t64sync+0x168/0x170 Fix this by having the iouring side honor IOCBNOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCBNOWAIT would always be set, this returns -EAGAIN which will have iouring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAPSYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.(CVE-2024-53052)

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.(CVE-2024-53055)

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: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIGDVBDYNAMICMINORS is set or not. When not set, dvbregisterdevice() won't check for boundaries, as it will rely that a previous call to dvbregisteradapter() would already be enforcing it. On a similar way, dvbdevice_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.(CVE-2024-53063)

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)

In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iiogtsbuildavailscaletable() If pertimescales[i] or pertimegains[i] kcalloc fails in the for loop of iiogtsbuildavailscaletable(), the errfreeout will fail to call kfree() each time when i is reduced to 0, so all the pertimescales[0] and pertimegains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0.(CVE-2024-53076)

In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: init value of hdrlen/txbuflen earlier If the read of USBPDPHYRXACKNOWLEDGEREG failed, then hdrlen and txbuflen are uninitialized. This commit stops to print uninitialized value and misleading/false data.(CVE-2024-53083)

In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpmpmsuspend() first Setting TPMCHIPFLAGSUSPENDED in the end of tpmpmsuspend() can be racy according, as this leaves window for tpmhwrngread() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpmpmsuspend() and tpmhwrngread(). Move TPMCHIPFLAGSUSPENDED check inside tpmgetrandom() so that it will be always checked only when the lock is reserved.(CVE-2024-53085)

In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f ("KVM: LAPIC: Mark hrtimer to expire in hard interrupt context") and commit 9090825fa9974 ("KVM: arm/arm64: Let the timer expire in hardirq context on RT"), On PREEMPTRT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPTRT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a "scheduling while atomic" bug for PREEMPTRT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct nftchainnat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] showstack+0x38/0x180 [<9000000004e3ea34>] dumpstacklvl+0x84/0xc0 [<9000000003a71708>] _schedulebug+0x48/0x60 [<9000000004e45734>] _schedule+0x1114/0x1660 [<9000000004e46040>] schedulertlock+0x20/0x60 [<9000000004e4e330>] rtlockslowlocklocked+0x3f0/0x10a0 [<9000000004e4f038>] rtspinlock+0x58/0x80 [<9000000003b02d68>] hrtimercancelwaitrunning+0x68/0xc0 [<9000000003b02e30>] hrtimercancel+0x70/0x80 [<ffff80000235eb70>] kvmrestoretimer+0x50/0x1a0 [kvm] [<ffff8000023616c8>] kvmarchvcpuload+0x68/0x2a0 [kvm] [<ffff80000234c2d4>] kvmschedin+0x34/0x60 [kvm] [<9000000003a749a0>] finishtaskswitch.isra.0+0x140/0x2e0 [<9000000004e44a70>] _schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [<ffff800002354c70>] kvmvcpublock+0x70/0x120 [kvm] [<ffff800002354d80>] kvmvcpuhalt+0x60/0x3e0 [kvm] [<ffff80000235b194>] kvmhandlegspr+0x3f4/0x4e0 [kvm] [<ffff80000235f548>] kvmhandle_exit+0x1c8/0x260 kvm