OESA-2024-1941

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

clk: sunxi-ng: Unregister clocks/resets when unbinding

Currently, unbinding a CCU driver unmaps the device's MMIO region, while leaving its clocks/resets and their providers registered. This can cause a page fault later when some clock operation tries to perform MMIO. Fix this by separating the CCU initialization from the memory allocation, and then using a devres callback to unregister the clocks and resets.

This also fixes a memory leak of the struct ccu_reset, and uses the correct owner (the specific platform driver) for the clocks and resets.

Early OF clock providers are never unregistered, and limited error handling is possible, so they are mostly unchanged. The error reporting is made more consistent by moving the message inside ofsunxiccu_probe.(CVE-2021-47205)

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

thermal/int340xthermal: handle datavault when the value is ZEROSIZEPTR

In some case, the GDDV returns a package with a buffer which has zero length. It causes that kmemdup() returns ZEROSIZEPTR (0x10).

Then the datavaultread() got NULL point dereference problem when accessing the 0x10 value in data_vault.

[ 71.024560] BUG: kernel NULL pointer dereference, address: 0000000000000010

This patch uses ZEROORNULLPTR() for checking ZEROSIZEPTR or NULL value in datavault.(CVE-2022-48703)

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

net/smc: Avoid overwriting the copies of clcsock callback functions

The callback functions of clcsock will be saved and replaced during the fallback. But if the fallback happens more than once, then the copies of these callback functions will be overwritten incorrectly, resulting in a loop call issue:

clcsk->skerrorreport |- smcfbackerrorreport() <------------------------------| |- smcfbackforwardwakeup() | (loop) |- clcsockcallback() (incorrectly overwritten) | |- smc->clcskerror_report() ------------------|

So this patch fixes the issue by saving these function pointers only once in the fallback and avoiding overwriting.(CVE-2022-48780)

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

net: marvell: prestera: Add missing ofnodeput() in presteraswitchsetbasemac_addr

This node pointer is returned by offindcompatiblenode() with refcount incremented. Calling ofnode_put() to aovid the refcount leak.(CVE-2022-48859)

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

of: Fix double free in ofparsephandlewithargs_map

In ofparsephandlewithargsmap() the inner loop that iterates through the map entries calls ofnode_put(new) to free the reference acquired by the previous iteration of the inner loop. This assumes that the value of "new" is NULL on the first iteration of the inner loop.

Make sure that this is true in all iterations of the outer loop by setting "new" to NULL after its value is assigned to "cur".

Extend the unittest to detect the double free and add an additional test case that actually triggers this path.(CVE-2023-52679)

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

netfilter: nftsetpipapo: do not free live element

Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo:

addelem("00000000") timeout 100 ms ... addelem("0000000X") timeout 100 ms delelem("0000000X") <---------------- delete one that was just added ... addelem("00005000") timeout 100 ms

1) nftpipaporemove() removes element 0000000X Then, KASAN shows a splat.

Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element.

Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map.

The _remove function does not work correctly if we have more than one element that share the same key.

This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation.

In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable.

The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer).

Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching.

Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element.

v2: avoid uneeded temporary variable (Stefano)(CVE-2024-26924)

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

netfilter: nftables: release mutex after nftgcseqend from abort path

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

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

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

net/sched: Fix mirred deadlock on device recursion

When the mirred action is used on a classful egress qdisc and a packet is mirrored or redirected to self we hit a qdisc lock deadlock. See trace below.

