OESA-2024-1768

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ASoC: SOF: Fix DSP oops stack dump output contents

Fix @buf arg given to hexdumpto_buffer() and stack address used in dump error output.(CVE-2021-47381)

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

scsi: iscsi: Fix iscsi_task use after free

Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn") added iscsigetconn()/iscsiputconn() calls during abort handling but then also changed the handling of the case where we detect an already completed task where we now end up doing a goto to the common put/cleanup code. This results in a iscsitask use after free, because the common cleanup code will do a put on the iscsitask.

This reverts the goto and moves the iscsigetconn() to after we've checked if the iscsi_task is valid.(CVE-2021-47427)

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:

powerpc/powernv: Add a null pointer check in opalpowercapinit()

kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.(CVE-2023-52696)

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

i2c: core: Run atomic i2c xfer when !preemptible

Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is disabled. However, non-atomic i2c transfers require preemption (e.g. in waitforcompletion() while waiting for the DMA).

panic() calls preemptdisablenotrace() before calling emergency_restart(). Therefore, if an i2c device is used for the restart, the xfer should be atomic. This avoids warnings like:

[ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/treeplugin.h:318 rcunotecontextswitch+0x33c/0x6b0 [ 12.676926] Voluntary context switch within RCU read-side critical section! ... [ 12.742376] scheduletimeout from waitforcompletiontimeout+0x90/0x114 [ 12.749179] waitforcompletiontimeout from tegrai2cwaitcompletion+0x40/0x70 ... [ 12.994527] atomicnotifiercallchain from machinerestart+0x34/0x58 [ 13.001050] machine_restart from panic+0x2a8/0x32c

Use !preemptible() instead, which is basically the same check as pre-v5.2.(CVE-2023-52791)

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:

net/ipv6: avoid possible UAF in ip6routempath_notify()

syzbot found another use-after-free in ip6routempath_notify() [1]

Commit f7225172f25a ("net/ipv6: prevent use after free in ip6routempath_notify") was not able to fix the root cause.

We need to defer the fib6inforelease() calls after ip6routempath_notify(), in the cleanup phase.

[1] BUG: KASAN: slab-use-after-free in rt6fillnode+0x1460/0x1ac0 Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037

CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1e7/0x2e0 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x167/0x540 mm/kasan/report.c:488 kasanreport+0x142/0x180 mm/kasan/report.c:601 rt6fillnode+0x1460/0x1ac0 inet6rtnotify+0x13b/0x290 net/ipv6/route.c:6184 ip6routempathnotify net/ipv6/route.c:5198 [inline] ip6routemultipathadd net/ipv6/route.c:5404 [inline] inet6rtmnewroute+0x1d0f/0x2300 net/ipv6/route.c:5517 rtnetlinkrcvmsg+0x885/0x1040 net/core/rtnetlink.c:6597 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2543 netlinkunicastkernel net/netlink/afnetlink.c:1341 [inline] netlinkunicast+0x7ea/0x980 net/netlink/afnetlink.c:1367 netlinksendmsg+0xa3b/0xd70 net/netlink/afnetlink.c:1908 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x221/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2584 _syssendmsg net/socket.c:2638 [inline] _syssendmsg+0x2b0/0x3a0 net/socket.c:2667 dosyscall64+0xf9/0x240 entrySYSCALL64afterhwframe+0x6f/0x77 RIP: 0033:0x7f73dd87dda9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9 RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005 RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858 </TASK>

Allocated by task 23037: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:372 [inline] kasankmalloc+0x98/0xb0 mm/kasan/common.c:389 kasankmalloc include/linux/kasan.h:211 [inline] _dokmallocnode mm/slub.c:3981 [inline] _kmalloc+0x22e/0x490 mm/slub.c:3994 kmalloc include/linux/slab.h:594 [inline] kzalloc include/linux/slab.h:711 [inline] fib6infoalloc+0x2e/0xf0 net/ipv6/ip6fib.c:155 ip6routeinfocreate+0x445/0x12b0 net/ipv6/route.c:3758 ip6routemultipathadd net/ipv6/route.c:5298 [inline] inet6rtmnewroute+0x744/0x2300 net/ipv6/route.c:5517 rtnetlinkrcvmsg+0x885/0x1040 net/core/rtnetlink.c:6597 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2543 netlinkunicastkernel net/netlink/afnetlink.c:1341 [inline] netlinkunicast+0x7ea/0x980 net/netlink/afnetlink.c:1367 netlinksendmsg+0xa3b/0xd70 net/netlink/afnetlink.c:1908 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x221/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2584 _syssendmsg net/socket.c:2638 [inline] _syssendmsg+0x2b0/0x3a0 net/socket.c:2667 dosyscall64+0xf9/0x240 entrySYSCALL64afterhwframe+0x6f/0x77

Freed by task 16: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 kasansavefreeinfo+0x4e/0x60 mm/kasan/generic.c:640 poisonslab_object+0xa6/0xe0 m ---truncated---(CVE-2024-26852)

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

inet: inet_defrag: prevent sk release while still in use

iplocalout() and other functions can pass skb->sk as function argument.

If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released.

This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.

Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ipdefrag() in output path is also implying skborphan(), which is buggy because output path relies on sk not disappearing.

A relevant old patch about the issue was : 8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()")

[..]

net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one.

If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly.

We need to change ipdefrag() to only use skborphan() when really needed, ie whenever frag_list is going to be used.

Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this:

If skb is refragmented again right after, ipdofragment() will copy head->sk to the new fragments, and sets up destructor to sockwfree. IOW, we have no choice but to fix up skwmem accouting to reflect the fully reassembled skb, else wmem will underflow.

This change moves the orphan down into the core, to last possible moment. As ipdefragoffset is aliased with skbuff->sk member, we must move the offset into the FRAGCB, else skb->sk gets clobbered.

This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue.

In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine.

In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize.(CVE-2024-26921)

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

scsi: core: Fix unremoved procfs host directory regression

Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${procname} directory earlier") fixed a bug related to modules loading/unloading, by adding a call to scsiprochostdirrm() on scsiremovehost(). But that led to a potential duplicate call to the hostdirrm() routine, since it's also called from scsihostdevrelease(). That triggered a regression report, which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host directory removal regression"). The fix just dropped the hostdirrm() call from devrelease().

