OESA-2024-1960

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

efi: libstub: only free priv.runtime_map when allocated

priv.runtimemap is only allocated when efinovamap is not set. Otherwise, it is an uninitialized value. In the error path, it is freed unconditionally. Avoid passing an uninitialized value to freepool. Free priv.runtimemap only when it was allocated.

This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.(CVE-2024-33619)

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

fpga: region: add owner module and take its refcount

The current implementation of the fpga region assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the region during programming if the parent device does not have a driver.

To address this problem, add a module owner pointer to the fpga_region struct and use it to take the module's refcount. Modify the functions for registering a region to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the region as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a region without setting the owner.

Also, update the documentation to keep it consistent with the new interface for registering an fpga region.(CVE-2024-35247)

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

eeprom: at24: fix memory corruption race condition

If the eeprom is not accessible, an nvmem device will be registered, the read will fail, and the device will be torn down. If another driver accesses the nvmem device after the teardown, it will reference invalid memory.

Move the failure point before registering the nvmem device.(CVE-2024-35848)

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

block: fix module reference leakage from bdevopenby_dev error path

At the time bdevmayopen() is called, module reference is grabbed already, hence module reference should be released if bdevmayopen() failed.

This problem is found by code review.(CVE-2024-35859)

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

Bluetooth: RFCOMM: Fix not validating setsockopt user input

syzbot reported rfcommsocksetsockopt_old() is copying data without checking user input length.

BUG: KASAN: slab-out-of-bounds in copyfromsockptroffset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copyfromsockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcommsocksetsockoptold net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcommsocksetsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064(CVE-2024-35966)

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

mm/slab: make __free(kfree) accept error pointers

Currently, if an automatically freed allocation is an error pointer that will lead to a crash. An example of this is in wm831xgpiodbg_show().

171 char *label _free(kfree) = gpiochipduplinelabel(chip, i); 172 if (ISERR(label)) { 173 deverr(wm831x->dev, "Failed to duplicate label\n"); 174 continue; 175 }

The auto clean up function should check for error pointers as well, otherwise we're going to keep hitting issues like this.(CVE-2024-36890)

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

USB: core: Fix access violation during port device removal

Testing with KASAN and syzkaller revealed a bug in port.c:disablestore(): usbhubtostruct_hub() can return NULL if the hub that the port belongs to is concurrently removed, but the function does not check for this possibility before dereferencing the returned value.

It turns out that the first dereference is unnecessary, since hub->intfdev is the parent of the port device, so it can be changed easily. Adding a check for hub == NULL prevents further problems.

The same bug exists in the disable_show() routine, and it can be fixed the same way.(CVE-2024-36896)

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

gpiolib: cdev: Fix use after free in lineinfochangednotify

The use-after-free issue occurs as follows: when the GPIO chip device file is being closed by invoking gpiochrdevrelease(), watchedlines is freed by bitmapfree(), but the unregistration of lineinfochangednb notifier chain failed due to waiting write rwsem. Additionally, one of the GPIO chip's lines is also in the release process and holds the notifier chain's read rwsem. Consequently, a race condition leads to the use-after-free of watched_lines.

Here is the typical stack when issue happened:

[free] gpiochrdevrelease() --> bitmapfree(cdev->watchedlines) <-- freed --> blockingnotifierchainunregister() --> downwrite(&nh->rwsem) <-- waiting rwsem --> _downwritecommon() --> rwsemdownwriteslowpath() --> schedulepreemptdisabled() --> schedule()

[use] st54spigpiodevrelease() --> gpiofree() --> gpiodfree() --> gpiodfreecommit() --> gpiodlinestatenotify() --> blockingnotifiercallchain() --> downread(&nh->rwsem); <-- held rwsem --> notifiercallchain() --> lineinfochangednotify() --> testbit(xxxx, cdev->watchedlines) <-- use after free

The side effect of the use-after-free issue is that a GPIO line event is being generated for userspace where it shouldn't. However, since the chrdev is being closed, userspace won't have the chance to read that event anyway.

To fix the issue, call the bitmapfree() function after the unregistration of lineinfochanged_nb notifier chain.(CVE-2024-36899)

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

ipv6: prevent NULL dereference in ip6_output()

According to syzbot, there is a chance that ip6dstidev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here.

syzbot reported:

general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6output+0x231/0x3f0 net/ipv6/ip6output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NFHOOK include/linux/netfilter.h:314 [inline] ip6xmit+0xefe/0x17f0 net/ipv6/ip6output.c:358 sctpv6xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctppackettransmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctppacketsingleton+0x22c/0x320 net/sctp/outqueue.c:783 sctpoutqflushctrl net/sctp/outqueue.c:914 [inline] sctpoutqflush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctpsideeffects net/sctp/smsideeffect.c:1198 [inline] sctpdosm+0x59cc/0x60c0 net/sctp/smsideeffect.c:1169 sctpprimitiveASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 _sctpconnect+0x9cd/0xe30 net/sctp/socket.c:1234 sctpconnect net/sctp/socket.c:4819 [inline] sctpinetconnect+0x149/0x1f0 net/sctp/socket.c:4834 _sysconnectfile net/socket.c:2048 [inline] _sysconnect+0x2df/0x310 net/socket.c:2065 _dosysconnect net/socket.c:2075 [inline] _sesysconnect net/socket.c:2072 [inline] _x64sysconnect+0x7a/0x90 net/socket.c:2072 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf5/0x240 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f(CVE-2024-36901)

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

Reapply "drm/qxl: simplify qxlfencewait"

This reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea.

Stephen Rostedt reports: "I went to run my tests on my VMs and the tests hung on boot up. Unfortunately, the most I ever got out was:

[ 93.607888] Testing event system initcall: OK [ 93.667730] Running tests on all trace events: [ 93.669757] Testing all events: OK [ 95.631064] ------------[ cut here ]------------ Timed out after 60 seconds"

and further debugging points to a possible circular locking dependency between the console_owner locking and the worker pool locking.

Reverting the commit allows Steve's VM to boot to completion again.

This may obviously result in the "[TTM] Buffer eviction failed" messages again, which was the reason for that original revert. But at this point this seems preferable to a non-booting system...

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

fs/9p: only translate RWX permissions for plain 9P2000

Garbage in plain 9P2000's perm bits is allowed through, which causes it to be able to set (among others) the suid bit. This was presumably not the intent since the unix extended bits are handled explicitly and conditionally on .u.(CVE-2024-36964)

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

net/mlx5: Add a timeout to acquire the command queue semaphore

Prevent forced completion handling on an entry that has not yet been assigned an index, causing an out of bounds access on idx = -22. Instead of waiting indefinitely for the sem, blocking flow now waits for index to be allocated or a sem acquisition timeout before beginning the timer for FW completion.

Kernel log example: mlx5core 0000:06:00.0: waitfunchandleexectimeout:1128:(pid 185911): cmd[-22]: CREATEUCTX(0xa04) No done completion(CVE-2024-38556)

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

rcu: Fix buffer overflow in printcpustall_info()

The rcuc-starvation output from printcpustall_info() might overflow the buffer if there is a huge difference in jiffies difference. The situation might seem improbable, but computers sometimes get very confused about time, which can result in full-sized integers, and, in this case, buffer overflow.

Also, the unsigned jiffies difference is printed using %ld, which is normally for signed integers. This is intentional for debugging purposes, but it is not obvious from the code.

This commit therefore changes sprintf() to snprintf() and adds a clarifying comment about intention of %ld format.

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

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

ALSA: Fix deadlocks with kctl removals at disconnection

In sndcarddisconnect(), we set card->shutdown flag at the beginning, call callbacks and do sync for card->powerrefsleep waiters at the end. The callback may delete a kctl element, and this can lead to a deadlock when the device was in the suspended state. Namely:

• A process waits for the power up at sndpowerrefandwait() in sndctlinfo() or read/write() inside card->controls_rwsem.

• The system gets disconnected meanwhile, and the driver tries to delete a kctl via sndctlremove*(); it tries to take card->controls_rwsem again, but this is already locked by the above. Since the sleeper isn't woken up, this deadlocks.

An easy fix is to wake up sleepers before processing the driver disconnect callbacks but right after setting the card->shutdown flag. Then all sleepers will abort immediately, and the code flows again.

So, basically this patch moves the waitevent() call at the right timing. While we're at it, just to be sure, call waiteventall() instead of waitevent(), although we don't use exclusive events on this queue for now.(CVE-2024-38600)

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

