The Linux Kernel, the operating system core itself.

Security Fix(es):

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

Bluetooth: hci_qca: Fix driver shutdown on closed serdev

The driver shutdown callback (which sends EDLSOCRESET to the device over serdev) should not be invoked when HCI device is not open (e.g. if hcidevopensync() failed), because the serdev and its TTY are not open either. Also skip this step if device is powered off (qcapower_shutdown()).

The shutdown callback causes use-after-free during system reboot with Qualcomm Atheros Bluetooth:

Unable to handle kernel paging request at virtual address 0072662f67726fd7 ... CPU: 6 PID: 1 Comm: systemd-shutdow Tainted: G W 6.1.0-rt5-00325-g8a5f56bcfcca #8 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: ttydriverflushbuffer+0x4/0x30 serdevdevicewriteflush+0x24/0x34 qcaserdevshutdown+0x80/0x130 [hciuart] deviceshutdown+0x15c/0x260 kernel_restart+0x48/0xac

KASAN report:

BUG: KASAN: use-after-free in ttydriverflush_buffer+0x1c/0x50 Read of size 8 at addr ffff16270c2e0018 by task systemd-shutdow/1

CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted 6.1.0-next-20221220-00014-gb85aaf97fb01-dirty #28 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dumpbacktrace.part.0+0xdc/0xf0 showstack+0x18/0x30 dumpstacklvl+0x68/0x84 printreport+0x188/0x488 kasanreport+0xa4/0xf0 _asanload8+0x80/0xac ttydriverflushbuffer+0x1c/0x50 ttyportwriteflush+0x34/0x44 serdevdevicewriteflush+0x48/0x60 qcaserdevshutdown+0x124/0x274 deviceshutdown+0x1e8/0x350 kernelrestart+0x48/0xb0 _dosysreboot+0x244/0x2d0 _arm64sysreboot+0x54/0x70 invokesyscall+0x60/0x190 el0svccommon.constprop.0+0x7c/0x160 doel0svc+0x44/0xf0 el0svc+0x2c/0x6c el0t64synchandler+0xbc/0x140 el0t64_sync+0x190/0x194(CVE-2022-48878)

In the Linux kernel, the following vulnerability has been resolved: rtc: cmos: Fix event handler registration ordering issue Because acpiinstallfixedeventhandler() enables the event automatically on success, it is incorrect to call it before the handler routine passed to it is ready to handle events. Unfortunately, the rtc-cmos driver does exactly the incorrect thing by calling cmoswakesetup(), which passes rtchandler() to acpiinstallfixedeventhandler(), before cmosdoprobe(), because rtchandler() uses devgetdrvdata() to get to the cmos object pointer and the driver data pointer is only populated in cmosdoprobe(). This leads to a NULL pointer dereference in rtchandler() on boot if the RTC fixed event happens to be active at the init time. To address this issue, change the initialization ordering of the driver so that cmoswakesetup() is always called after a successful cmosdoprobe() call. While at it, change cmospnpprobe() to call cmosdoprobe() after the initial if () statement used for computing the IRQ argument to be passed to cmosdoprobe() which is cleaner than calling it in each branch of that if () (local variable "irq" can be of type int, because it is passed to that function as an argument of type int). Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPIFADTLOWPOWERS0") caused this issue to affect a larger number of systems, because previously it only affected systems with ACPIFADTLOWPOWER_S0 set, but it is present regardless of that commit.(CVE-2022-48953)

In the Linux kernel, the following vulnerability has been resolved: e100: Fix possible use after free in e100xmitprepare In e100xmitprepare(), if we can't map the skb, then return -ENOMEM, so e100xmitframe() will return NETDEVTXBUSY and the upper layer will resend the skb. But the skb is already freed, which will cause UAF bug when the upper layer resends the skb. Remove the harmful free.(CVE-2022-49026)

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

dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA

This dmaalloccoherent() is undone neither in the remove function, nor in the error handling path of fslqdmaprobe().

Switch to the managed version to fix both issues.(CVE-2024-35833)

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

netfilter: nf_tables: honor table dormant flag from netdev release event path