But it happens that this proc directory is created on scsihostalloc(), and that function "pairs" with scsihostdevrelease(), while scsiremovehost() pairs with scsiaddhost(). In other words, it seems the reason for removing the proc directory on devrelease() was meant to cover cases in which a SCSI host structure was allocated, but the call to scsiaddhost() didn't happen. And that pattern happens to exist in some error paths, for example.

Syzkaller causes that by using USB raw gadget device, error'ing on usb-storage driver, at usbstorprobe2(). By checking that path, we can see that the BadDevice label leads to a scsihostput() after a SCSI host allocation, but there's no call to scsiaddhost() in such path. That leads to messages like this in dmesg (and a leak of the SCSI host proc structure):

usb-storage 4-1:87.51: USB Mass Storage device detected procdirentry 'scsi/usb-storage' already registered WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376

The proper fix seems to still call scsiprochostdirrm() on devrelease(), but guard that with the state check for SHOSTCREATED; there is even a comment in scsihostdevrelease() detailing that: such conditional is meant for cases where the SCSI host was allocated but there was no calls to {add,remove}_host(), like the usb-storage case.

This is what we propose here and with that, the error path of usb-storage does not trigger the warning anymore.(CVE-2024-26935)

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

init/main.c: Fix potential staticcommandline memory overflow

We allocate memory of size 'xlen + strlen(bootcommandline) + 1' for staticcommandline, but the strings copied into staticcommandline are extracommandline and commandline, rather than extracommandline and bootcommand_line.

When strlen(commandline) > strlen(bootcommandline), staticcommand_line will overflow.

This patch just recovers strlen(commandline) which was miss-consolidated with strlen(bootcommandline) in the commit f5c7310ac73e ("init/main: add checks for the return value of memblockalloc*()")(CVE-2024-26988)

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

f2fs: fix to avoid potential panic during recovery

During recovery, if FAULTBLOCK is on, it is possible that f2fsreservenewblock() will return -ENOSPC during recovery, then it may trigger panic.

Also, if fault injection rate is 1 and only FAULT_BLOCK fault type is on, it may encounter deadloop in loop of block reservation.

Let's change as below to fix these issues: - remove bug_on() to avoid panic. - limit the loop count of block reservation to avoid potential deadloop.(CVE-2024-27032)

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

clk: Fix clkcoreget NULL dereference

It is possible for clkcoreget to dereference a NULL in the following sequence:

clkcoreget() ofclkgethwfromclkspec() _ofclkgethwfromprovider() _clkgethw()

_clkgethw() can return NULL which is dereferenced by clkcore_get() at hw->core.

Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev based clklookups") the check ISERRORNULL() was performed which would have caught the NULL.

Reading the description of this function it talks about returning NULL but that cannot be so at the moment.

Update the function to check for hw before dereferencing it and return NULL if hw is NULL.(CVE-2024-27038)

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

net: phy: fix phygetinternal_delay accessing an empty array

The phygetinternaldelay function could try to access to an empty array in the case that the driver is calling phygetinternaldelay without defining delay_values and rx-internal-delay-ps or tx-internal-delay-ps is defined to 0 in the device-tree. This will lead to "unable to handle kernel NULL pointer dereference at virtual address 0". To avoid this kernel oops, the test should be delay >= 0. As there is already delay < 0 test just before, the test could only be size == 0.(CVE-2024-27047)

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