crypto: qat - validate slices count returned by FW

The function adfsendadmintlstart() enables the telemetry (TL) feature on a QAT device by sending the ICPQATFWTLSTART message to the firmware. This triggers the FW to start writing TL data to a DMA buffer in memory and returns an array containing the number of accelerators of each type (slices) supported by this HW. The pointer to this array is stored in the adftlhwdata data structure called slicecnt.

The array slicecnt is then used in the function tlprintdevdata() to report in debugfs only statistics about the supported accelerators. An incorrect value of the elements in slice_cnt might lead to an out of bounds memory read. At the moment, there isn't an implementation of FW that returns a wrong value, but for robustness validate the slice count array returned by FW.(CVE-2024-38606)

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

macintosh/via-macii: Fix "BUG: sleeping function called from invalid context"

The via-macii ADB driver calls request_irq() after disabling hard interrupts. But disabling interrupts isn't necessary here because the VIA shift register interrupt was masked during VIA1 initialization.(CVE-2024-38607)

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

kunit/fortify: Fix mismatched kvalloc()/vfree() usage

The kv*() family of tests were accidentally freeing with vfree() instead of kvfree(). Use kvfree() instead.(CVE-2024-38617)

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

drm/amdgpu: add error handle to avoid out-of-bounds

if the sdmav40irqidtoseq return -EINVAL, the process should be stop to avoid out-of-bounds read, so directly return -EINVAL.(CVE-2024-39471)

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

ASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension

If a process module does not have base config extension then the same format applies to all of it's inputs and the process->baseconfigext is NULL, causing NULL dereference when specifically crafted topology and sequences used.(CVE-2024-39473)

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

fbdev: savage: Handle err return when savagefbcheckvar failed

The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero") checks the value of pixclock to avoid divide-by-zero error. However the function savagefbprobe doesn't handle the error return of savagefbcheck_var. When pixclock is 0, it will cause divide-by-zero error.(CVE-2024-39475)

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

media: mc: Fix graph walk in mediapipelinestart

The graph walk tries to follow all links, even if they are not between pads. This causes a crash with, e.g. a MEDIALNKFLANCILLARYLINK link.

Fix this by allowing the walk to proceed only for MEDIALNKFLDATALINK links.(CVE-2024-39481)

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

drm/drm_file: Fix pid refcounting race

<maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>

filp->pid is supposed to be a refcounted pointer; however, before this patch, drmfileupdatepid() only increments the refcount of a struct pid after storing a pointer to it in filp->pid and dropping the dev->filelistmutex, making the following race possible:

process A process B ========= ========= begin drmfileupdatepid mutexlock(&dev->filelistmutex) rcureplacepointer(filp->pid, <pid B>, 1) mutexunlock(&dev->filelistmutex) begin drmfileupdatepid mutexlock(&dev->filelistmutex) rcureplacepointer(filp->pid, <pid A>, 1) mutexunlock(&dev->filelistmutex) getpid(<pid A>) synchronizercu() putpid(<pid B>) * pid B reaches refcount 0 and is freed here * getpid(<pid B>) * UAF * synchronizercu() putpid(<pid A>)

As far as I know, this race can only occur with CONFIGPREEMPTRCU=y because it requires RCU to detect a quiescent state in code that is not explicitly calling into the scheduler.

This race leads to use-after-free of a "struct pid". It is probably somewhat hard to hit because process A has to pass through a synchronizercu() operation while process B is between mutexunlock() and get_pid().

Fix it by ensuring that by the time a pointer to the current task's pid is stored in the file, an extra reference to the pid has been taken.

This fix also removes the condition for synchronize_rcu(); I think that optimization is unnecessary complexity, since in that case we would usually have bailed out on the lockless check above.(CVE-2024-39486)

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

crypto: qat - Fix ADFDEVRESET_SYNC memory leak

Using completiondone to determine whether the caller has gone away only works after a complete call. Furthermore it's still possible that the caller has not yet called waitfor_completion, resulting in another potential UAF.

Fix this by making the caller use cancelworksync and then freeing the memory safely.(CVE-2024-39493)

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

btrfs: zoned: fix use-after-free due to race with dev replace

While loading a zone's info during creation of a block group, we can race with a device replace operation and then trigger a use-after-free on the device that was just replaced (source device of the replace operation).

This happens because at btrfsloadzone_info() we extract a device from the chunk map into a local variable and then use the device while not under the protection of the device replace rwsem. So if there's a device replace operation happening when we extract the device and that device is the source of the replace operation, we will trigger a use-after-free if before we finish using the device the replace operation finishes and frees the device.

Fix this by enlarging the critical section under the protection of the device replace rwsem so that all uses of the device are done inside the critical section.(CVE-2024-39496)

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

netfilter: ipset: Fix race between namespace cleanup and gc in the list:set type

Lion Ackermann reported that there is a race condition between namespace cleanup in ipset and the garbage collection of the list:set type. The namespace cleanup can destroy the list:set type of sets while the gc of the set type is waiting to run in rcu cleanup. The latter uses data from the destroyed set which thus leads use after free. The patch contains the following parts:

• When destroying all sets, first remove the garbage collectors, then wait if needed and then destroy the sets.
• Fix the badly ordered "wait then remove gc" for the destroy a single set case.
• Fix the missing rcu locking in the list:set type in the userspace test case.
• Use proper RCU list handlings in the list:set type.

The patch depends on c1193d9bbbd3 (netfilter: ipset: Add list flush to cancel_gc).(CVE-2024-39503)

In the Linux kernel, the following vulnerability has been resolved: cachefiles: remove requests from xarray during flushing requests Even with CACHEFILESDEAD set, we can still read the requests, so in the following concurrency the request may be used after it has been freed: mount | daemonthread1 | daemonthread2 ------------------------------------------------------------ cachefilesondemandinitobject cachefilesondemandsendreq REQA = kzalloc(sizeof(*req) + datalen) waitforcompletion(&REQA->done) cachefilesdaemonread cachefilesondemanddaemonread // close dev fd cachefilesflushreqs complete(&REQA->done) kfree(REQA) xalock(&cache->reqs); cachefilesondemandselectreq req->msg.opcode != CACHEFILESOPREAD // req use-after-free !!! xaunlock(&cache->reqs); xa_destroy(&cache->reqs) Hence remove requests from cache->reqs when flushing them to avoid accessing freed requests.(CVE-2024-40900)

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

net/mlx5: Always stop health timer during driver removal

Currently, if teardown_hca fails to execute during driver removal, mlx5 does not stop the health timer. Afterwards, mlx5 continue with driver teardown. This may lead to a UAF bug, which results in page fault Oops[1], since the health timer invokes after resources were freed.

Hence, stop the health monitor even if teardown_hca fails.

