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:

wifi: mac80211: fix NULL dereference at band check in starting tx ba session

In MLD connection, linkdata/linkconf are dynamically allocated. They don't point to vif->bssconf. So, there will be no chanreq assigned to vif->bssconf and then the chan will be NULL. Tweak the code to check htsupported/vhtsupported/hashe/haseht on sta deflink.

Crash log (with rtw89 version under MLO development): [ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 9890.526102] #PF: supervisor read access in kernel mode [ 9890.526105] #PF: errorcode(0x0000) - not-present page [ 9890.526109] PGD 0 P4D 0 [ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI [ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G OE 6.9.0 #1 [ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018 [ 9890.526126] Workqueue: phy2 rtw89corebawork [rtw89core] [ 9890.526203] RIP: 0010:ieee80211starttxba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211 [ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 <83> 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3

All code

0: f7 e8 imul %eax 2: d5 (bad) 3: 93 xchg %eax,%ebx 4: 3e ea ds (bad) 6: 48 83 c4 28 add $0x28,%rsp a: 89 d8 mov %ebx,%eax c: 5b pop %rbx d: 41 5c pop %r12 f: 41 5d pop %r13 11: 41 5e pop %r14 13: 41 5f pop %r15 15: 5d pop %rbp 16: c3 retq 17: cc int3 18: cc int3 19: cc int3 1a: cc int3 1b: 49 8b 84 24 e0 f1 ff mov -0xe20(%r12),%rax 22: ff 23: 48 8b 80 90 1b 00 00 mov 0x1b90(%rax),%rax 2a:* 83 38 03 cmpl $0x3,(%rax) <-- trapping instruction 2d: 0f 84 37 fe ff ff je 0xfffffffffffffe6a 33: bb ea ff ff ff mov $0xffffffea,%ebx 38: eb cc jmp 0x6 3a: 49 rex.WB 3b: 8b .byte 0x8b 3c: 84 24 10 test %ah,(%rax,%rdx,1) 3f: f3 repz

Code starting with the faulting instruction

