OESA-2024-1765

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

spi: Fix deadlock when adding SPI controllers on SPI buses

Currently we have a global spiaddlock which we take when adding new devices so that we can check that we're not trying to reuse a chip select that's already controlled. This means that if the SPI device is itself a SPI controller and triggers the instantiation of further SPI devices we trigger a deadlock as we try to register and instantiate those devices while in the process of doing so for the parent controller and hence already holding the global spiaddlock. Since we only care about concurrency within a single SPI bus move the lock to be per controller, avoiding the deadlock.

This can be easily triggered in the case of spi-mux.(CVE-2021-47469)

(CVE-2023-39180)

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

hid: cp2112: Fix duplicate workqueue initialization

Previously the cp2112 driver called INITDELAYEDWORK within cp2112gpioirqstartup, resulting in duplicate initilizations of the workqueue on subsequent IRQ startups following an initial request. This resulted in a warning in setworkdata in workqueue.c, as well as a rare NULL dereference within processone_work in workqueue.c.

Initialize the workqueue within _probe instead.(CVE-2023-52853)

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

ksmbd: fix UAF issue in ksmbdtcpnew_connection()

The race is between the handling of a new TCP connection and its disconnection. It leads to UAF on struct tcp_transport in ksmbdtcpnew_connection() function.(CVE-2024-26592)

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

netfilter: nftables: release mutex after nftgcseqend from abort path

The commit mutex should not be released during the critical section between nftgcseqbegin() and nftgcseqend(), otherwise, async GC worker could collect expired objects and get the released commit lock within the same GC sequence.

nftablesmoduleautoload() temporarily releases the mutex to load module dependencies, then it goes back to replay the transaction again. Move it at the end of the abort phase after nftgcseqend() is called.(CVE-2024-26925)

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

wifi: wilc1000: fix RCU usage in connect path

With lockdep enabled, calls to the connect function from cfg802.11 layer lead to the following warning:

============================= WARNING: suspicious RCU usage

6.7.0-rc1-wt+ #333 Not tainted

drivers/net/wireless/microchip/wilc1000/hif.c:386 suspicious rcudereferencecheck() usage! [...] stack backtrace: CPU: 0 PID: 100 Comm: wpasupplicant Not tainted 6.7.0-rc1-wt+ #333 Hardware name: Atmel SAMA5 unwindbacktrace from showstack+0x18/0x1c showstack from dumpstacklvl+0x34/0x48 dumpstacklvl from wilcparsejoinbssparam+0x7dc/0x7f4 wilcparsejoinbssparam from connect+0x2c4/0x648 connect from cfg80211connect+0x30c/0xb74 cfg80211connect from nl80211connect+0x860/0xa94 nl80211connect from genlrcvmsg+0x3fc/0x59c genlrcvmsg from netlinkrcvskb+0xd0/0x1f8 netlinkrcvskb from genlrcv+0x2c/0x3c genlrcv from netlinkunicast+0x3b0/0x550 netlinkunicast from netlinksendmsg+0x368/0x688 netlinksendmsg from _syssendmsg+0x190/0x430 syssendmsg from syssendmsg+0x110/0x158 _syssendmsg from syssendmsg+0xe8/0x150 syssendmsg from retfastsyscall+0x0/0x1c

This warning is emitted because in the connect path, when trying to parse target BSS parameters, we dereference a RCU pointer whithout being in RCU critical section. Fix RCU dereference usage by moving it to a RCU read critical section. To avoid wrapping the whole wilcparsejoinbssparam under the critical section, just use the critical section to copy ies data(CVE-2024-27053)

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

media: tc358743: register v4l2 async device only after successful setup

Ensure the device has been setup correctly before registering the v4l2 async device, thus allowing userspace to access.(CVE-2024-35830)

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

net/rds: fix possible cp null dereference

cp might be null, calling cp->cp_conn would produce null dereference

[Simon Horman adds:]

Analysis:

• cp is a parameter of _rdsrdma_map and is not reassigned.

• The following call-sites pass a NULL cp argument to _rdsrdma_map()

  • rdsgetmr()
  • rdsgetmrfordest

• Prior to the code above, the following assumes that cp may be NULL (which is indicative, but could itself be unnecessary)

  transprivate = rs->rstransport->getmr( sg, nents, rs, &mr->rkey, cp ? cp->cpconn : NULL, args->vec.addr, args->vec.bytes, needodp ? ODPZEROBASED : ODPNOT_NEEDED);