[1] mlx5core 0000:18:00.0: E-Switch: Unload vfs: mode(LEGACY), nvfs(0), necvfs(0), active vports(0) mlx5core 0000:18:00.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0) mlx5core 0000:18:00.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0) mlx5core 0000:18:00.0: E-Switch: cleanup mlx5core 0000:18:00.0: waitfunc:1155:(pid 1967079): TEARDOWNHCA(0x103) timeout. Will cause a leak of a command resource mlx5core 0000:18:00.0: mlx5functionclose:1288:(pid 1967079): teardownhca failed, skip cleanup BUG: unable to handle page fault for address: ffffa26487064230 PGD 100c00067 P4D 100c00067 PUD 100e5a067 PMD 105ed7067 PTE 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE ------- --- 6.7.0-68.fc38.x8664 #1 Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0013.121520200651 12/15/2020 RIP: 0010:ioread32be+0x34/0x60 RSP: 0018:ffffa26480003e58 EFLAGS: 00010292 RAX: ffffa26487064200 RBX: ffff9042d08161a0 RCX: ffff904c108222c0 RDX: 000000010bbf1b80 RSI: ffffffffc055ddb0 RDI: ffffa26487064230 RBP: ffff9042d08161a0 R08: 0000000000000022 R09: ffff904c108222e8 R10: 0000000000000004 R11: 0000000000000441 R12: ffffffffc055ddb0 R13: ffffa26487064200 R14: ffffa26480003f00 R15: ffff904c108222c0 FS: 0000000000000000(0000) GS:ffff904c10800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa26487064230 CR3: 00000002c4420006 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? _die+0x23/0x70 ? pagefaultoops+0x171/0x4e0 ? excpagefault+0x175/0x180 ? asmexcpagefault+0x26/0x30 ? _pfxpollhealth+0x10/0x10 [mlx5core] ? _pfxpollhealth+0x10/0x10 [mlx5core] ? ioread32be+0x34/0x60 mlx5healthcheckfatalsensors+0x20/0x100 [mlx5core] ? _pfxpollhealth+0x10/0x10 [mlx5core] pollhealth+0x42/0x230 [mlx5core] ? _nexttimerinterrupt+0xbc/0x110 ? _pfxpollhealth+0x10/0x10 [mlx5core] calltimerfn+0x21/0x130 ? _pfxpollhealth+0x10/0x10 [mlx5core] _runtimers+0x222/0x2c0 runtimersoftirq+0x1d/0x40 _dosoftirq+0xc9/0x2c8 _irqexitrcu+0xa6/0xc0 sysvecapictimerinterrupt+0x72/0x90 </IRQ> <TASK> asmsysvecapictimerinterrupt+0x1a/0x20 RIP: 0010:cpuidleenterstate+0xcc/0x440 ? cpuidleenterstate+0xbd/0x440 cpuidleenter+0x2d/0x40 doidle+0x20d/0x270 cpustartupentry+0x2a/0x30 restinit+0xd0/0xd0 archcallrestinit+0xe/0x30 startkernel+0x709/0xa90 x8664startreservations+0x18/0x30 x8664startkernel+0x96/0xa0 secondarystartup64noverify+0x18f/0x19b ---[ end trace 0000000000000000 ]---(CVE-2024-40906)

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

bpf: Set run context for rawtp test_run callback

syzbot reported crash when rawtp program executed through the testrun interface calls bpfgetattachcookie helper or any other helper that touches task->bpf_ctx pointer.

Setting the run context (task->bpfctx pointer) for testrun callback.(CVE-2024-40908)

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

cachefiles: defer exposing anonfd until after copyto_user() succeeds

After installing the anonymous fd, we can now see it in userland and close it. However, at this point we may not have gotten the reference count of the cache, but we will put it during colse fd, so this may cause a cache UAF.

So grab the cache reference count before fdinstall(). In addition, by kernel convention, fd is taken over by the user land after fdinstall(), and the kernel should not call closefd() after that, i.e., it should call fdinstall() after everything is ready, thus fdinstall() is called after copyto_user() succeeds.(CVE-2024-40913)

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

net: bridge: mst: fix suspicious rcu usage in brmstset_state

I converted brmstset_state to RCU to avoid a vlan use-after-free but forgot to change the vlan group dereference helper. Switch to vlan group RCU deref helper to fix the suspicious rcu usage warning.(CVE-2024-40920)

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

net: bridge: mst: pass vlan group directly to brmstvlansetstate

Pass the already obtained vlan group pointer to brmstvlansetstate() instead of dereferencing it again. Each caller has already correctly dereferenced it for their context. This change is required for the following suspicious RCU dereference fix. No functional changes intended.(CVE-2024-40921)

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

iouring/rsrc: don't lock while !TASKRUNNING

There is a report of iorsrcrefquiesce() locking a mutex while not TASKRUNNING, which is due to forgetting restoring the state back after ioruntaskworksig() and attempts to break out of the waiting loop.

do not call blocking ops when !TASKRUNNING; state=1 set at [<ffffffff815d2494>] preparetowait+0xa4/0x380 kernel/sched/wait.c:237 WARNING: CPU: 2 PID: 397056 at kernel/sched/core.c:10099 mightsleep+0x114/0x160 kernel/sched/core.c:10099 RIP: 0010:mightsleep+0x114/0x160 kernel/sched/core.c:10099 Call Trace: <TASK> _mutexlockcommon kernel/locking/mutex.c:585 [inline] _mutexlock+0xb4/0x940 kernel/locking/mutex.c:752 iorsrcrefquiesce+0x590/0x940 iouring/rsrc.c:253 iosqebuffersunregister+0xa2/0x340 iouring/rsrc.c:799 _iouringregister iouring/register.c:424 [inline] _dosysiouringregister+0x5b9/0x2400 iouring/register.c:613 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd8/0x270 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x6f/0x77(CVE-2024-40922)

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

cachefiles: flush all requests after setting CACHEFILES_DEAD

In ondemand mode, when the daemon is processing an open request, if the kernel flags the cache as CACHEFILESDEAD, the cachefilesdaemonwrite() will always return -EIO, so the daemon can't pass the copen to the kernel. Then the kernel process that is waiting for the copen triggers a hungtask.

Since the DEAD state is irreversible, it can only be exited by closing /dev/cachefiles. Therefore, after calling cachefilesioerror() to mark the cache as CACHEFILES_DEAD, if in ondemand mode, flush all requests to avoid the above hungtask. We may still be able to read some of the cached data before closing the fd of /dev/cachefiles.

Note that this relies on the patch that adds reference counting to the req, otherwise it may UAF.(CVE-2024-40935)

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

KVM: Fix a data race on lastboostedvcpu in kvmvcpuon_spin()

Use {READ,WRITE}ONCE() to access kvm->lastboosted_vcpu to ensure the loads and stores are atomic. In the extremely unlikely scenario the compiler tears the stores, it's theoretically possible for KVM to attempt to get a vCPU using an out-of-bounds index, e.g. if the write is split into multiple 8-bit stores, and is paired with a 32-bit load on a VM with 257 vCPUs:

CPU0 CPU1 lastboostedvcpu = 0xff;

                                (last_boosted_vcpu = 0x100)
                                last_boosted_vcpu[15:8] = 0x01;

i = (lastboostedvcpu = 0x1ff) lastboostedvcpu[7:0] = 0x00;

vcpu = kvm->vcpu_array[0x1ff];

As detected by KCSAN:

BUG: KCSAN: data-race in kvmvcpuonspin [kvm] / kvmvcpuonspin [kvm]

write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16: kvmvcpuonspin (arch/x86/kvm/../../../virt/kvm/kvmmain.c:4112) kvm handlepause (arch/x86/kvm/vmx/vmx.c:5929) kvmintel vmxhandleexit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvmintel vcpurun (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvmarchvcpuioctlrun (arch/x86/kvm/x86.c:?) kvm kvmvcpuioctl (arch/x86/kvm/../../../virt/kvm/kvmmain.c:?) kvm _sesysioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) _x64sysioctl (fs/ioctl.c:890) x64syscall (arch/x86/entry/syscall64.c:33) dosyscall64 (arch/x86/entry/common.c:?) entrySYSCALL64afterhwframe (arch/x86/entry/entry_64.S:130)

read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4: kvmvcpuonspin (arch/x86/kvm/../../../virt/kvm/kvmmain.c:4069) kvm handlepause (arch/x86/kvm/vmx/vmx.c:5929) kvmintel vmxhandleexit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvmintel vcpurun (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvmarchvcpuioctlrun (arch/x86/kvm/x86.c:?) kvm kvmvcpuioctl (arch/x86/kvm/../../../virt/kvm/kvmmain.c:?) kvm _sesysioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) _x64sysioctl (fs/ioctl.c:890) x64syscall (arch/x86/entry/syscall64.c:33) dosyscall64 (arch/x86/entry/common.c:?) entrySYSCALL64afterhwframe (arch/x86/entry/entry_64.S:130)

value changed: 0x00000012 -> 0x00000000(CVE-2024-40953)

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

btrfs: zoned: allocate dummy checksums for zoned NODATASUM writes

Shin'ichiro reported that when he's running fstests' test-case btrfs/167 on emulated zoned devices, he's seeing the following NULL pointer dereference in 'btrfszonefinish_endio()':

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000011: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] CPU: 4 PID: 2332440 Comm: kworker/u80:15 Tainted: G W 6.10.0-rc2-kts+ #4 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Workqueue: btrfs-endio-write btrfsworkhelper [btrfs] RIP: 0010:btrfszonefinish_endio.part.0+0x34/0x160 [btrfs]