0: 83 38 03 cmpl $0x3,(%rax) 3: 0f 84 37 fe ff ff je 0xfffffffffffffe40 9: bb ea ff ff ff mov $0xffffffea,%ebx e: eb cc jmp 0xffffffffffffffdc 10: 49 rex.WB 11: 8b .byte 0x8b 12: 84 24 10 test %ah,(%rax,%rdx,1) 15: f3 repz [ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246 [ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8 [ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685 [ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873 [ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70 [ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000 [ 9890.526313] FS: 0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000 [ 9890.526316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0 [ 9890.526321] Call Trace: [ 9890.526324] <TASK> [ 9890.526327] ? showregs (arch/x86/kernel/dumpstack.c:479) [ 9890.526335] ? _die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 9890.526340] ? pagefaultoops (arch/x86/mm/fault.c:713) [ 9890.526347] ? searchmoduleextables (kernel/module/main.c:3256 (discriminator ---truncated---(CVE-2024-43911)

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

staging: iio: frequency: ad9834: Validate frequency parameter value

In ad9834writefrequency() clkgetrate() can return 0. In such case ad9834calcfreqreg() call will lead to division by zero. Checking 'if (fout > (clkfreq / 2))' doesn't protect in case of 'fout' is 0. ad9834writefrequency() is called from ad9834write(), where fout is taken from text buffer, which can contain any value.

Modify parameters checking.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47663)

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

scsi: pm80xx: Set phy->enable_completion only when we wait for it

pm8001phycontrol() populates the enablecompletion pointer with a stack address, sends a PHYLINKRESET / PHYHARDRESET, waits 300 ms, and returns. The problem arises when a phy control response comes late. After 300 ms the pm8001phycontrol() function returns and the passed enablecompletion stack address is no longer valid. Late phy control response invokes complete() on a dangling enable_completion pointer which leads to a kernel crash.(CVE-2024-47666)

In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARGPTRTO{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARGPTRTO{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAPPERFMON can already read all kernel memory anyway hence bpfgetfuncarg() and bpfgetfuncret() is skipped in here. Also, the MTU helpers mtulen pointer value is being written but also read. Technically, the MEMUNINIT should not be there in order to always force init. Removing MEMUNINIT needs more verifier rework though: MEMUNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEMUNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf*checkmtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEMUNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.(CVE-2024-47728)

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: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.(CVE-2024-49945)

In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpifirmwarepropertylist() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQFNOSUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpifirmwarepropertylist+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwindbacktrace from showstack+0x18/0x1c showstack from dumpstacklvl+0x34/0x44 dumpstacklvl from _warn+0x88/0xec _warn from warnslowpathfmt+0x7c/0xb0 warnslowpathfmt from rpifirmwarepropertylist+0x204/0x22c rpifirmwarepropertylist from rpifirmwareproperty+0x68/0x8c rpifirmwareproperty from rpifirmwaresetpower+0x54/0xc0 rpifirmwaresetpower from _genpdpoweroff+0xe4/0x148 _genpdpoweroff from genpdsyncpoweroff+0x7c/0x11c genpdsyncpoweroff from genpdfinishsuspend+0xcc/0xe0 genpdfinishsuspend from dpmruncallback+0x78/0xd0 dpmruncallback from devicesuspendnoirq+0xc0/0x238 devicesuspendnoirq from dpmsuspendnoirq+0xb0/0x168 dpmsuspendnoirq from suspenddevicesandenter+0x1b8/0x5ac suspenddevicesandenter from pmsuspend+0x254/0x2e4 pmsuspend from statestore+0xa8/0xd4 statestore from kernfsfopwriteiter+0x154/0x1a0 kernfsfopwriteiter from vfswrite+0x12c/0x184 vfswrite from ksyswrite+0x78/0xc0 ksyswrite from retfast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs(CVE-2024-49963)

In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 ("aoe: fix the potential use-after-free problem in aoecmdcfgpkts") makes tx() calling devput() instead of doing in aoecmdcfgpkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmdatarw(), resend(), probe() and aoecmdcfgrsp(). Those functions also use aoenetxmit() to push packet to tx queue. So they should also use devhold() to increase the refcnt of skb->dev. On the other hand, moving devput() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding devhold() are not called in revalidate(), aoecmdatarw(), resend(), probe(), and aoecmdcfg_rsp(). This patch fixed this issue.(CVE-2024-49982)

In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken.(CVE-2024-50115)

In the Linux kernel, the following vulnerability has been resolved: bpf: Use rawspinlockt in ringbuf The function _bpfringbufreserve is invoked from a tracepoint, which disables preemption. Using spinlockt in this context can lead to a "sleep in atomic" warning in the RT variant. This issue is illustrated in the example below: BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 556208, name: testprogs preemptcount: 1, expected: 0 RCU nest depth: 1, expected: 1 INFO: lockdep is turned off. Preemption disabled at: [<ffffd33a5c88ea44>] migrateenable+0xc0/0x39c CPU: 7 PID: 556208 Comm: testprogs Tainted: G Hardware name: Qualcomm SA8775P Ride (DT) Call trace: dumpbacktrace+0xac/0x130 showstack+0x1c/0x30 dumpstacklvl+0xac/0xe8 dumpstack+0x18/0x30 _mightresched+0x3bc/0x4fc rtspinlock+0x8c/0x1a4 _bpfringbufreserve+0xc4/0x254 bpfringbufreservedynptr+0x5c/0xdc bpfprogac3d15160d62622atestreadwrite+0x104/0x238 tracecallbpf+0x238/0x774 perfcallbpfenter.isra.0+0x104/0x194 perfsyscallenter+0x2f8/0x510 tracesysenter+0x39c/0x564 syscalltraceenter+0x220/0x3c0 doel0svc+0x138/0x1dc el0svc+0x54/0x130 el0t64synchandler+0x134/0x150 el0t64sync+0x17c/0x180 Switch the spinlock to rawspinlock_t to avoid this error.(CVE-2024-50138)

(CVE-2024-50151)

In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix null-ptr-deref in targetallocdevice() There is a null-ptr-deref issue reported by KASAN: BUG: KASAN: null-ptr-deref in targetallocdevice+0xbc4/0xbe0 [targetcoremod] ... kasanreport+0xb9/0xf0 targetallocdevice+0xbc4/0xbe0 [targetcoremod] coredevsetupvirtuallun0+0xef/0x1f0 [targetcoremod] targetcoreinitconfigfs+0x205/0x420 [targetcoremod] dooneinitcall+0xdd/0x4e0 ... entrySYSCALL64afterhwframe+0x76/0x7e In targetallocdevice(), if allocing memory for dev queues fails, then dev will be freed by dev->transport->freedevice(), but dev->transport is not initialized at that time, which will lead to a null pointer reference problem. Fixing this bug by freeing dev with hba->backend->ops->freedevice().(CVE-2024-50153)

In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the inilluminanceperiodavailableshow function references the device embedded in the IIO device, not in the i2c client. devtoiiodev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indiodev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.(CVE-2024-50198)

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: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data(CVE-2024-50237)

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfsfilerelease(CVE-2024-50242)

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in niclear() Checking of NTFSFLAGSLOGREPLAYING added to prevent access to uninitialized bitmap during replay process.(CVE-2024-50244)

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in miread Mutex lock with another subclass used in nilock_dir().(CVE-2024-50245)

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check(CVE-2024-50246)

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNTCHUNKSIZE bytes and a index out of bounds will occur in smaxoff.(CVE-2024-50247)