• The code modified by this patch is guarded by ISERR(transprivate), where trans_private is assigned as per the previous point in this analysis.

  The only implementation of getmr that I could locate is rdsibgetmr() which can return an ERR_PTR if the conn (4th) argument is NULL.

• ret is set to PTRERR(transprivate). rdsibgetmr can return ERRPTR(-ENODEV) if the conn (4th) argument is NULL. Thus ret may be -ENODEV in which case the code in question will execute.

Conclusion: * cp may be NULL at the point where this patch adds a check; this patch does seem to address a possible bug(CVE-2024-35902)

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

kprobes: Fix possible use-after-free issue on kprobe registration

When unloading a module, its state is changing MODULESTATELIVE -> MODULESTATEGOING -> MODULESTATEUNFORMED. Each change will take a time. is_module_text_address() and __module_text_address() works with MODULESTATELIVE and MODULESTATEGOING. If we use is_module_text_address() and __module_text_address() separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULESTATEUNFORMED between those operations.

In check_kprobe_address_safe(), if the second __module_text_address() is failed, that is ignored because it expected a kerneltext address. But it may have failed simply because module->state has been changed to MODULESTATEUNFORMED. In this case, armkprobe() will try to modify non-exist module text address (use-after-free).

To fix this problem, we should not use separated is_module_text_address() and __module_text_address(), but use only __module_text_address() once and do try_module_get(module) which is only available with MODULESTATELIVE.(CVE-2024-35955)

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:

drm/amd/display: Fix division by zero in setupdscconfig

When sliceheight is 0, the division by sliceheight in the calculation of the number of slices will cause a division by zero driver crash. This leaves the kernel in a state that requires a reboot. This patch adds a check to avoid the division by zero.

The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor connected via Thunderbolt. The amdgpu driver crashed with this exception when I rebooted the system with the monitor connected.

kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447) kernel: ? dotrap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154) kernel: ? setupdscconfig (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dcdsc.c:1053) amdgpu kernel: ? doerrortrap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175) kernel: ? setupdscconfig (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dcdsc.c:1053) amdgpu kernel: ? excdivideerror (arch/x86/kernel/traps.c:194 (discriminator 2)) kernel: ? setupdscconfig (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dcdsc.c:1053) amdgpu kernel: ? asmexcdivideerror (./arch/x86/include/asm/idtentry.h:548) kernel: ? setupdscconfig (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dcdsc.c:1053) amdgpu kernel: dcdsccomputeconfig (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dcdsc.c:1109) amdgpu

After applying this patch, the driver no longer crashes when the monitor is connected and the system is rebooted. I believe this is the same issue reported for 3113.(CVE-2024-36969)

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

net: sched: schmultiq: fix possible OOB write in multiqtune()

q->bands will be assigned to qopt->bands to execute subsequent code logic after kmalloc. So the old q->bands should not be used in kmalloc. Otherwise, an out-of-bounds write will occur.(CVE-2024-36978)

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

RDMA/hns: Fix UAF for cq async event

The refcount of CQ is not protected by locks. When CQ asynchronous events and CQ destruction are concurrent, CQ may have been released, which will cause UAF.

Use the xa_lock() to protect the CQ refcount.(CVE-2024-38545)

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

ftrace: Fix possible use-after-free issue in ftrace_location()

KASAN reports a bug:

BUG: KASAN: use-after-free in ftracelocation+0x90/0x120 Read of size 8 at addr ffff888141d40010 by task insmod/424 CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+ [...] Call Trace: <TASK> dumpstacklvl+0x68/0xa0 printreport+0xcf/0x610 kasanreport+0xb5/0xe0 ftracelocation+0x90/0x120 registerkprobe+0x14b/0xa40 kprobeinit+0x2d/0xff0 [kprobeexample] dooneinitcall+0x8f/0x2d0 doinitmodule+0x13a/0x3c0 loadmodule+0x3082/0x33d0 initmodulefromfile+0xd2/0x130 _x64sysfinitmodule+0x306/0x440 dosyscall64+0x68/0x140 entrySYSCALL64after_hwframe+0x71/0x79

The root cause is that, in lookuprec(), ftrace record of some address is being searched in ftrace pages of some module, but those ftrace pages at the same time is being freed in ftracerelease_mod() as the corresponding module is being deleted:

       CPU1                       |      CPU2