RSP: 0018:ffff88867f107a90 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff893e5534 RDX: 0000000000000011 RSI: 0000000000000004 RDI: 0000000000000088 RBP: 0000000000000002 R08: 0000000000000001 R09: ffffed1081696028 R10: ffff88840b4b0143 R11: ffff88834dfff600 R12: ffff88840b4b0000 R13: 0000000000020000 R14: 0000000000000000 R15: ffff888530ad5210 FS: 0000000000000000(0000) GS:ffff888e3f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f87223fff38 CR3: 00000007a7c6a002 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? diebody.cold+0x19/0x27 ? dieaddr+0x46/0x70 ? excgeneralprotection+0x14f/0x250 ? asmexcgeneralprotection+0x26/0x30 ? dorawreadunlock+0x44/0x70 ? btrfszonefinishendio.part.0+0x34/0x160 [btrfs] btrfsfinishoneordered+0x5d9/0x19a0 [btrfs] ? _pfxlockrelease+0x10/0x10 ? dorawwritelock+0x90/0x260 ? _pfxdorawwritelock+0x10/0x10 ? _pfxbtrfsfinishoneordered+0x10/0x10 [btrfs] ? rawwriteunlock+0x23/0x40 ? btrfsfinishorderedzoned+0x5a9/0x850 [btrfs] ? lockacquire+0x435/0x500 btrfsworkhelper+0x1b1/0xa70 [btrfs] ? _schedule+0x10a8/0x60b0 ? _pfxmightresched+0x10/0x10 processonework+0x862/0x1410 ? _pfxlockacquire+0x10/0x10 ? _pfxprocessonework+0x10/0x10 ? assignwork+0x16c/0x240 workerthread+0x5e6/0x1010 ? _pfxworkerthread+0x10/0x10 kthread+0x2c3/0x3a0 ? traceirqenable.constprop.0+0xce/0x110 ? _pfxkthread+0x10/0x10 retfromfork+0x31/0x70 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

Enabling CONFIGBTRFSASSERT revealed the following assertion to trigger:

assertion failed: !list_empty(&ordered->list), in fs/btrfs/zoned.c:1815

This indicates, that we're missing the checksums list on the ordered_extent. As btrfs/167 is doing a NOCOW write this is to be expected.

Further analysis with drgn confirmed the assumption:

>>> inode = prog.crashedthread().stacktrace()[11]['ordered'].inode >>> btrfsinode = drgn.containerof(inode, "struct btrfsinode", \ "vfsinode") >>> print(btrfs_inode.flags) (u32)1

As zoned emulation mode simulates conventional zones on regular devices, we cannot use zone-append for writing. But we're only attaching dummy checksums if we're doing a zone-append write.

So for NOCOW zoned data writes on conventional zones, also attach a dummy checksum.(CVE-2024-40962)

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

serial: imx: Introduce timeout when waiting on transmitter empty

By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential deadlock.

In case of the timeout, there is not much we can do, so we simply ignore the transmitter state and optimistically try to continue.(CVE-2024-40967)

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

batman-adv: bypass empty buckets in batadvpurgeorig_ref()

Many syzbot reports are pointing to soft lockups in batadvpurgeorig_ref() [1]

Root cause is unknown, but we can avoid spending too much time there and perhaps get more interesting reports.

[1]

watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621] Modules linked in: irq event stamp: 6182794 hardirqs last enabled at (6182793): [<ffff8000801dae10>] _localbhenableip+0x224/0x44c kernel/softirq.c:386 hardirqs last disabled at (6182794): [<ffff80008ad66a78>] _el1irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (6182794): [<ffff80008ad66a78>] el1interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (6182792): [<ffff80008aab71c4>] spinunlockbh include/linux/spinlock.h:396 [inline] softirqs last enabled at (6182792): [<ffff80008aab71c4>] batadvpurgeorigref+0x114c/0x1228 net/batman-adv/originator.c:1287 softirqs last disabled at (6182790): [<ffff80008aab61dc>] spinlockbh include/linux/spinlock.h:356 [inline] softirqs last disabled at (6182790): [<ffff80008aab61dc>] batadvpurgeorigref+0x164/0x1228 net/batman-adv/originator.c:1271 CPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Workqueue: batevents batadvpurgeorig pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : shouldresched arch/arm64/include/asm/preempt.h:79 [inline] pc : _localbhenableip+0x228/0x44c kernel/softirq.c:388 lr : _localbhenableip+0x224/0x44c kernel/softirq.c:386 sp : ffff800099007970 x29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000 x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001 x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4 x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0 x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001 x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003 x11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000 Call trace: _daiflocalirqenable arch/arm64/include/asm/irqflags.h:27 [inline] archlocalirqenable arch/arm64/include/asm/irqflags.h:49 [inline] _localbhenableip+0x228/0x44c kernel/softirq.c:386 _rawspinunlockbh include/linux/spinlockapismp.h:167 [inline] rawspinunlockbh+0x3c/0x4c kernel/locking/spinlock.c:210 spinunlockbh include/linux/spinlock.h:396 [inline] batadvpurgeorigref+0x114c/0x1228 net/batman-adv/originator.c:1287 batadvpurgeorig+0x20/0x70 net/batman-adv/originator.c:1300 processonework+0x694/0x1204 kernel/workqueue.c:2633 processscheduledworks kernel/workqueue.c:2706 [inline] workerthread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 retfromfork+0x10/0x20 arch/arm64/kernel/entry.S:860 Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : archlocalirqenable+0x8/0xc arch/arm64/include/asm/irqflags.h:51 lr : defaultidle_call+0xf8/0x128 kernel/sched/idle.c:103 sp : ffff800093a17d30 x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4 x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002 x23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000 x20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396 x17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001 ---truncated---(CVE-2024-40981)

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

netrom: Fix a memory leak in nrheartbeatexpiry()

syzbot reported a memory leak in nr_create() [0].

Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.") added sockhold() to the nrheartbeatexpiry() function, where a) a socket has a SOCKDESTROY flag or b) a listening socket has a SOCK_DEAD flag.

But in the case "a," when the SOCKDESTROY flag is set, the file descriptor has already been closed and the nrrelease() function has been called. So it makes no sense to hold the reference count because no one will call another nrdestroysocket() and put it as in the case "b."

nrconnect nrestablishdatalink nrstartheartbeat

nrrelease switch (nr->state) case NRSTATE3 nr->state = NRSTATE2 socksetflag(sk, SOCKDESTROY);

                    nr_rx_frame
                      nr_process_rx_frame
                        switch (nr->state)
                        case NR_STATE_2
                          nr_state2_machine()
                            nr_disconnect()
                              nr_sk(sk)->state = NR_STATE_0
                              sock_set_flag(sk, SOCK_DEAD)

                    nr_heartbeat_expiry
                      switch (nr->state)
                      case NR_STATE_0
                        if (sock_flag(sk, SOCK_DESTROY) ||
                           (sk->sk_state == TCP_LISTEN
                             && sock_flag(sk, SOCK_DEAD)))
                           sock_hold()  // ( !!! )
                           nr_destroy_socket()

To fix the memory leak, let's call sock_hold() only for a listening socket.

Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.

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

bpf: Fix too early release of tcx_entry

Pedro Pinto and later independently also Hyunwoo Kim and Wongi Lee reported an issue that the tcx_entry can be released too early leading to a use after free (UAF) when an active old-style ingress or clsact qdisc with a shared tc block is later replaced by another ingress or clsact instance.

Essentially, the sequence to trigger the UAF (one example) can be as follows:

1. A network namespace is created
2. An ingress qdisc is created. This allocates a tcxentry, and &tcxentry->miniq is stored in the qdisc's miniqp->p_miniq. At the same time, a tcf block with index 1 is created.
3. chain0 is attached to the tcf block. chain0 must be connected to the block linked to the ingress qdisc to later reach the function tcfchain0headchangecb_del() which triggers the UAF.

4. Create and graft a clsact qdisc. This causes the ingress qdisc created in step 1 to be removed, thus freeing the previously linked tcx_entry:

   rtnetlinkrcvmsg() => tcmodifyqdisc() => qdisccreate() => clsactinit() [a] => qdiscgraft() => qdiscdestroy() => _qdiscdestroy() => ingressdestroy() [b] => tcxentryfree() => kfreercu() // tcx_entry freed

5. Finally, the network namespace is closed. This registers the cleanupnet worker, and during the process of releasing the remaining clsact qdisc, it accesses the tcxentry that was already freed in step 4, causing the UAF to occur:

   cleanupnet() => opsexitlist() => defaultdeviceexitbatch() => unregisternetdevicemany() => unregisternetdevicemanynotify() => devshutdown() => qdiscput() => clsactdestroy() [c] => tcfblockputext() => tcfchain0headchangecbdel() => tcfchainheadchangeitem() => clsactchainheadchange() => miniqdiscpairswap() // UAF