[..... other info removed for brevity....] [ 82.890906] [ 82.890906] ============================================ [ 82.890906] WARNING: possible recursive locking detected [ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W [ 82.890906] -------------------------------------------- [ 82.890906] ping/418 is trying to acquire lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: _devqueuexmit+0x1778/0x3550 [ 82.890906] [ 82.890906] but task is already holding lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: _devqueuexmit+0x1778/0x3550 [ 82.890906] [ 82.890906] other info that might help us debug this: [ 82.890906] Possible unsafe locking scenario: [ 82.890906] [ 82.890906] CPU0 [ 82.890906] ---- [ 82.890906] lock(&sch->q.lock); [ 82.890906] lock(&sch->q.lock); [ 82.890906] [ 82.890906] * DEADLOCK * [ 82.890906] [..... other info removed for brevity....]

Example setup (eth0->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0

Another example(eth0->eth1->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth1

tc qdisc add dev eth1 root handle 1: htb default 30 tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0

We fix this by adding an owner field (CPU id) to struct Qdisc set after root qdisc is entered. When the softirq enters it a second time, if the qdisc owner is the same CPU, the packet is dropped to break the loop.(CVE-2024-27010)

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

dma-mapping: benchmark: fix node id validation

While validating node ids in mapbenchmarkioctl(), nodepossible() may be provided with invalid argument outside of [0,MAXNUMNODES-1] range leading to:

BUG: KASAN: wild-memory-access in mapbenchmarkioctl (kernel/dma/mapbenchmark.c:214) Read of size 8 at addr 1fffffff8ccb6398 by task dmamapbenchma/971 CPU: 7 PID: 971 Comm: dmamapbenchma Not tainted 6.9.0-rc6 #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:117) kasanreport (mm/kasan/report.c:603) kasancheckrange (mm/kasan/generic.c:189) variabletestbit (arch/x86/include/asm/bitops.h:227) [inline] archtestbit (arch/x86/include/asm/bitops.h:239) [inline] _testbit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline] nodestate (include/linux/nodemask.h:423) [inline] mapbenchmarkioctl (kernel/dma/mapbenchmark.c:214) fullproxyunlockedioctl (fs/debugfs/file.c:333) _x64sysioctl (fs/ioctl.c:890) dosyscall64 (arch/x86/entry/common.c:83) entrySYSCALL64afterhwframe (arch/x86/entry/entry_64.S:130)

Compare node ids with sane bounds first. NUMANONODE is considered a special valid case meaning that benchmarking kthreads won't be bound to a cpuset of a given node.

Found by Linux Verification Center (linuxtesting.org).(CVE-2024-34777)

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

md/dm-raid: don't call mdreapsync_thread() directly

Currently mdreapsyncthread() is called from raidmessage() directly without holding 'reconfigmutex', this is definitely unsafe because mdreapsyncthread() can change many fields that is protected by 'reconfig_mutex'.

However, hold 'reconfigmutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozensync_thread() to fix deadlock").

Fix this problem by using stopsyncthread() to unregister sync_thread, like md/raid did.(CVE-2024-35808)

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

net: mvpp2: clear BM pool before initialization

Register value persist after booting the kernel using kexec which results in kernel panic. Thus clear the BM pool registers before initialisation to fix the issue.(CVE-2024-35837)

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

netfilter: nftables: flush pending destroy work before exitnet release

Similar to 2c9f0293280e ("netfilter: nftables: flush pending destroy work before netlink notifier") to address a race between exitnet and the destroy workqueue.

The trace below shows an element to be released via destroy workqueue while exit_net path (triggered via module removal) has already released the set that is used in such transaction.

[ 1360.547789] BUG: KASAN: slab-use-after-free in nftablestransdestroywork+0x3f5/0x590 [nftables] [ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465 [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359 [ 1360.547882] Workqueue: events nftablestransdestroywork [nftables] [ 1360.547984] Call Trace: [ 1360.547991] <TASK> [ 1360.547998] dumpstacklvl+0x53/0x70 [ 1360.548014] printreport+0xc4/0x610 [ 1360.548026] ? virtaddrvalid+0xba/0x160 [ 1360.548040] ? _pfxrawspinlockirqsave+0x10/0x10 [ 1360.548054] ? nftablestransdestroywork+0x3f5/0x590 [nftables] [ 1360.548176] kasanreport+0xae/0xe0 [ 1360.548189] ? nftablestransdestroywork+0x3f5/0x590 [nftables] [ 1360.548312] nftablestransdestroywork+0x3f5/0x590 [nftables] [ 1360.548447] ? _pfxnftablestransdestroywork+0x10/0x10 [nftables] [ 1360.548577] ? rawspinunlockirq+0x18/0x30 [ 1360.548591] processonework+0x2f1/0x670 [ 1360.548610] workerthread+0x4d3/0x760 [ 1360.548627] ? _pfxworkerthread+0x10/0x10 [ 1360.548640] kthread+0x16b/0x1b0 [ 1360.548653] ? _pfxkthread+0x10/0x10 [ 1360.548665] retfromfork+0x2f/0x50 [ 1360.548679] ? _pfxkthread+0x10/0x10 [ 1360.548690] retfromfork_asm+0x1a/0x30 [ 1360.548707] </TASK>

[ 1360.548719] Allocated by task 192061: [ 1360.548726] kasansavestack+0x20/0x40 [ 1360.548739] kasansavetrack+0x14/0x30 [ 1360.548750] kasankmalloc+0x8f/0xa0 [ 1360.548760] _kmallocnode+0x1f1/0x450 [ 1360.548771] nftablesnewset+0x10c7/0x1b50 [nftables] [ 1360.548883] nfnetlinkrcvbatch+0xbc4/0xdc0 [nfnetlink] [ 1360.548909] nfnetlinkrcv+0x1a8/0x1e0 [nfnetlink] [ 1360.548927] netlinkunicast+0x367/0x4f0 [ 1360.548935] netlinksendmsg+0x34b/0x610 [ 1360.548944] _syssendmsg+0x4d4/0x510 [ 1360.548953] _syssendmsg+0xc9/0x120 [ 1360.548961] _syssendmsg+0xbe/0x140 [ 1360.548971] dosyscall64+0x55/0x120 [ 1360.548982] entrySYSCALL64afterhwframe+0x55/0x5d

[ 1360.548994] Freed by task 192222: [ 1360.548999] kasansavestack+0x20/0x40 [ 1360.549009] kasansavetrack+0x14/0x30 [ 1360.549019] kasansavefreeinfo+0x3b/0x60 [ 1360.549028] poisonslabobject+0x100/0x180 [ 1360.549036] _kasanslabfree+0x14/0x30 [ 1360.549042] kfree+0xb6/0x260 [ 1360.549049] _nftreleasetable+0x473/0x6a0 [nftables] [ 1360.549131] nftablesexitnet+0x170/0x240 [nftables] [ 1360.549221] opsexitlist+0x50/0xa0 [ 1360.549229] freeexitlist+0x101/0x140 [ 1360.549236] unregisterpernetoperations+0x107/0x160 [ 1360.549245] unregisterpernetsubsys+0x1c/0x30 [ 1360.549254] nftablesmoduleexit+0x43/0x80 [nftables] [ 1360.549345] _dosysdeletemodule+0x253/0x370 [ 1360.549352] dosyscall64+0x55/0x120 [ 1360.549360] entrySYSCALL64afterhwframe+0x55/0x5d

(gdb) list *_nftreleasetable+0x473 0x1e033 is in _nftreleasetable (net/netfilter/nftablesapi.c:11354). 11349 listforeachentrysafe(flowtable, nf, &table->flowtables, list) { 11350 listdel(&flowtable->list); 11351 nftusedec(&table->use); 11352 nftablesflowtabledestroy(flowtable); 11353 } 11354 listforeachentrysafe(set, ns, &table->sets, list) { 11355 listdel(&set->list); 11356 nftusedec(&table->use); 11357 if (set->flags & (NFTSETMAP | NFTSETOBJECT)) 11358 nftmap_deactivat ---truncated---(CVE-2024-35899)

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

drm/amdgpu: Skip do PCI error slot reset during RAS recovery

Why: The PCI error slot reset maybe triggered after inject ue to UMC multi times, this caused system hang. [ 557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume [ 557.373718] [drm] PCIE GART of 512M enabled. [ 557.373722] [drm] PTB located at 0x0000031FED700000 [ 557.373788] [drm] VRAM is lost due to GPU reset! [ 557.373789] [drm] PSP is resuming... [ 557.547012] mlx5core 0000:55:00.0: mlx5pcierrdetected Device state = 1 pcistatus: 0. Exit, result = 3, need reset [ 557.547067] [drm] PCI error: detected callback, state(1)!! [ 557.547069] [drm] No support for XGMI hive yet... [ 557.548125] mlx5core 0000:55:00.0: mlx5pcislotreset Device state = 1 pcistatus: 0. Enter [ 557.607763] mlx5core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations [ 557.607777] mlx5core 0000:55:00.0: mlx5pcislotreset Device state = 1 pcistatus: 1. Exit, err = 0, result = 5, recovered [ 557.610492] [drm] PCI error: slot reset callback!! ... [ 560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded! [ 560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded! [ 560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI [ 560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G OE 5.15.0-91-generic #101-Ubuntu [ 560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023 [ 560.720959] Workqueue: amdgpu-reset-hive amdgpurasdorecovery [amdgpu] [ 560.728887] RIP: 0010:amdgpudevicegpurecover.cold+0xbf1/0xcf5 [amdgpu] [ 560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff <48> 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00 [ 560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202 [ 560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0 [ 560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010 [ 560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08 [ 560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000 [ 560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000 [ 560.803889] FS: 0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000 [ 560.812973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0 [ 560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 560.843444] PKRU: 55555554 [ 560.846480] Call Trace: [ 560.849225] <TASK> [ 560.851580] ? showtraceloglvl+0x1d6/0x2ea [ 560.856488] ? showtraceloglvl+0x1d6/0x2ea [ 560.861379] ? amdgpurasdorecovery+0x1b2/0x210 [amdgpu] [ 560.867778] ? showregs.part.0+0x23/0x29 [ 560.872293] ? _diebody.cold+0x8/0xd [ 560.876502] ? dieaddr+0x3e/0x60 [ 560.880238] ? excgeneralprotection+0x1c5/0x410 [ 560.885532] ? asmexcgeneralprotection+0x27/0x30 [ 560.891025] ? amdgpudevicegpurecover.cold+0xbf1/0xcf5 [amdgpu] [ 560.898323] amdgpurasdorecovery+0x1b2/0x210 [amdgpu] [ 560.904520] processonework+0x228/0x3d0 How: In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.(CVE-2024-35931)

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

fs/9p: fix uninitialized values during inode evict

If an iget fails due to not being able to retrieve information from the server then the inode structure is only partially initialized. When the inode gets evicted, references to uninitialized structures (like fscache cookies) were being made.

This patch checks for a bad_inode before doing anything other than clearing the inode from the cache. Since the inode is bad, it shouldn't have any state associated with it that needs to be written back (and there really isn't a way to complete those anyways).(CVE-2024-36923)

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

nilfs2: fix potential kernel bug due to lack of writeback flag waiting

Destructive writes to a block device on which nilfs2 is mounted can cause a kernel bug in the folio/page writeback start routine or writeback end routine (_foliostart_writeback in the log below):

kernel BUG at mm/page-writeback.c:3070! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI ... RIP: 0010:_foliostartwriteback+0xbaa/0x10e0 Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f> 0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00 ... Call Trace: <TASK> nilfssegctordoconstruct+0x4654/0x69d0 [nilfs2] nilfssegctorconstruct+0x181/0x6b0 [nilfs2] nilfssegctorthread+0x548/0x11c0 [nilfs2] kthread+0x2f0/0x390 retfromfork+0x4b/0x80 retfromfork_asm+0x1a/0x30 </TASK>

This is because when the log writer starts a writeback for segment summary blocks or a super root block that use the backing device's page cache, it does not wait for the ongoing folio/page writeback, resulting in an inconsistent writeback state.

Fix this issue by waiting for ongoing writebacks when putting folios/pages on the backing device into writeback state.(CVE-2024-37078)

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

drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference

In cdnsmhdpatomicenable(), the return value of drmmodeduplicate() is assigned to mhdpstate->currentmode, and there is a dereference of it in drmmodesetname(), which will lead to a NULL pointer dereference on failure of drmmodeduplicate().

Fix this bug add a check of mhdpstate->currentmode.(CVE-2024-38548)

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

wifi: carl9170: add a proper sanity check for endpoints

Syzkaller reports [1] hitting a warning which is caused by presence of a wrong endpoint type at the URB sumbitting stage. While there was a check for a specific 4th endpoint, since it can switch types between bulk and interrupt, other endpoints are trusted implicitly. Similar warning is triggered in a couple of other syzbot issues [2].

Fix the issue by doing a comprehensive check of all endpoints taking into account difference between high- and full-speed configuration.

[1] Syzkaller report: ... WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usbsubmiturb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> carl9170usbsendrxirqurb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504 carl9170usbinitdevice drivers/net/wireless/ath/carl9170/usb.c:939 [inline] carl9170usbfirmwarefinish drivers/net/wireless/ath/carl9170/usb.c:999 [inline] carl9170usbfirmwarestep2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028 requestfirmwareworkfunc+0x130/0x240 drivers/base/firmwareloader/main.c:1107 processonework+0x9bf/0x1710 kernel/workqueue.c:2289 workerthread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:308 </TASK>

[2] Related syzkaller crashes:(CVE-2024-38567)

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:

media: i2c: et8ek8: Don't strip remove function when driver is builtin

Using _exit for the remove function results in the remove callback being discarded with CONFIGVIDEO_ET8EK8=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally.

This also fixes a W=1 modpost warning:

WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text)(CVE-2024-38611)

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

media: stk1160: fix bounds checking in stk1160copyvideo()

The subtract in this condition is reversed. The ->length is the length of the buffer. The ->bytesused is how many bytes we have copied thus far. When the condition is reversed that means the result of the subtraction is always negative but since it's unsigned then the result is a very high positive value. That means the overflow check is never true.

Additionally, the ->bytesused doesn't actually work for this purpose because we're not writing to "buf->mem + buf->bytesused". Instead, the math to calculate the destination where we are writing is a bit involved. You calculate the number of full lines already written, multiply by two, skip a line if necessary so that we start on an odd numbered line, and add the offset into the line.

To fix this buffer overflow, just take the actual destination where we are writing, if the offset is already out of bounds print an error and return. Otherwise, write up to buf->length bytes.(CVE-2024-38621)

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:

md/raid5: fix deadlock that raid5d() wait for itself to clear MDSBCHANGE_PENDING

Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MDSBCHANGE_PENDING in raid5d"")

However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d().

Current implementation in raid5d() has a weird dependence:

1) mdcheckrecovery() from raid5d() must hold 'reconfigmutex' to clear MDSBCHANGEPENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MDSBCHANGE_PENDING to be cleared;

This behaviour is introduce before v2.6, and for consequence, if other context hold 'reconfigmutex', and mdcheckrecovery() can't update superblock, then raid5d() will waste one cpu 100% by the deadloop, until 'reconfig_mutex' is released.

Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MDSBCHANGEPENDING is still set after mdcheckrecovery(), daemon thread will be woken up when 'reconfigmutex' is released. Meanwhile, the hang problem will be fixed as well.(CVE-2024-39476)

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

mmc: davinci: Don't strip remove function when driver is builtin

Using _exit for the remove function results in the remove callback being discarded with CONFIGMMC_DAVINCI=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally.

This also fixes a W=1 modpost warning:

WARNING: modpost: drivers/mmc/host/davincimmc: section mismatch in reference: davincimmcsddriver+0x10 (section: .data) -> davincimmcsd_remove (section: .exit.text)(CVE-2024-39484)

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

liquidio: Adjust a NULL pointer handling path in liovfrepcopypacket

In liovfrepcopypacket() pginfo->page is compared to a NULL value, but then it is unconditionally passed to skbaddrxfrag() which looks strange and could lead to null pointer dereference.

liovfrepcopypacket() call trace looks like: octeondroqprocesspackets octeondroqfastprocesspackets octeondroqdispatchpkt octeoncreaterecvinfo ...search in the dispatchlist... ->dispfn(rdisp->rinfo, ...) liovfreppktrecv(struct octeonrecvinfo *recvinfo, ...) In this path there is no code which sets pginfo->page to NULL. So this check looks unneeded and doesn't solve potential problem. But I guess the author had reason to add a check and I have no such card and can't do real test. In addition, the code in the function liquidiopushpacket() in liquidio/liocore.c does exactly the same.

Based on this, I consider the most acceptable compromise solution to adjust this issue by moving skbaddrx_frag() into conditional scope.

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

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

iouring/io-wq: Use setbit() and test_bit() at worker->flags

Utilize setbit() and testbit() on worker->flags within io_uring/io-wq to address potential data races.

The structure ioworker->flags may be accessed through various data paths, leading to concurrency issues. When KCSAN is enabled, it reveals data races occurring in ioworkerhandlework and iowqactivatefreeworker functions.

 BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker
 write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28:
 io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569)
 io_wq_worker (io_uring/io-wq.c:?)

<snip>

 read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5:
 io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285)
 io_wq_enqueue (io_uring/io-wq.c:947)
 io_queue_iowq (io_uring/io_uring.c:524)
 io_req_task_submit (io_uring/io_uring.c:1511)
 io_handle_tw_list (io_uring/io_uring.c:1198)

<snip>

Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm").

These races involve writes and reads to the same memory location by different tasks running on different CPUs. To mitigate this, refactor the code to use atomic operations such as setbit(), testbit(), and clear_bit() instead of basic "and" and "or" operations. This ensures thread-safe manipulation of worker flags.

Also, move create_index to avoid holes in the structure.(CVE-2024-39508)

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

riscv: rewrite _kernelmap_pages() to fix sleeping in invalid context

_kernelmap_pages() is a debug function which clears the valid bit in page table entry for deallocated pages to detect illegal memory accesses to freed pages.

This function set/clear the valid bit using _setmemory(). _setmemory() acquires initmm's semaphore, and this operation may sleep. This is problematic, because _kernelmappages() can be called in atomic context, and thus is illegal to sleep. An example warning that this causes:

BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 2, name: kthreadd preemptcount: 2, expected: 0 CPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37 Hardware name: riscv-virtio,qemu (DT) Call Trace: [<ffffffff800060dc>] dumpbacktrace+0x1c/0x24 [<ffffffff8091ef6e>] showstack+0x2c/0x38 [<ffffffff8092baf8>] dumpstacklvl+0x5a/0x72 [<ffffffff8092bb24>] dumpstack+0x14/0x1c [<ffffffff8003b7ac>] _mightresched+0x104/0x10e [<ffffffff8003b7f4>] _mightsleep+0x3e/0x62 [<ffffffff8093276a>] downwrite+0x20/0x72 [<ffffffff8000cf00>] _setmemory+0x82/0x2fa [<ffffffff8000d324>] _kernelmappages+0x5a/0xd4 [<ffffffff80196cca>] _allocpagesbulk+0x3b2/0x43a [<ffffffff8018ee82>] _vmallocnoderange+0x196/0x6ba [<ffffffff80011904>] copyprocess+0x72c/0x17ec [<ffffffff80012ab4>] kernelclone+0x60/0x2fe [<ffffffff80012f62>] kernelthread+0x82/0xa0 [<ffffffff8003552c>] kthreadd+0x14a/0x1be [<ffffffff809357de>] retfromfork+0xe/0x1c

Rewrite this function with applytoexistingpagerange(). It is fine to not have any locking, because _kernelmap_pages() works with pages being allocated/deallocated and those pages are not changed by anyone else in the meantime.(CVE-2024-40915)

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

iommu: Return right value in iommusvabind_device()

iommusvabinddevice() should return either a sva bond handle or an ERRPTR value in error cases. Existing drivers (idxd and uacce) only check the return value with IS_ERR(). This could potentially lead to a kernel NULL pointer dereference issue if the function returns NULL instead of an error pointer.

In reality, this doesn't cause any problems because iommusvabinddevice() only returns NULL when the kernel is not configured with CONFIGIOMMUSVA. In this case, iommudevenablefeature(dev, IOMMUDEVFEATSVA) will return an error, and the device drivers won't call iommusvabinddevice() at all.(CVE-2024-40945)

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

ima: Avoid blocking in RCU read-side critical section

A panic happens in imamatchpolicy:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 PGD 42f873067 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 5 PID: 1286325 Comm: kubeletmonit.sh Kdump: loaded Tainted: P Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:imamatchpolicy+0x84/0x450 Code: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39 7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d f2 b9 f4 00 0f 84 9c 01 00 00 <44> 85 73 10 74 ea 44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f RSP: 0018:ff71570009e07a80 EFLAGS: 00010207 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200 RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739 R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970 R13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001 FS: 00007f5195b51740(0000) GS:ff3e278b12d40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: imagetaction+0x22/0x30 processmeasurement+0xb0/0x830 ? pageaddfilermap+0x15/0x170 ? allocsetpte+0x269/0x4c0 ? prepnewpage+0x81/0x140 ? simplexattrget+0x75/0xa0 ? selinuxfileopen+0x9d/0xf0 imafilecheck+0x64/0x90 pathopenat+0x571/0x1720 dofilpopen+0x9b/0x110 ? pagecountertrycharge+0x57/0xc0 ? filescgroupallocfd+0x38/0x60 ? _allocfd+0xd4/0x250 ? dosysopen+0x1bd/0x250 dosysopen+0x1bd/0x250 dosyscall64+0x5d/0x1d0 entrySYSCALL64after_hwframe+0x65/0xca

Commit c7423dbdbc9e ("ima: Handle -ESTALE returned by imafilterrulematch()") introduced call to imalsmcopyrule within a RCU read-side critical section which contains kmalloc with GFP_KERNEL. This implies a possible sleep and violates limitations of RCU read-side critical sections on non-PREEMPT systems.

Sleeping within RCU read-side critical section might cause synchronize_rcu() returning early and break RCU protection, allowing a UAF to happen.

The root cause of this issue could be described as follows: | Thread A | Thread B | | |imamatchpolicy | | | rcureadlock | |imalsmupdaterule | | | synchronizercu | | | | kmalloc(GFPKERNEL)| | | sleep | ==> synchronizercu returns early | kfree(entry) | | | | entry = entry->next| ==> UAF happens and entry now becomes NULL (or could be anything). | | entry->action | ==> Accessing entry might cause panic.

To fix this issue, we are converting all kmalloc that is called within RCU read-side critical section to use GFP_ATOMIC.

PM: fixed missing comment, long lines, !CONFIGIMALSM_RULES case

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

dmaengine: idxd: Fix possible Use-After-Free in irqprocesswork_list

Use listforeachentrysafe() to allow iterating through the list and deleting the entry in the iteration process. The descriptor is freed via idxddesccomplete() and there's a slight chance may cause issue for the list iterator when the descriptor is reused by another thread without it being deleted from the list.(CVE-2024-40956)

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

ipv6: prevent possible NULL dereference in rt6_probe()

syzbot caught a NULL dereference in rt6_probe() [1]

Bail out if _in6dev_get() returns NULL.

[1] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f] CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:rt6probe net/ipv6/route.c:656 [inline] RIP: 0010:findmatch+0x8c4/0xf50 net/ipv6/route.c:758 Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19 RSP: 0018:ffffc900034af070 EFLAGS: 00010203 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000 RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c RBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000 FS: 00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> rt6nhfindmatch+0xfa/0x1a0 net/ipv6/route.c:784 nexthopforeachfib6nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496 _findrrleaf+0x6e7/0xe00 net/ipv6/route.c:825 findrrleaf net/ipv6/route.c:853 [inline] rt6select net/ipv6/route.c:897 [inline] fib6tablelookup+0x57e/0xa30 net/ipv6/route.c:2195 ip6polroute+0x1cd/0x1150 net/ipv6/route.c:2231 pollookupfunc include/net/ip6fib.h:616 [inline] fib6rulelookup+0x386/0x720 net/ipv6/fib6rules.c:121 ip6routeoutputflagsnoref net/ipv6/route.c:2639 [inline] ip6routeoutputflags+0x1d0/0x640 net/ipv6/route.c:2651 ip6dstlookuptail.constprop.0+0x961/0x1760 net/ipv6/ip6output.c:1147 ip6dstlookupflow+0x99/0x1d0 net/ipv6/ip6output.c:1250 rawv6sendmsg+0xdab/0x4340 net/ipv6/raw.c:898 inetsendmsg+0x119/0x140 net/ipv4/afinet.c:853 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg net/socket.c:745 [inline] sockwriteiter+0x4b8/0x5c0 net/socket.c:1160 newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0x6b6/0x1140 fs/readwrite.c:590 ksyswrite+0x1f8/0x260 fs/readwrite.c:643 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f(CVE-2024-40960)

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:

ext4: do not create EA inode under buffer lock

ext4xattrsetentry() creates new EA inodes while holding buffer lock on the external xattr block. This is problematic as it nests all the allocation locking (which acquires locks on other buffers) under the buffer lock. This can even deadlock when the filesystem is corrupted and e.g. quota file is setup to contain xattr block as data block. Move the allocation of EA inode out of ext4xattrsetentry() into the callers.(CVE-2024-40972)

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

dropmonitor: replace spinlock by rawspinlock

tracedropcommon() is called with preemption disabled, and it acquires a spinlock. This is problematic for RT kernels because spinlocks are sleeping locks in this configuration, which causes the following splat:

BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 449, name: rcuc/47 preemptcount: 1, expected: 0 RCU nest depth: 2, expected: 2 5 locks held by rcuc/47/449: #0: ff1100086ec30a60 ((softirqctrl.lock)){+.+.}-{2:2}, at: _localbhdisableip+0x105/0x210 #1: ffffffffb394a280 (rcureadlock){....}-{1:2}, at: rtspinlock+0xbf/0x130 #2: ffffffffb394a280 (rcureadlock){....}-{1:2}, at: _localbhdisableip+0x11c/0x210 #3: ffffffffb394a160 (rcucallback){....}-{0:0}, at: rcudobatch+0x360/0xc70 #4: ff1100086ee07520 (&data->lock){+.+.}-{2:2}, at: tracedropcommon.constprop.0+0xb5/0x290 irq event stamp: 139909 hardirqs last enabled at (139908): [<ffffffffb1df2b33>] _rawspinunlockirqrestore+0x63/0x80 hardirqs last disabled at (139909): [<ffffffffb19bd03d>] tracedropcommon.constprop.0+0x26d/0x290 softirqs last enabled at (139892): [<ffffffffb07a1083>] _localbhenableip+0x103/0x170 softirqs last disabled at (139898): [<ffffffffb0909b33>] rcucpukthread+0x93/0x1f0 Preemption disabled at: [<ffffffffb1de786b>] rtmutexslowunlock+0xab/0x2e0 CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7 Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022 Call Trace: <TASK> dumpstacklvl+0x8c/0xd0 dumpstack+0x14/0x20 _mightresched+0x21e/0x2f0 rtspinlock+0x5e/0x130 ? tracedropcommon.constprop.0+0xb5/0x290 ? skbqueuepurgereason.part.0+0x1bf/0x230 tracedropcommon.constprop.0+0xb5/0x290 ? preemptcountsub+0x1c/0xd0 ? rawspinunlockirqrestore+0x4a/0x80 ? _pfxtracedropcommon.constprop.0+0x10/0x10 ? rtmutexslowunlock+0x26a/0x2e0 ? skbqueuepurgereason.part.0+0x1bf/0x230 ? _pfxrtmutexslowunlock+0x10/0x10 ? skbqueuepurgereason.part.0+0x1bf/0x230 tracekfreeskbhit+0x15/0x20 tracekfreeskb+0xe9/0x150 kfreeskbreason+0x7b/0x110 skbqueuepurgereason.part.0+0x1bf/0x230 ? _pfxskbqueuepurgereason.part.0+0x10/0x10 ? marklock.part.0+0x8a/0x520 ...

tracedropcommon() also disables interrupts, but this is a minor issue because we could easily replace it with a local_lock.

Replace the spinlock with rawspin_lock to avoid sleeping in atomic context.(CVE-2024-40980)

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:

net/sched: actapi: fix possible infinite loop in tcfidrcheckalloc()

syzbot found hanging tasks waiting on rtnl_lock [1]

A reproducer is available in the syzbot bug.

When a request to add multiple actions with the same index is sent, the second request will block forever on the first request. This holds rtnl_lock, and causes tasks to hang.

Return -EAGAIN to prevent infinite looping, while keeping documented behavior.

[1]

INFO: task kworker/1:0:5088 blocked for more than 143 seconds. Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000 Workqueue: eventspowerefficient regcheckchanswork Call Trace: <TASK> contextswitch kernel/sched/core.c:5409 [inline] _schedule+0xf15/0x5d00 kernel/sched/core.c:6746 _scheduleloop kernel/sched/core.c:6823 [inline] schedule+0xe7/0x350 kernel/sched/core.c:6838 schedulepreemptdisabled+0x13/0x30 kernel/sched/core.c:6895 _mutexlockcommon kernel/locking/mutex.c:684 [inline] _mutexlock+0x5b8/0x9c0 kernel/locking/mutex.c:752 wiphylock include/net/cfg80211.h:5953 [inline] regleaveinvalidchans net/wireless/reg.c:2466 [inline] regcheckchanswork+0x10a/0x10e0 net/wireless/reg.c:2481(CVE-2024-40995)

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

drm/amdkfd: don't allow mapping the MMIO HDP page with large pages

We don't get the right offset in that case. The GPU has an unused 4K area of the register BAR space into which you can remap registers. We remap the HDP flush registers into this space to allow userspace (CPU or GPU) to flush the HDP when it updates VRAM. However, on systems with >4K pages, we end up exposing PAGE_SIZE of MMIO space.(CVE-2024-41011)