Check for table dormant flag otherwise netdev release event path tries to unregister an already unregistered hook.

[524854.857999] ------------[ cut here ]------------ [524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 nfunregisternethook+0x21a/0x260 [...] [524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365 [524854.858869] Workqueue: netns cleanupnet [524854.858886] RIP: 0010:nfunregisternethook+0x21a/0x260 [524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41 [524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246 [524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a [524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438 [524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34 [524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005 [524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00 [524854.858971] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0 [524854.859000] Call Trace: [524854.859006] <TASK> [524854.859013] ? _warn+0x9f/0x1a0 [524854.859027] ? _nfunregisternethook+0x21a/0x260 [524854.859044] ? reportbug+0x1b1/0x1e0 [524854.859060] ? handlebug+0x3c/0x70 [524854.859071] ? excinvalidop+0x17/0x40 [524854.859083] ? asmexcinvalidop+0x1a/0x20 [524854.859100] ? _nfunregisternethook+0x6a/0x260 [524854.859116] ? _nfunregisternethook+0x21a/0x260 [524854.859135] nftablesnetdevevent+0x337/0x390 [nftables] [524854.859304] ? _pfxnftablesnetdevevent+0x10/0x10 [nftables] [524854.859461] ? packetnotifier+0xb3/0x360 [524854.859476] ? rawspinunlockirqrestore+0x11/0x40 [524854.859489] ? dcbnlnetdeviceevent+0x35/0x140 [524854.859507] ? _pfxnftablesnetdevevent+0x10/0x10 [nftables] [524854.859661] notifiercallchain+0x7d/0x140 [524854.859677] unregisternetdevicemany_notify+0x5e1/0xae0(CVE-2024-36005)

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

firewire: ohci: mask bus reset interrupts between ISR and bottom half

In the FireWire OHCI interrupt handler, if a bus reset interrupt has occurred, mask bus reset interrupts until busresetwork has serviced and cleared the interrupt.

Normally, we always leave bus reset interrupts masked. We infer the bus reset from the self-ID interrupt that happens shortly thereafter. A scenario where we unmask bus reset interrupts was introduced in 2008 in a007bb857e0b26f5d8b73c2ff90782d9c0972620: If OHCIPARAMDEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we will unmask bus reset interrupts so we can log them.

irqhandler logs the bus reset interrupt. However, we can't clear the bus reset event flag in irqhandler, because we won't service the event until later. irqhandler exits with the event flag still set. If the corresponding interrupt is still unmasked, the first bus reset will usually freeze the system due to irqhandler being called again each time it exits. This freeze can be reproduced by loading firewireohci with "modprobe firewireohci debug=-1" (to enable all debugging output). Apparently there are also some cases where busresetwork will get called soon enough to clear the event, and operation will continue normally.

This freeze was first reported a few months after a007bb85 was committed, but until now it was never fixed. The debug level could safely be set to -1 through sysfs after the module was loaded, but this would be ineffectual in logging bus reset interrupts since they were only unmasked during initialization.

irqhandler will now leave the event flag set but mask bus reset interrupts, so irqhandler won't be called again and there will be no freeze. If OHCIPARAMDEBUGBUSRESETS is enabled, busreset_work will unmask the interrupt after servicing the event, so future interrupts will be caught as desired.

As a side effect to this change, OHCIPARAMDEBUGBUSRESETS can now be enabled through sysfs in addition to during initial module loading. However, when enabled through sysfs, logging of bus reset interrupts will be effective only starting with the second bus reset, after busreset_work has executed.(CVE-2024-36950)

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: arm64: probes: Remove broken LDR (literal) uprobe support The simulateldrliteral() and simulateldrswliteral() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulateldrliteral() nor simulateldrswliteral() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulateldrliteral() and simulateldrswliteral() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as armprobedecodeinsn() will return INSNREJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.(CVE-2024-50099)

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)

In the Linux kernel, the following vulnerability has been resolved: virtiopmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtiopmemflush(), causing the system to hang. So add a status check in the beginning of virtiopmem_flush() to return early if the device is not activated.(CVE-2024-50184)

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: 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: 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: 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)