wifi: rtl8xxxu: add cancelworksync() for c2hcmd_work

The workqueue might still be running, when the driver is stopped. To avoid a use-after-free, call cancelworksync() in rtl8xxxu_stop().(CVE-2024-27052)

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:

ipv6: fix potential "struct net" leak in inet6rtmgetaddr()

It seems that if userspace provides a correct IFATARGETNETNSID value but no IFAADDRESS and IFALOCAL attributes, inet6rtmgetaddr() returns -EINVAL with an elevated "struct net" refcount.(CVE-2024-27417)

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

genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline

The absence of IRQDMOVEPCNTXT prevents immediate effectiveness of interrupt affinity reconfiguration via procfs. Instead, the change is deferred until the next instance of the interrupt being triggered on the original CPU.

When the interrupt next triggers on the original CPU, the new affinity is enforced within _irqmoveirq(). A vector is allocated from the new CPU, but the old vector on the original CPU remains and is not immediately reclaimed. Instead, apicd->movein_progress is flagged, and the reclaiming process is delayed until the next trigger of the interrupt on the new CPU.

Upon the subsequent triggering of the interrupt on the new CPU, irqcompletemove() adds a task to the old CPU's vectorcleanup list if it remains online. Subsequently, the timer on the old CPU iterates over its vectorcleanup list, reclaiming old vectors.

However, a rare scenario arises if the old CPU is outgoing before the interrupt triggers again on the new CPU.

In that case irqforcecompletemove() is not invoked on the outgoing CPU to reclaim the old apicd->prevvector because the interrupt isn't currently affine to the outgoing CPU, and irqneedsfixup() returns false. Even though _vectorschedulecleanup() is later called on the new CPU, it doesn't reclaim apicd->prevvector; instead, it simply resets both apicd->moveinprogress and apicd->prev_vector to 0.

As a result, the vector remains unreclaimed in vector_matrix, leading to a CPU vector leak.

To address this issue, move the invocation of irqforcecompletemove() before the irqneedsfixup() call to reclaim apicd->prevvector, if the interrupt is currently or used to be affine to the outgoing CPU.

Additionally, reclaim the vector in _vectorschedulecleanup() as well, following a warning message, although theoretically it should never see apicd->moveinprogress with apicd->prevcpu pointing to an offline CPU.(CVE-2024-31076)

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

wifi: brcmfmac: Fix use-after-free bug in brcmfcfg80211detach

This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233

In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker:

->brcmfusbprobe ->brcmfusbprobecb ->brcmfattach ->brcmfbusstarted ->brcmfcfg80211attach ->wlinitpriv ->brcmfinitescan ->INITWORK(&cfg->escantimeoutwork, brcmfcfg80211escantimeout_worker);

If we disconnect the USB by hotplug, it will call brcmfusbdisconnect to make cleanup. The invoking chain is :

brcmfusbdisconnect ->brcmfusbdisconnectcb ->brcmfdetach ->brcmfcfg80211detach ->kfree(cfg);

While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmfcfg80211escantimeoutworker.

Fix it by deleting the timer and canceling the worker in brcmfcfg80211detach.

arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free

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

drm/amdgpu: amdgputtmgart_bind set gtt bound flag

Otherwise after the GTT bo is released, the GTT and gart space is freed but amdgputtmbackend_unbind will not clear the gart page table entry and leave valid mapping entry pointing to the stale system page. Then if GPU access the gart address mistakely, it will read undefined value instead page fault, harder to debug and reproduce the real issue.(CVE-2024-35817)

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:

dyndbg: fix old BUG_ON in >control parser

Fix a BUGON from 2009. Even if it looks "unreachable" (I didn't really look), lets make sure by removing it, doing prerr and return -EINVAL instead.(CVE-2024-35947)

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:

net: bridge: xmit: make sure we have at least eth header len bytes

syzbot triggered an uninit value[1] error in bridge device's xmit path by sending a short (less than ETH_HLEN bytes) skb. To fix it check if we can actually pull that amount instead of assuming.

Tested with dropwatch: drop at: brdevxmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3) origin: software timestamp: Mon May 13 11:31:53 2024 778214037 nsec protocol: 0x88a8 length: 2 original length: 2 drop reason: PKTTOOSMALL