There are also other variants, the gist is to add an ingress (or clsact) qdisc with a specific shared block, then to replace that qdisc, waiting for the tcxentry kfreercu() to be executed and subsequently accessing the current active qdisc's miniq one way or another.

The correct fix is to turn the miniqactive boolean into a counter. What can be observed, at step 2 above, the counter transitions from 0->1, at step [a] from 1->2 (in order for the miniq object to remain active during the replacement), then in [b] from 2->1 and finally [c] 1->0 with the eventual release. The reference counter in general ranges from [0,2] and it does not need to be atomic since all access to the counter is protected by the rtnl mutex. With this in place, there is no longer a UAF happening and the tcxentry is freed at the correct time.(CVE-2024-41010)

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

xfs: don't walk off the end of a directory data block

This adds sanity checks for xfsdir2dataunused and xfsdir2dataentry to make sure don't stray beyond valid memory region. Before patching, the loop simply checks that the start offset of the dup and dep is within the range. So in a crafted image, if last entry is xfsdir2data_unused, we can change dup->length to dup->length-1 and leave 1 byte of space. In the next traversal, this space will be considered as dup or dep. We may encounter an out of bound read when accessing the fixed members.

In the patch, we make sure that the remaining bytes large enough to hold an unused entry before accessing xfsdir2dataunused and xfsdir2dataunused is XFSDIR2DATAALIGN byte aligned. We also make sure that the remaining bytes large enough to hold a dirent with a single-byte name before accessing xfsdir2dataentry.(CVE-2024-41013)

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

xfs: add bounds checking to xlogrecoverprocess_data

There is a lack of verification of the space occupied by fixed members of xlogopheader in the xlogrecoverprocess_data.

We can create a crafted image to trigger an out of bounds read by following these steps: 1) Mount an image of xfs, and do some file operations to leave records 2) Before umounting, copy the image for subsequent steps to simulate abnormal exit. Because umount will ensure that tailblk and headblk are the same, which will result in the inability to enter xlogrecoverprocessdata 3) Write a tool to parse and modify the copied image in step 2 4) Make the end of the xlogopheader entries only 1 byte away from xlogrecheader->hsize 5) xlogrecheader->hnumlogops++ 6) Modify xlogrecheader->h_crc

Fix: Add a check to make sure there is sufficient space to access fixed members of xlogopheader.(CVE-2024-41014)

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

fs/ntfs3: Add a check for attr_names and oatbl

Added out-of-bound checking for *ane (ATTRNAMEENTRY).(CVE-2024-41018)

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

fs/ntfs3: Validate ff offset

This adds sanity checks for ff offset. There is a check on rt->first_free at first, but walking through by ff without any check. If the second ff is a large offset. We may encounter an out-of-bound read.(CVE-2024-41019)

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

filelock: Fix fcntl/close race recovery compat path

When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when fcntl/close race is detected"), I missed that there are two copies of the code I was patching: The normal version, and the version for 64-bit offsets on 32-bit kernels. Thanks to Greg KH for stumbling over this while doing the stable backport...

Apply exactly the same fix to the compat path for 32-bit kernels.(CVE-2024-41020)

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

s390/mm: Fix VMFAULTHWPOISON handling in do_exception()

There is no support for HWPOISON, MEMORYFAILURE, or ARCHHASCOPYMC on s390. Therefore we do not expect to see VMFAULTHWPOISON in do_exception().

However, since commit af19487f00f3 ("mm: make PTEMARKERSWAPINERROR more general"), it is possible to see VMFAULTHWPOISON in combination with PTEMARKERPOISONED, even on architectures that do not support HWPOISON otherwise. In this case, we will end up on the BUG() in doexception().

Fix this by treating VMFAULTHWPOISON the same as VMFAULTSIGBUS, similar to x86 when MEMORY_FAILURE is not configured. Also print unexpected fault flags, for easier debugging.

Note that VMFAULTHWPOISON_LARGE is not expected, because s390 cannot support swap entries on other levels than PTE level.(CVE-2024-41021)

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

sched/deadline: Fix task_struct reference leak

During the execution of the following stress test with linux-rt:

stress-ng --cyclic 30 --timeout 30 --minimize --quiet

kmemleak frequently reported a memory leak concerning the task_struct:

unreferenced object 0xffff8881305b8000 (size 16136): comm "stress-ng", pid 614, jiffies 4294883961 (age 286.412s) object hex dump (first 32 bytes): 02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .@.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ debug hex dump (first 16 bytes): 53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 S............... backtrace: [<00000000046b6790>] duptaskstruct+0x30/0x540 [<00000000c5ca0f0b>] copyprocess+0x3d9/0x50e0 [<00000000ced59777>] kernelclone+0xb0/0x770 [<00000000a50befdc>] _dosysclone+0xb6/0xf0 [<000000001dbf2008>] dosyscall64+0x5d/0xf0 [<00000000552900ff>] entrySYSCALL64after_hwframe+0x6e/0x76

The issue occurs in startdltimer(), which increments the taskstruct reference count and sets a timer. The timer callback, dltasktimer, is supposed to decrement the reference count upon expiration. However, if enqueuetask_dl() is called before the timer expires and cancels it, the reference count is not decremented, leading to the leak.

This patch fixes the reference leak by ensuring the task_struct reference count is properly decremented when the timer is canceled.(CVE-2024-41023)

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

firmware: cs_dsp: Fix overflow checking of wmfw header

Fix the checking that firmware file buffer is large enough for the wmfw header, to prevent overrunning the buffer.

The original code tested that the firmware data buffer contained enough bytes for the sums of the size of the structs

wmfw_header + wmfw_adsp1_sizes + wmfw_footer

But wmfwadsp1sizes is only used on ADSP1 firmware. For ADSP2 and Halo Core the equivalent struct is wmfwadsp2sizes, which is 4 bytes longer. So the length check didn't guarantee that there are enough bytes in the firmware buffer for a header with wmfwadsp2sizes.

This patch splits the length check into three separate parts. Each of the wmfwheader, wmfwadsp?sizes and wmfwfooter are checked separately before they are used.(CVE-2024-41039)

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

net/sched: Fix UAF when resolving a clash

KASAN reports the following UAF:

BUG: KASAN: slab-use-after-free in tcfctflowtableprocessconn+0x12b/0x380 [actct] Read of size 1 at addr ffff888c07603600 by task handler130/6469

Call Trace: <IRQ> dumpstacklvl+0x48/0x70 printaddressdescription.constprop.0+0x33/0x3d0 printreport+0xc0/0x2b0 kasanreport+0xd0/0x120 _asanload1+0x6c/0x80 tcfctflowtableprocessconn+0x12b/0x380 [actct] tcfctact+0x886/0x1350 [actct] tcfactionexec+0xf8/0x1f0 flclassify+0x355/0x360 [clsflower] _tcfclassify+0x1fd/0x330 tcfclassify+0x21c/0x3c0 schhandleingress.constprop.0+0x2c5/0x500 _netifreceiveskbcore.constprop.0+0xb25/0x1510 _netifreceiveskblistcore+0x220/0x4c0 netifreceiveskblistinternal+0x446/0x620 napicompletedone+0x157/0x3d0 grocellpoll+0xcf/0x100 _napipoll+0x65/0x310 netrxaction+0x30c/0x5c0 _dosoftirq+0x14f/0x491 _irqexitrcu+0x82/0xc0 irqexitrcu+0xe/0x20 commoninterrupt+0xa1/0xb0 </IRQ> <TASK> asmcommon_interrupt+0x27/0x40

Allocated by task 6469: kasansavestack+0x38/0x70 kasansettrack+0x25/0x40 kasansaveallocinfo+0x1e/0x40 _kasankrealloc+0x133/0x190 krealloc+0xaa/0x130 nfctextadd+0xed/0x230 [nfconntrack] tcfctact+0x1095/0x1350 [actct] tcfactionexec+0xf8/0x1f0 flclassify+0x355/0x360 [clsflower] _tcfclassify+0x1fd/0x330 tcfclassify+0x21c/0x3c0 schhandleingress.constprop.0+0x2c5/0x500 _netifreceiveskbcore.constprop.0+0xb25/0x1510 _netifreceiveskblistcore+0x220/0x4c0 netifreceiveskblistinternal+0x446/0x620 napicompletedone+0x157/0x3d0 grocellpoll+0xcf/0x100 _napipoll+0x65/0x310 netrxaction+0x30c/0x5c0 _dosoftirq+0x14f/0x491