registerkprobes() { | deletemodule() { checkkprobeaddresssafe() { | archcheckftracelocation() { | ftracelocation() { | lookuprec() // USE! | ftracereleasemod() // Free!

To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftracelocationrange(); 2. Use ftracelocationrange() instead of lookuprec() in ftracelocation(); 3. Call synchronizercu() before freeing any ftrace pages both in ftraceprocesslocs()/ftracereleasemod()/ftracefree_mem().(CVE-2024-38588)

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

RDMA/hns: Fix deadlock on SRQ async events.

xalock for SRQ table may be required in AEQ. Use xastoreirq()/ xaerase_irq() to avoid deadlock.(CVE-2024-38591)

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

afunix: Fix data races in unixreleasesock/unixstream_sendmsg

A data-race condition has been identified in afunix. In one data path, the write function unixreleasesock() atomically writes to sk->skshutdown using WRITEONCE. However, on the reader side, unixstream_sendmsg() does not read it atomically. Consequently, this issue is causing the following KCSAN splat to occur:

BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg

write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
unix_release_sock (net/unix/af_unix.c:640)
unix_release (net/unix/af_unix.c:1050)
sock_close (net/socket.c:659 net/socket.c:1421)
__fput (fs/file_table.c:422)
__fput_sync (fs/file_table.c:508)
__se_sys_close (fs/open.c:1559 fs/open.c:1541)
__x64_sys_close (fs/open.c:1541)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
unix_stream_sendmsg (net/unix/af_unix.c:2273)
__sock_sendmsg (net/socket.c:730 net/socket.c:745)
____sys_sendmsg (net/socket.c:2584)
__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

value changed: 0x01 -> 0x03

The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").

Commit e1d09c2c2f57 ("afunix: Fix data races around sk->skshutdown.") addressed a comparable issue in the past regarding sk->skshutdown. However, it overlooked resolving this particular data path. This patch only offending unixstreamsendmsg() function, since the other reads seem to be protected by unixstate_lock() as discussed in(CVE-2024-38596)

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

ring-buffer: Fix a race between readers and resize checks

The reader code in rbgetreader_page() swaps a new reader page into the ring buffer by doing cmpxchg on old->list.prev->next to point it to the new page. Following that, if the operation is successful, old->list.next->prev gets updated too. This means the underlying doubly-linked list is temporarily inconsistent, page->prev->next or page->next->prev might not be equal back to page for some page in the ring buffer.

The resize operation in ringbufferresize() can be invoked in parallel. It calls rbcheckpages() which can detect the described inconsistency and stop further tracing:

[ 190.271762] ------------[ cut here ]------------ [ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ringbuffer.c:1467 rbcheckpages.isra.0+0x6a/0xa0 [ 190.271789] Modules linked in: [...] [ 190.271991] Unloaded tainted modules: inteluncorefrequency(E):1 skxedac(E):1 [ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f [ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014 [ 190.272015] RIP: 0010:rbcheckpages.isra.0+0x6a/0xa0 [ 190.272023] Code: [...] [ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206 [ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80 [ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700 [ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000 [ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720 [ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000 [ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000 [ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0 [ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 190.272077] Call Trace: [ 190.272098] <TASK> [ 190.272189] ringbufferresize+0x2ab/0x460 [ 190.272199] _tracingresizeringbuffer.part.0+0x23/0xa0 [ 190.272206] tracingresizeringbuffer+0x65/0x90 [ 190.272216] tracingentrieswrite+0x74/0xc0 [ 190.272225] vfswrite+0xf5/0x420 [ 190.272248] ksyswrite+0x67/0xe0 [ 190.272256] dosyscall64+0x82/0x170 [ 190.272363] entrySYSCALL64afterhwframe+0x76/0x7e [ 190.272373] RIP: 0033:0x7f1bd657d263 [ 190.272381] Code: [...] [ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIGRAX: 0000000000000001 [ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263 [ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001 [ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000 [ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500 [ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002 [ 190.272412] </TASK> [ 190.272414] ---[ end trace 0000000000000000 ]---

Note that ringbufferresize() calls rbcheckpages() only if the parent trace_buffer has recording disabled. Recent commit d78ab792705c ("tracing: Stop current tracer when resizing buffer") causes that it is now always the case which makes it more likely to experience this issue.

The window to hit this race is nonetheless very small. To help reproducing it, one can add a delay loop in rbgetreader_page():

ret = rbheadpagereplace(reader, cpubuffer->readerpage); if (!ret) goto spin; for (unsigned i = 0; i < 1U << 26; i++) /* inserted delay loop */ asm volatile ("" : : : "memory"); rblisthead(reader->list.next)->prev = &cpubuffer->reader_page->list;

.. ---truncated---(CVE-2024-38601)