[1] BUG: KMSAN: uninit-value in brdevxmit+0x61d/0x1cb0 net/bridge/brdevice.c:65 brdevxmit+0x61d/0x1cb0 net/bridge/brdevice.c:65 netdevstartxmit include/linux/netdevice.h:4903 [inline] netdevstartxmit include/linux/netdevice.h:4917 [inline] xmitone net/core/dev.c:3531 [inline] devhardstartxmit+0x247/0xa20 net/core/dev.c:3547 _devqueuexmit+0x34db/0x5350 net/core/dev.c:4341 devqueuexmit include/linux/netdevice.h:3091 [inline] _bpftxskb net/core/filter.c:2136 [inline] _bpfredirectcommon net/core/filter.c:2180 [inline] _bpfredirect+0x14a6/0x1620 net/core/filter.c:2187 _bpfcloneredirect net/core/filter.c:2460 [inline] bpfcloneredirect+0x328/0x470 net/core/filter.c:2432 _bpfprogrun+0x13fe/0xe0f0 kernel/bpf/core.c:1997 _bpfprogrun512+0xb5/0xe0 kernel/bpf/core.c:2238 bpfdispatchernopfunc include/linux/bpf.h:1234 [inline] _bpfprogrun include/linux/filter.h:657 [inline] bpfprogrun include/linux/filter.h:664 [inline] bpftestrun+0x499/0xc30 net/bpf/testrun.c:425 bpfprogtestrunskb+0x14ea/0x1f20 net/bpf/testrun.c:1058 bpfprogtestrun+0x6b7/0xad0 kernel/bpf/syscall.c:4269 _sysbpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678 _dosysbpf kernel/bpf/syscall.c:5767 [inline] _sesysbpf kernel/bpf/syscall.c:5765 [inline] _x64sysbpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 x64syscall+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls64.h:322 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f(CVE-2024-38538)

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:

drm/mediatek: Add 0 size check to mtkdrmgem_obj

Add a check to mtkdrmgem_init if we attempt to allocate a GEM object of 0 bytes. Currently, no such check exists and the kernel will panic if a userspace application attempts to allocate a 0x0 GBM buffer.

Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and verifying that we now return EINVAL.(CVE-2024-38549)

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

net/mlx5: Discard command completions in internal error

Fix use after free when FW completion arrives while device is in internal error state. Avoid calling completion handler in this case, since the device will flush the command interface and trigger all completions manually.

Kernel log: ------------[ cut here ]------------ refcountt: underflow; use-after-free. ... RIP: 0010:refcountwarnsaturate+0xd8/0xe0 ... Call Trace: <IRQ> ? _warn+0x79/0x120 ? refcountwarnsaturate+0xd8/0xe0 ? reportbug+0x17c/0x190 ? handlebug+0x3c/0x60 ? excinvalidop+0x14/0x70 ? asmexcinvalidop+0x16/0x20 ? refcountwarnsaturate+0xd8/0xe0 cmdentput+0x13b/0x160 [mlx5core] mlx5cmdcomphandler+0x5f9/0x670 [mlx5core] cmdcompnotifier+0x1f/0x30 [mlx5core] notifiercallchain+0x35/0xb0 atomicnotifiercallchain+0x16/0x20 mlx5eqasyncint+0xf6/0x290 [mlx5core] notifiercallchain+0x35/0xb0 atomicnotifiercallchain+0x16/0x20 irqinthandler+0x19/0x30 [mlx5core] _handleirqeventpercpu+0x4b/0x160 handleirqevent+0x2e/0x80 handleedgeirq+0x98/0x230 _commoninterrupt+0x3b/0xa0 commoninterrupt+0x7b/0xa0 </IRQ> <TASK> asmcommon_interrupt+0x22/0x40(CVE-2024-38555)

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

drivers/perf: hisi_pcie: Fix out-of-bound access when valid event group

The perf tool allows users to create event groups through following cmd [1], but the driver does not check whether the array index is out of bounds when writing data to the eventgroup array. If the number of events in an eventgroup is greater than HISIPCIEMAXCOUNTERS, the memory write overflow of eventgroup array occurs.

Add array index check to fix the possible array out of bounds violation, and return directly when write new events are written to array bounds.

There are 9 different events in an event_group. [1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}'(CVE-2024-38569)

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:

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)

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

serial: max3100: Lock port->lock when calling uarthandlects_change()

uarthandlects_change() has to be called with port lock taken, Since we run it in a separate work, the lock may not be taken at the time of running. Make sure that it's taken by explicitly doing that. Without it we got a splat:

WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serialcore.c:3491 uarthandlectschange+0xa6/0xb0 ... Workqueue: max3100-0 max3100work [max3100] RIP: 0010:uarthandlectschange+0xa6/0xb0 ... max3100handlerx+0xc5/0x110 [max3100] max3100work+0x12a/0x340 max3100

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

bpf: Allow delete from sockmap/sockhash only if update is allowed

We have seen an influx of syzkaller reports where a BPF program attached to a tracepoint triggers a locking rule violation by performing a map_delete on a sockmap/sockhash.

We don't intend to support this artificial use scenario. Extend the existing verifier allowed-program-type check for updating sockmap/sockhash to also cover deleting from a map.

From now on only BPF programs which were previously allowed to update sockmap/sockhash can delete from these map types.(CVE-2024-38662)