Freed by task 6469: kasansavestack+0x38/0x70 kasansettrack+0x25/0x40 kasansavefreeinfo+0x2b/0x60 __kasanslabfree+0x180/0x1f0 _kasanslabfree+0x12/0x30 slabfreefreelisthook+0xd2/0x1a0 _kmemcachefree+0x1a2/0x2f0 kfree+0x78/0x120 nfconntrackfree+0x74/0x130 [nfconntrack] nfctdestroy+0xb2/0x140 [nfconntrack] _nfctresolveclash+0x529/0x5d0 [nfconntrack] nfctresolveclash+0xf6/0x490 [nfconntrack] _nfconntrackconfirm+0x2c6/0x770 [nfconntrack] tcfctact+0x12ad/0x1350 [actct] tcfactionexec+0xf8/0x1f0 flclassify+0x355/0x360 [clsflower] _tcfclassify+0x1fd/0x330 tcfclassify+0x21c/0x3c0 schhandleingress.constprop.0+0x2c5/0x500 _netifreceiveskbcore.constprop.0+0xb25/0x1510 _netifreceiveskblistcore+0x220/0x4c0 netifreceiveskblistinternal+0x446/0x620 napicompletedone+0x157/0x3d0 grocellpoll+0xcf/0x100 _napipoll+0x65/0x310 netrxaction+0x30c/0x5c0 _dosoftirq+0x14f/0x491

The ct may be dropped if a clash has been resolved but is still passed to the tcfctflowtableprocess_conn function for further usage. This issue can be fixed by retrieving ct from skb again after confirming conntrack.(CVE-2024-41040)

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

udp: Set SOCKRCUFREE earlier in udplibget_port().

syzkaller triggered the warning [0] in udpv4early_demux().

In udpv[46]earlydemux() and sklookup(), we do not touch the refcount of the looked-up sk and use sockpfree() as skb->destructor, so we check SOCKRCU_FREE to ensure that the sk is safe to access during the RCU grace period.

Currently, SOCKRCUFREE is flagged for a bound socket after being put into the hash table. Moreover, the SOCKRCUFREE check is done too early in udpv[46]earlydemux() and sklookup(), so there could be a small race window:

CPU1 CPU2 ---- ---- udpv4earlydemux() udplibgetport() | |- hlistaddheadrcu() |- sk = _udp4libdemuxlookup() | |- DEBUGNETWARNONONCE(skisrefcounted(sk)); `- socksetflag(sk, SOCKRCU_FREE)

We had the same bug in TCP and fixed it in commit 871019b22d1b ("net: set SOCKRCUFREE before inserting socket into hashtable").

Let's apply the same fix for UDP.

Modules linked in: CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:udpv4earlydemux+0x481/0xb70 net/ipv4/udp.c:2599 Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe <0f> 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52 RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c RDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001 RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680 R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e FS: 00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <TASK> iprcvfinishcore.constprop.0+0xbdd/0xd20 net/ipv4/ipinput.c:349 iprcvfinish+0xda/0x150 net/ipv4/ipinput.c:447 NFHOOK include/linux/netfilter.h:314 [inline] NFHOOK include/linux/netfilter.h:308 [inline] iprcv+0x16c/0x180 net/ipv4/ipinput.c:569 _netifreceiveskbonecore+0xb3/0xe0 net/core/dev.c:5624 _netifreceiveskb+0x21/0xd0 net/core/dev.c:5738 netifreceiveskbinternal net/core/dev.c:5824 [inline] netifreceiveskb+0x271/0x300 net/core/dev.c:5884 tunrxbatched drivers/net/tun.c:1549 [inline] tungetuser+0x24db/0x2c50 drivers/net/tun.c:2002 tunchrwriteiter+0x107/0x1a0 drivers/net/tun.c:2048 newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0x76f/0x8d0 fs/readwrite.c:590 ksyswrite+0xbf/0x190 fs/readwrite.c:643 _dosyswrite fs/readwrite.c:655 [inline] _sesyswrite fs/readwrite.c:652 [inline] _x64syswrite+0x41/0x50 fs/readwrite.c:652 x64syscall+0xe66/0x1990 arch/x86/include/generated/asm/syscalls64.h:2 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x4b/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7fc44a68bc1f Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48 RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f R ---truncated---(CVE-2024-41041)

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

ppp: reject claimed-as-LCP but actually malformed packets

Since 'pppasyncencode()' assumes valid LCP packets (with code from 1 to 7 inclusive), add 'pppcheckpacket()' to ensure that LCP packet has an actual body beyond PPP_LCP header bytes, and reject claimed-as-LCP but actually malformed data otherwise.(CVE-2024-41044)

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

bpf: Defer work in bpftimercancelandfree

Currently, the same case as previous patch (two timer callbacks trying to cancel each other) can be invoked through bpfmapupdateelem as well, or more precisely, freeing map elements containing timers. Since this relies on hrtimercancel as well, it is prone to the same deadlock situation as the previous patch.

It would be sufficient to use hrtimertrytocancel to fix this problem, as the timer cannot be enqueued after asynccancelandfree. Once asynccancelandfree has been done, the timer must be reinitialized before it can be armed again. The callback running in parallel trying to arm the timer will fail, and freeing bpfhrtimer without waiting is sufficient (given kfreercu), and bpftimercb will return HRTIMERNORESTART, preventing the timer from being rearmed again.

However, there exists a UAF scenario where the callback arms the timer before entering this function, such that if cancellation fails (due to timer callback invoking this routine, or the target timer callback running concurrently). In such a case, if the timer expiration is significantly far in the future, the RCU grace period expiration happening before it will free the bpf_hrtimer state and along with it the struct hrtimer, that is enqueued.

Hence, it is clear cancellation needs to occur after asynccancelandfree, and yet it cannot be done inline due to deadlock issues. We thus modify bpftimercancelandfree to defer work to the global workqueue, adding a workstruct alongside rcuhead (both used at _different points of time, so can share space).

Update existing code comments to reflect the new state of affairs.(CVE-2024-41045)

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

skmsg: Skip zero length skb in skmsgrecvmsg

When running BPF selftests (./testprogs -t sockmapbasic) on a Loongarch platform, the following kernel panic occurs:

[...] Oops[#1]: CPU: 22 PID: 2824 Comm: testprogs Tainted: G OE 6.10.0-rc2+ #18 Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018 ... ... ra: 90000000048bf6c0 skmsgrecvmsg+0x120/0x560 ERA: 9000000004162774 copypagetoiter+0x74/0x1c0 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 0000000c (PPLV0 +PIE +PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) BADV: 0000000000000040 PRID: 0014c011 (Loongson-64bit, Loongson-3C5000) Modules linked in: bpftestmod(OE) xtCHECKSUM xtMASQUERADE xtconntrack Process testprogs (pid: 2824, threadinfo=0000000000863a31, task=...) Stack : ... Call Trace: [<9000000004162774>] copypagetoiter+0x74/0x1c0 [<90000000048bf6c0>] skmsgrecvmsg+0x120/0x560 [<90000000049f2b90>] tcpbpfrecvmsgparser+0x170/0x4e0 [<90000000049aae34>] inetrecvmsg+0x54/0x100 [<900000000481ad5c>] sockrecvmsg+0x7c/0xe0 [<900000000481e1a8>] _sysrecvfrom+0x108/0x1c0 [<900000000481e27c>] sysrecvfrom+0x1c/0x40 [<9000000004c076ec>] dosyscall+0x8c/0xc0 [<9000000003731da4>] handlesyscall+0xc4/0x160 Code: ... ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception Kernel relocated by 0x3510000 .text @ 0x9000000003710000 .data @ 0x9000000004d70000 .bss @ 0x9000000006469400 ---[ end Kernel panic - not syncing: Fatal exception ]--- [...]

This crash happens every time when running sockmapskbverdictshutdown subtest in sockmapbasic.

This crash is because a NULL pointer is passed to pageaddress() in the skmsgrecvmsg(). Due to the different implementations depending on the architecture, pageaddress(NULL) will trigger a panic on Loongarch platform but not on x86 platform. So this bug was hidden on x86 platform for a while, but now it is exposed on Loongarch platform. The root cause is that a zero length skb (skb->len == 0) was put on the queue.

This zero length skb is a TCP FIN packet, which was sent by shutdown(), invoked in testsockmapskbverdictshutdown():

shutdown(p1, SHUT_WR);

In this case, in skpsockskbingressenqueue(), numsge is zero, and no page is put to this sge (see sgsetpage in sgsetpage), but this empty sge is queued into ingressmsg list.

And in skmsgrecvmsg(), this empty sge is used, and a NULL page is got by sgpage(sge). Pass this NULL page to copypagetoiter(), which passes it to kmaplocalpage() and to page_address(), then kernel panics.

To solve this, we should skip this zero length skb. So in skmsgrecvmsg(), if copy is zero, that means it's a zero length skb, skip invoking copypagetoiter(). We are using the EFAULT return triggered by copypagetoiter to check for isfin in tcpbpf.c.(CVE-2024-41048)

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

filelock: fix potential use-after-free in posixlockinode

Light Hsieh reported a KASAN UAF warning in traceposixlock_inode(). The request pointer had been changed earlier to point to a lock entry that was added to the inode's list. However, before the tracepoint could fire, another task raced in and freed that lock.

Fix this by moving the tracepoint inside the spinlock, which should ensure that this doesn't happen.(CVE-2024-41049)

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

firmware: cs_dsp: Use strnlen() on name fields in V1 wmfw files

Use strnlen() instead of strlen() on the algorithm and coefficient name string arrays in V1 wmfw files.

In V1 wmfw files the name is a NUL-terminated string in a fixed-size array. cs_dsp should protect against overrunning the array if the NUL terminator is missing.(CVE-2024-41056)

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

bluetooth/l2cap: sync sock recv cb and release

The problem occurs between the system call to close the sock and hcirxwork, where the former releases the sock and the latter accesses it without lock protection.

       CPU0                       CPU1
       ----                       ----
       sock_close                 hci_rx_work
   l2cap_sock_release         hci_acldata_packet
   l2cap_sock_kill            l2cap_recv_frame
   sk_free                    l2cap_conless_channel
                              l2cap_sock_recv_cb

If hcirxwork processes the data that needs to be received before the sock is closed, then everything is normal; Otherwise, the work thread may access the released sock when receiving data.

Add a chan mutex in the rx callback of the sock to achieve synchronization between the sock release and recv cb.

Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.(CVE-2024-41062)

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

Bluetooth: hcicore: cancel all works upon hciunregister_dev()

syzbot is reporting that calling hcireleasedev() from hcierrorreset() due to hcidevput() from hcierrorreset() can cause deadlock at destroyworkqueue(), for hcierrorreset() is called from hdev->reqworkqueue which destroy_workqueue() needs to flush.

We need to make sure that hdev->{rxwork,cmdwork,txwork} which are queued into hdev->workqueue and hdev->{poweron,errorreset} which are queued into hdev->reqworkqueue are no longer running by the moment

   destroy_workqueue(hdev->workqueue);
   destroy_workqueue(hdev->req_workqueue);

are called from hcireleasedev().

Call cancelworksync() on these work items from hciunregisterdev() as soon as hdev->list is removed from hcidevlist.(CVE-2024-41063)

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

powerpc/eeh: avoid possible crash when edev->pdev changes

If a PCI device is removed during eehpereport_edev(), edev->pdev will change and can cause a crash, hold the PCI rescan/remove lock while taking a copy of edev->pdev->bus.(CVE-2024-41064)

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

ASoC: topology: Fix references to freed memory

Most users after parsing a topology file, release memory used by it, so having pointer references directly into topology file contents is wrong. Use devm_kmemdup(), to allocate memory as needed.(CVE-2024-41069)

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

wifi: cfg80211: wext: add extra SIOCSIWSCAN data check

In 'cfg80211wextsiwscan()', add extra check whether number of channels passed via 'ioctl(sock, SIOCSIWSCAN, ...)' doesn't exceed IWMAXFREQUENCIES and reject invalid request with -EINVAL otherwise.(CVE-2024-41072)

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

nvme: avoid double free special payload

If a discard request needs to be retried, and that retry may fail before a new special payload is added, a double free will result. Clear the RQFSPECIALLOAD when the request is cleaned.(CVE-2024-41073)

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

cachefiles: Set object to close if ondemand_id < 0 in copen

If copen is maliciously called in the user mode, it may delete the request corresponding to the random id. And the request may have not been read yet.

Note that when the object is set to reopen, the open request will be done with the still reopen state in above case. As a result, the request corresponding to this object is always skipped in select_req function, so the read request is never completed and blocks other process.

Fix this issue by simply set object to close if its id < 0 in copen.(CVE-2024-41074)

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

cachefiles: add consistency check for copen/cread

This prevents malicious processes from completing random copen/cread requests and crashing the system. Added checks are listed below:

• Generic, copen can only complete open requests, and cread can only complete read requests.
• For copen, ondemand_id must not be 0, because this indicates that the request has not been read by the daemon.
• For cread, the object corresponding to fd and req should be the same.(CVE-2024-41075)

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

NFSv4: Fix memory leak in nfs4setsecurity_label

We leak nfsfattr and nfs4label every time we set a security xattr.(CVE-2024-41076)

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

null_blk: fix validation of block size

Block size should be between 512 and PAGE_SIZE and be a power of 2. The current check does not validate this, so update the check.

Without this patch, null_blk would Oops due to a null pointer deref when loaded with bs=1536 [1].

axboe: remove unnecessary braces and != 0 check

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

iouring: fix possible deadlock in ioregisteriowqmax_workers()

The ioregisteriowqmaxworkers() function calls ioputsqdata(), which acquires the sqd->lock without releasing the uringlock. Similar to the commit 009ad9f0c6ee ("iouring: drop ctx->uringlock before acquiring sqd->lock"), this can lead to a potential deadlock situation.

To resolve this issue, the uringlock is released before calling ioputsqdata(), and then it is re-acquired after the function call.

This change ensures that the locks are acquired in the correct order, preventing the possibility of a deadlock.(CVE-2024-41080)

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

cxl/mem: Fix no cxl_nvd during pmem region auto-assembling

When CXL subsystem is auto-assembling a pmem region during cxl endpoint port probing, always hit below calltrace.

BUG: kernel NULL pointer dereference, address: 0000000000000078 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page RIP: 0010:cxlpmemregionprobe+0x22e/0x360 [cxlpmem] Call Trace: <TASK> ? die+0x24/0x70 ? pagefaultoops+0x82/0x160 ? douseraddrfault+0x65/0x6b0 ? excpagefault+0x7d/0x170 ? asmexcpagefault+0x26/0x30 ? cxlpmemregionprobe+0x22e/0x360 [cxlpmem] ? cxlpmemregionprobe+0x1ac/0x360 [cxlpmem] cxlbusprobe+0x1b/0x60 [cxlcore] reallyprobe+0x173/0x410 ? _pfxdeviceattachdriver+0x10/0x10 _driverprobedevice+0x80/0x170 driverprobedevice+0x1e/0x90 _deviceattachdriver+0x90/0x120 busforeachdrv+0x84/0xe0 _deviceattach+0xbc/0x1f0 busprobedevice+0x90/0xa0 deviceadd+0x51c/0x710 devmcxladdpmemregion+0x1b5/0x380 [cxlcore] cxlbusprobe+0x1b/0x60 [cxl_core]

The cxlnvd of the memdev needs to be available during the pmem region probe. Currently the cxlnvd is registered after the endpoint port probe. The endpoint probe, in the case of autoassembly of regions, can cause a pmem region probe requiring the not yet available cxl_nvd. Adjust the sequence so this dependency is met.

This requires adding a port parameter to cxlfindnvdimm_bridge() that can be used to query the ancestor root port. The endpoint port is not yet available, but will share a common ancestor with its parent, so start the query from there instead.(CVE-2024-41085)

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

tap: add missing verification for short frame

The cited commit missed to check against the validity of the frame length in the tapgetuserxdp() path, which could cause a corrupted skb to be sent downstack. Even before the skb is transmitted, the tapgetuserxdp()-->skbsetnetworkheader() may assume the size is more than ETHHLEN. Once transmitted, this could either cause out-of-bound access beyond the actual length, or confuse the underlayer with incorrect or inconsistent header length in the skb metadata.

In the alternative path, tapgetuser() already prohibits short frame which has the length less than Ethernet header size from being transmitted.

This is to drop any frame shorter than the Ethernet header size just like how tapgetuser() does.

CVE: CVE-2024-41090(CVE-2024-41090)

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

tun: add missing verification for short frame

The cited commit missed to check against the validity of the frame length in the tunxdpone() path, which could cause a corrupted skb to be sent downstack. Even before the skb is transmitted, the tunxdpone-->ethtypetrans() may access the Ethernet header although it can be less than ETH_HLEN. Once transmitted, this could either cause out-of-bound access beyond the actual length, or confuse the underlayer with incorrect or inconsistent header length in the skb metadata.

In the alternative path, tungetuser() already prohibits short frame which has the length less than Ethernet header size from being transmitted for IFF_TAP.

This is to drop any frame shorter than the Ethernet header size just like how tungetuser() does.

CVE: CVE-2024-41091(CVE-2024-41091)

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

PCI/MSI: Fix UAF in msicapabilityinit

KFENCE reports the following UAF:

BUG: KFENCE: use-after-free read in _pcienablemsirange+0x2c0/0x488

Use-after-free read at 0x0000000024629571 (in kfence-#12): _pcienablemsirange+0x2c0/0x488 pciallocirqvectorsaffinity+0xec/0x14c pciallocirq_vectors+0x18/0x28

kfence-#12: 0x0000000008614900-0x00000000e06c228d, size=104, cache=kmalloc-128

allocated by task 81 on cpu 7 at 10.808142s: _kmemcacheallocnode+0x1f0/0x2bc kmalloctrace+0x44/0x138 msiallocdesc+0x3c/0x9c msidomaininsertmsidesc+0x30/0x78 msisetupmsidesc+0x13c/0x184 _pcienablemsirange+0x258/0x488 pciallocirqvectorsaffinity+0xec/0x14c pciallocirq_vectors+0x18/0x28

freed by task 81 on cpu 7 at 10.811436s: msidomainfreedescs+0xd4/0x10c msidomainfreelocked.part.0+0xc0/0x1d8 msidomainallocirqsalllocked+0xb4/0xbc pcimsisetupmsiirqs+0x30/0x4c _pcienablemsirange+0x2a8/0x488 pciallocirqvectorsaffinity+0xec/0x14c pciallocirqvectors+0x18/0x28

Descriptor allocation done in: _pcienablemsirange msicapabilityinit msisetupmsidesc msiinsertmsidesc msidomaininsertmsidesc msiallocdesc ...

Freed in case of failure in _msidomainalloclocked() _pcienablemsirange msicapabilityinit pcimsisetupmsiirqs msidomainallocirqsalllocked msidomainalloclocked _msidomainalloclocked => fails msidomainfree_locked ...

That failure propagates back to pcimsisetupmsiirqs() in msicapabilityinit() which accesses the descriptor for unmasking in the error exit path.

Cure it by copying the descriptor and using the copy for the error exit path unmask operation.

tglx: Massaged change log

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

bpf: Take return from setmemoryro() into account with bpfproglock_ro()

setmemoryro() can fail, leaving memory unprotected.

Check its return and take it into account as an error.(CVE-2024-42068)

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

iio: chemical: bme680: Fix overflows in compensate() functions

There are cases in the compensate functions of the driver that there could be overflows of variables due to bit shifting ops. These implications were initially discussed here [1] and they were mentioned in log message of Commit 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor").

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

ALSA: emux: improve patch ioctl data validation

In loaddata(), make the validation of and skipping over the main info block match that in loadguspatch().

In loadguspatch(), add checking that the specified patch length matches the actually supplied data, like loaddata() already did.(CVE-2024-42097)

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

jffs2: Fix potential illegal address access in jffs2freeinode

During the stress testing of the jffs2 file system,the following abnormal printouts were found: [ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948 [ 2430.649622] Mem abort info: [ 2430.649829] ESR = 0x96000004 [ 2430.650115] EC = 0x25: DABT (current EL), IL = 32 bits [ 2430.650564] SET = 0, FnV = 0 [ 2430.650795] EA = 0, S1PTW = 0 [ 2430.651032] FSC = 0x04: level 0 translation fault [ 2430.651446] Data abort info: [ 2430.651683] ISV = 0, ISS = 0x00000004 [ 2430.652001] CM = 0, WnR = 0 [ 2430.652558] [0069696969696948] address between user and kernel address ranges [ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33 [ 2430.655008] Hardware name: linux,dummy-virt (DT) [ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2430.656142] pc : kfree+0x78/0x348 [ 2430.656630] lr : jffs2freeinode+0x24/0x48 [ 2430.657051] sp : ffff800009eebd10 [ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000 [ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000 [ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14 [ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000 [ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000 [ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19 [ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14 [ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302 [ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342 [ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000 [ 2430.664217] Call trace: [ 2430.664528] kfree+0x78/0x348 [ 2430.664855] jffs2freeinode+0x24/0x48 [ 2430.665233] icallback+0x24/0x50 [ 2430.665528] rcudobatch+0x1ac/0x448 [ 2430.665892] rcucore+0x28c/0x3c8 [ 2430.666151] rcucoresi+0x18/0x28 [ 2430.666473] _dosoftirq+0x138/0x3cc [ 2430.666781] irqexit+0xf0/0x110 [ 2430.667065] handledomainirq+0x6c/0x98 [ 2430.667447] gichandleirq+0xac/0xe8 [ 2430.667739] callonirqstack+0x28/0x54 The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of the jffsinodeinfo structure. It was found that all variables in the jffsinodeinfo structure were 5a5a5a5a, except for the first member sem. It is suspected that these variables are not initialized because they were set to 5a5a5a5a during memory testing, which is meant to detect uninitialized memory.The sem variable is initialized in the function jffs2iinitonce, while other members are initialized in the function jffs2initinodeinfo.

The function jffs2initinodeinfo is called after igetlocked, but in the igetlocked function, the destroyinode process is triggered, which releases the inode and consequently, the target member of the inode is not initialized.In concurrent high pressure scenarios, igetlocked may enter the destroyinode branch as described in the code.

Since the destroyinode functionality of jffs2 only releases the target, the fix method is to set target to NULL in jffs2iinitonce.(CVE-2024-42115)

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

powerpc: Avoid nmienter/nmiexit in real mode interrupt.

nmienter()/nmiexit() touches per cpu variables which can lead to kernel crash when invoked during real mode interrupt handling (e.g. early HMI/MCE interrupt handler) if percpu allocation comes from vmalloc area.

Early HMI/MCE handlers are called through DEFINEINTERRUPTHANDLERNMI() wrapper which invokes nmienter/nmiexit calls. We don't see any issue when percpu allocation is from the embedded first chunk. However with CONFIGNEEDPERCPUPAGEFIRST_CHUNK enabled there are chances where percpu allocation can come from the vmalloc area.

With kernel command line "percpualloc=page" we can force percpu allocation to come from vmalloc area and can see kernel crash in machinecheck_early:

[ 1.215714] NIP [c000000000e49eb4] rcunmienter+0x24/0x110 [ 1.215717] LR [c0000000000461a0] machinecheckearly+0xf0/0x2c0 [ 1.215719] --- interrupt: 200 [ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable) [ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0 [ 1.215724] [c000000fffd73210] [c000000000008364] machinecheckearly_common+0x134/0x1f8

Fix this by avoiding use of nmienter()/nmiexit() in real mode if percpu first chunk is not embedded.(CVE-2024-42126)

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

leds: mlxreg: Use devmmutexinit() for mutex initialization

In this driver LEDs are registered using devmledclassdevregister() so they are automatically unregistered after module's remove() is done. ledclassdevunregister() calls module's ledset_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead.(CVE-2024-42129)

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

s390/pkey: Wipe copies of protected- and secure-keys

Although the clear-key of neither protected- nor secure-keys is accessible, this key material should only be visible to the calling process. So wipe all copies of protected- or secure-keys from stack, even in case of an error.(CVE-2024-42155)

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

gve: Account for stopped queues when reading NIC stats

We now account for the fact that the NIC might send us stats for a subset of queues. Without this change, gvegetethtoolstats might make an invalid access on the priv->statsreport->stats array.(CVE-2024-42162)

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

drm/amdgpu: Using uninitialized value *size when calling amdgpuvcecs_reloc

Initialize the size before calling amdgpuvcecs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)(CVE-2024-42228)