OESA-2025-1159

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net: wwan: t7xx: Fix FSM command timeout issue

When driver processes the internal state change command, it use an asynchronous thread to process the command operation. If the main thread detects that the task has timed out, the asynchronous thread will panic when executing the completion notification because the main thread completion object has been released.

BUG: unable to handle page fault for address: fffffffffffffff8 PGD 1f283a067 P4D 1f283a067 PUD 1f283c067 PMD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:completeall+0x3e/0xa0 [...] Call Trace: <TASK> ? _diebody+0x68/0xb0 ? pagefaultoops+0x379/0x3e0 ? excpagefault+0x69/0xa0 ? asmexcpagefault+0x22/0x30 ? completeall+0x3e/0xa0 fsmmainthread+0xa3/0x9c0 [mtkt7xx (HASH:1400 5)] ? _pfxautoremovewakefunction+0x10/0x10 kthread+0xd8/0x110 ? _pfxfsmmainthread+0x10/0x10 [mtkt7xx (HASH:1400 5)] ? _pfxkthread+0x10/0x10 retfromfork+0x38/0x50 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1b/0x30 </TASK> [...] CR2: fffffffffffffff8 ---[ end trace 0000000000000000 ]---

Use the reference counter to ensure safe release as Sergey suggests: https://lore.kernel.org/all/da90f64c-260a-4329-87bf-1f9ff20a5951@gmail.com/(CVE-2024-39282)

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

i3c: mipi-i3c-hci: Mask ring interrupts before ring stop request

Bus cleanup path in DMA mode may trigger a RINGOPSTAT interrupt when the ring is being stopped. Depending on timing between ring stop request completion, interrupt handler removal and code execution this may lead to a NULL pointer dereference in hcidmairqhandler() if it gets to run after the iodata pointer is set to NULL in hcidmacleanup().

Prevent this my masking the ring interrupts before ring stop request.(CVE-2024-45828)

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

ethtool: fail closed if we can't get max channel used in indirection tables

Commit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count with active RSS contexts") proves that allowing indirection table to contain channels with out of bounds IDs may lead to crashes. Currently the max channel check in the core gets skipped if driver can't fetch the indirection table or when we can't allocate memory.

Both of those conditions should be extremely rare but if they do happen we should try to be safe and fail the channel change.(CVE-2024-46834)

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

wifi: mt76: mt7921: fix NULL pointer access in mt7921ipv6addr_change

When disabling wifi mt7921ipv6addr_change() is called as a notifier. At this point mvif->phy is already NULL so we cannot use it here.(CVE-2024-46860)

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

usbnet: ipheth: do not stop RX on failing RX callback

RX callbacks can fail for multiple reasons:

• Payload too short
• Payload formatted incorrecly (e.g. bad NCM framing)
• Lack of memory

None of these should cause the driver to seize up.

Make such failures non-critical and continue processing further incoming URBs.(CVE-2024-46861)

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

nvme-rdma: unquiesce admin_q before destroy it

Kernel will hang on destroy admin_q while we create ctrl failed, such as following calltrace:

PID: 23644 TASK: ff2d52b40f439fc0 CPU: 2 COMMAND: "nvme" #0 [ff61d23de260fb78] _schedule at ffffffff8323bc15 #1 [ff61d23de260fc08] schedule at ffffffff8323c014 #2 [ff61d23de260fc28] blkmqfreezequeuewait at ffffffff82a3dba1 #3 [ff61d23de260fc78] blkfreezequeue at ffffffff82a4113a #4 [ff61d23de260fc90] blkcleanupqueue at ffffffff82a33006 #5 [ff61d23de260fcb0] nvmerdmadestroyadminqueue at ffffffffc12686ce #6 [ff61d23de260fcc8] nvmerdmasetupctrl at ffffffffc1268ced #7 [ff61d23de260fd28] nvmerdmacreatectrl at ffffffffc126919b #8 [ff61d23de260fd68] nvmfdevwrite at ffffffffc024f362 #9 [ff61d23de260fe38] vfswrite at ffffffff827d5f25 RIP: 00007fda7891d574 RSP: 00007ffe2ef06958 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 000055e8122a4d90 RCX: 00007fda7891d574 RDX: 000000000000012b RSI: 000055e8122a4d90 RDI: 0000000000000004 RBP: 00007ffe2ef079c0 R8: 000000000000012b R9: 000055e8122a4d90 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000004 R13: 000055e8122923c0 R14: 000000000000012b R15: 00007fda78a54500 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b

This due to we have quiesced admiq before cancel requests, but forgot to unquiesce before destroy it, as a result we fail to drain the pending requests, and hang on blkmqfreezequeuewait() forever. Here try to reuse nvmerdmateardownadmin_queue() to fix this issue and simplify the code.(CVE-2024-49569)

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

net/mlx5e: Don't call cleanup on profile rollback failure

When profile rollback fails in mlx5enetdevchange_profile, the netdev profile var is left set to NULL. Avoid a crash when unloading the driver by not calling profile->cleanup in such a case.

This was encountered while testing, with the original trigger that the wq rescuer thread creation got interrupted (presumably due to Ctrl+C-ing modprobe), which gets converted to ENOMEM (-12) by mlx5eprivinit, the profile rollback also fails for the same reason (signal still active) so the profile is left as NULL, leading to a crash later in mlx5eremove.

[ 732.473932] mlx5core 0000:08:00.1: E-Switch: Unload vfs: mode(OFFLOADS), nvfs(2), necvfs(0), active vports(2) [ 734.525513] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR [ 734.557372] mlx5core 0000:08:00.1: mlx5enetdevinitprofile:6235:(pid 6086): mlx5eprivinit failed, err=-12 [ 734.559187] mlx5core 0000:08:00.1 eth3: mlx5enetdevchangeprofile: new profile init failed, -12 [ 734.560153] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR [ 734.589378] mlx5core 0000:08:00.1: mlx5enetdevinitprofile:6235:(pid 6086): mlx5eprivinit failed, err=-12 [ 734.591136] mlx5core 0000:08:00.1 eth3: mlx5enetdevchangeprofile: failed to rollback to orig profile, -12 [ 745.537492] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 745.538222] #PF: supervisor read access in kernel mode <snipped> [ 745.551290] Call Trace: [ 745.551590] <TASK> [ 745.551866] ? _die+0x20/0x60 [ 745.552218] ? pagefaultoops+0x150/0x400 [ 745.555307] ? excpagefault+0x79/0x240 [ 745.555729] ? asmexcpagefault+0x22/0x30 [ 745.556166] ? mlx5eremove+0x6b/0xb0 [mlx5core] [ 745.556698] auxiliarybusremove+0x18/0x30 [ 745.557134] devicereleasedriverinternal+0x1df/0x240 [ 745.557654] busremovedevice+0xd7/0x140 [ 745.558075] devicedel+0x15b/0x3c0 [ 745.558456] mlx5rescandriverslocked.part.0+0xb1/0x2f0 [mlx5core] [ 745.559112] mlx5unregisterdevice+0x34/0x50 [mlx5core] [ 745.559686] mlx5uninitone+0x46/0xf0 [mlx5core] [ 745.560203] removeone+0x4e/0xd0 [mlx5core] [ 745.560694] pcideviceremove+0x39/0xa0 [ 745.561112] devicereleasedriverinternal+0x1df/0x240 [ 745.561631] driverdetach+0x47/0x90 [ 745.562022] busremovedriver+0x84/0x100 [ 745.562444] pciunregisterdriver+0x3b/0x90 [ 745.562890] mlx5cleanup+0xc/0x1b [mlx5core] [ 745.563415] _x64sysdeletemodule+0x14d/0x2f0 [ 745.563886] ? kmemcachefree+0x1b0/0x460 [ 745.564313] ? lockdephardirqsonprepare+0xe2/0x190 [ 745.564825] dosyscall64+0x6d/0x140 [ 745.565223] entrySYSCALL64afterhwframe+0x4b/0x53 [ 745.565725] RIP: 0033:0x7f1579b1288b(CVE-2024-50146)

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

KVM: arm64: Get rid of userspaceirqchipin_use

Improper use of userspaceirqchipinuse led to syzbot hitting the following WARNON() in kvmtimerupdate_irq():

WARNING: CPU: 0 PID: 3281 at arch/arm64/kvm/archtimer.c:459 kvmtimerupdateirq+0x21c/0x394 Call trace: kvmtimerupdateirq+0x21c/0x394 arch/arm64/kvm/archtimer.c:459 kvmtimervcpureset+0x158/0x684 arch/arm64/kvm/archtimer.c:968 kvmresetvcpu+0x3b4/0x560 arch/arm64/kvm/reset.c:264 kvmvcpusettarget arch/arm64/kvm/arm.c:1553 [inline] kvmarchvcpuioctlvcpuinit arch/arm64/kvm/arm.c:1573 [inline] kvmarchvcpuioctl+0x112c/0x1b3c arch/arm64/kvm/arm.c:1695 kvmvcpuioctl+0x4ec/0xf74 virt/kvm/kvmmain.c:4658 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:907 [inline] _sesysioctl fs/ioctl.c:893 [inline] _arm64sysioctl+0x108/0x184 fs/ioctl.c:893 _invokesyscall arch/arm64/kernel/syscall.c:35 [inline] invokesyscall+0x78/0x1b8 arch/arm64/kernel/syscall.c:49 el0svccommon+0xe8/0x1b0 arch/arm64/kernel/syscall.c:132 doel0svc+0x40/0x50 arch/arm64/kernel/syscall.c:151 el0svc+0x54/0x14c arch/arm64/kernel/entry-common.c:712 el0t64synchandler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598

The following sequence led to the scenario: - Userspace creates a VM and a vCPU. - The vCPU is initialized with KVMARMVCPUPMUV3 during KVMARMVCPUINIT. - Without any other setup, such as vGIC or vPMU, userspace issues KVMRUN on the vCPU. Since the vPMU is requested, but not setup, kvmarmpmuv3enable() fails in kvmarchvcpurunpidchange(). As a result, KVMRUN returns after enabling the timer, but before incrementing 'userspaceirqchipinuse': kvmarchvcpurunpidchange() ret = kvmarmpmuv3enable() if (!vcpu->arch.pmu.created) return -EINVAL; if (ret) return ret; [...] if (!irqchipinkernel(kvm)) staticbranchinc(&userspaceirqchipinuse); - Userspace ignores the error and issues KVMARMVCPUINIT again. Since the timer is already enabled, control moves through the following flow, ultimately hitting the WARNON(): kvmtimervcpureset() if (timer->enabled) kvmtimerupdateirq() if (!userspaceirqchip()) ret = kvmvgicinjectirq() ret = vgiclazyinit() if (unlikely(!vgicinitialized(kvm))) if (kvm->arch.vgic.vgicmodel != KVMDEVTYPEARMVGICV2) return -EBUSY; WARN_ON(ret);

Theoretically, since userspaceirqchipinuse's functionality can be simply replaced by '!irqchipin_kernel()', get rid of the static key to avoid the mismanagement, which also helps with the syzbot issue.(CVE-2024-53195)

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

netfilter: IDLETIMER: Fix for possible ABBA deadlock

Deletion of the last rule referencing a given idletimer may happen at the same time as a read of its file in sysfs:

| ====================================================== | WARNING: possible circular locking dependency detected | 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted | ------------------------------------------------------ | iptables/3303 is trying to acquire lock: | ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: _kernfsremove+0x20 | | but task is already holding lock: | ffffffffa0249068 (listmutex){+.+.}-{3:3}, at: idletimertgdestroyv] | | which lock already depends on the new lock.

A simple reproducer is:

| #!/bin/bash | | while true; do | iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme" | iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme" | done & | while true; do | cat /sys/class/xt_idletimer/timers/testme >/dev/null | done

Avoid this by freeing list_mutex right after deleting the element from the list, then continuing with the teardown.(CVE-2024-54683)

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

mm/vmalloc: combine all TLB flush operations of KASAN shadow virtual address into one operation

When compiling kernel source 'make -j $(nproc)' with the up-and-running KASAN-enabled kernel on a 256-core machine, the following soft lockup is shown:

watchdog: BUG: soft lockup - CPU#28 stuck for 22s! [kworker/28:1:1760] CPU: 28 PID: 1760 Comm: kworker/28:1 Kdump: loaded Not tainted 6.10.0-rc5 #95 Workqueue: events drainvmapareawork RIP: 0010:smpcallfunctionmanycond+0x1d8/0xbb0 Code: 38 c8 7c 08 84 c9 0f 85 49 08 00 00 8b 45 08 a8 01 74 2e 48 89 f1 49 89 f7 48 c1 e9 03 41 83 e7 07 4c 01 e9 41 83 c7 03 f3 90 <0f> b6 01 41 38 c7 7c 08 84 c0 0f 85 d4 06 00 00 8b 45 08 a8 01 75 RSP: 0018:ffffc9000cb3fb60 EFLAGS: 00000202 RAX: 0000000000000011 RBX: ffff8883bc4469c0 RCX: ffffed10776e9949 RDX: 0000000000000002 RSI: ffff8883bb74ca48 RDI: ffffffff8434dc50 RBP: ffff8883bb74ca40 R08: ffff888103585dc0 R09: ffff8884533a1800 R10: 0000000000000004 R11: ffffffffffffffff R12: ffffed1077888d39 R13: dffffc0000000000 R14: ffffed1077888d38 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff8883bc400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005577b5c8d158 CR3: 0000000004850000 CR4: 0000000000350ef0 Call Trace: <IRQ> ? watchdogtimerfn+0x2cd/0x390 ? pfxwatchdogtimerfn+0x10/0x10 ? _hrtimerrunqueues+0x300/0x6d0 ? schedclockcpu+0x69/0x4e0 ? _pfxhrtimerrunqueues+0x10/0x10 ? srsoreturnthunk+0x5/0x5f ? ktimegetupdateoffsetsnow+0x7f/0x2a0 ? srsoreturnthunk+0x5/0x5f ? srsoreturnthunk+0x5/0x5f ? hrtimerinterrupt+0x2ca/0x760 ? _sysvecapictimerinterrupt+0x8c/0x2b0 ? sysvecapictimerinterrupt+0x6a/0x90 </IRQ> <TASK> ? asmsysvecapictimerinterrupt+0x16/0x20 ? smpcallfunctionmanycond+0x1d8/0xbb0 ? _pfxdokernelrangeflush+0x10/0x10 oneachcpucondmask+0x20/0x40 flushtlbkernelrange+0x19b/0x250 ? srsoreturnthunk+0x5/0x5f ? kasanreleasevmalloc+0xa7/0xc0 purgevmapnode+0x357/0x820 ? _pfxpurgevmapnode+0x10/0x10 _purgevmaparealazy+0x5b8/0xa10 drainvmapareawork+0x21/0x30 processonework+0x661/0x10b0 workerthread+0x844/0x10e0 ? srsoreturnthunk+0x5/0x5f ? _kthreadparkme+0x82/0x140 ? _pfxworkerthread+0x10/0x10 kthread+0x2a5/0x370 ? _pfxkthread+0x10/0x10 retfromfork+0x30/0x70 ? _pfxkthread+0x10/0x10 retfromfork_asm+0x1a/0x30 </TASK>

Debugging Analysis:

1. The following ftrace log shows that the lockup CPU spends too much time iterating vmapnodes and flushing TLB when purging vmarea structures. (Some info is trimmed).

   kworker: funcgraphentry: | drainvmapareawork() { kworker: funcgraphentry: | mutexlock() { kworker: funcgraphentry: 1.092 us | _condresched(); kworker: funcgraphexit: 3.306 us | } ... ... kworker: funcgraphentry: | flushtlbkernelrange() { ... ... kworker: funcgraphexit: # 7533.649 us | } ... ... kworker: funcgraphentry: 2.344 us | mutexunlock(); kworker: funcgraphexit: $ 23871554 us | }

   The drainvmaparea_work() spends over 23 seconds.

   There are 2805 flushtlbkernel_range() calls in the ftrace log.

   • One is called in _purgevmaparealazy().
   • Others are called by purgevmapnode->kasanreleasevmalloc. purgevmapnode() iteratively releases kasan vmalloc allocations and flushes TLB for each vmaparea.
     • [Rough calculation] Each flushtlbkernelrange() runs about 7.5ms. -- 2804 * 7.5ms = 21.03 seconds. -- That's why a soft lock is triggered.

2. Extending the soft lockup time can work around the issue (For example, # echo ---truncated---(CVE-2024-56559)

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

gpio: grgpio: Add NULL check in grgpio_probe

devmkasprintf() can return a NULL pointer on failure,but this returned value in grgpioprobe is not checked. Add NULL check in grgpio_probe, to handle kernel NULL pointer dereference error.(CVE-2024-56634)

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

net: Fix icmp host relookup triggering iprtbug

arp link failure may trigger iprtbug while xfrm enabled, call trace is:

WARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 iprtbug+0x14/0x20 Modules linked in: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iprtbug+0x14/0x20 Call Trace: <IRQ> ipsendskb+0x14/0x40 _icmpsend+0x42d/0x6a0 ipv4linkfailure+0xe2/0x1d0 arperrorreport+0x3c/0x50 neighinvalidate+0x8d/0x100 neightimerhandler+0x2e1/0x330 calltimerfn+0x21/0x120 _runtimerbase.part.0+0x1c9/0x270 runtimersoftirq+0x4c/0x80 handlesoftirqs+0xac/0x280 irqexitrcu+0x62/0x80 sysvecapictimerinterrupt+0x77/0x90

The script below reproduces this scenario: ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \ dir out priority 0 ptype main flag localok icmp ip l a veth1 type veth ip a a 192.168.141.111/24 dev veth0 ip l s veth0 up ping 192.168.141.155 -c 1

icmproutelookup() create input routes for locally generated packets while xfrm relookup ICMP traffic.Then it will set input route (dst->out = iprtbug) to skb for DESTUNREACH.

For ICMP err triggered by locally generated packets, dst->dev of output route is loopback. Generally, xfrm relookup verification is not required on loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1).

Skip icmp relookup for locally generated packets to fix it.(CVE-2024-56647)

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

ipv6: Fix soft lockups in fib6selectpath under high next hop churn

Soft lockups have been observed on a cluster of Linux-based edge routers located in a highly dynamic environment. Using the bird service, these routers continuously update BGP-advertised routes due to frequently changing nexthop destinations, while also managing significant IPv6 traffic. The lockups occur during the traversal of the multipath circular linked-list in the fib6_select_path function, particularly while iterating through the siblings in the list. The issue typically arises when the nodes of the linked list are unexpectedly deleted concurrently on a different core—indicated by their 'next' and 'previous' elements pointing back to the node itself and their reference count dropping to zero. This results in an infinite loop, leading to a soft lockup that triggers a system panic via the watchdog timer.

Apply RCU primitives in the problematic code sections to resolve the issue. Where necessary, update the references to fib6_siblings to annotate or use the RCU APIs.

Include a test script that reproduces the issue. The script periodically updates the routing table while generating a heavy load of outgoing IPv6 traffic through multiple iperf3 clients. It consistently induces infinite soft lockups within a couple of minutes.

Kernel log:

0 [ffffbd13003e8d30] machinekexec at ffffffff8ceaf3eb 1 [ffffbd13003e8d90] _crashkexec at ffffffff8d0120e3 2 [ffffbd13003e8e58] panic at ffffffff8cef65d4 3 [ffffbd13003e8ed8] watchdogtimerfn at ffffffff8d05cb03 4 [ffffbd13003e8f08] _hrtimerrunqueues at ffffffff8cfec62f 5 [ffffbd13003e8f70] hrtimerinterrupt at ffffffff8cfed756 6 [ffffbd13003e8fd0] _sysvecapictimerinterrupt at ffffffff8cea01af 7 [ffffbd13003e8ff0] sysvecapictimerinterrupt at ffffffff8df1b83d -- <IRQ stack> -- 8 [ffffbd13003d3708] asmsysvecapictimerinterrupt at ffffffff8e000ecb [exception RIP: fib6selectpath+299] RIP: ffffffff8ddafe7b RSP: ffffbd13003d37b8 RFLAGS: 00000287 RAX: ffff975850b43600 RBX: ffff975850b40200 RCX: 0000000000000000 RDX: 000000003fffffff RSI: 0000000051d383e4 RDI: ffff975850b43618 RBP: ffffbd13003d3800 R8: 0000000000000000 R9: ffff975850b40200 R10: 0000000000000000 R11: 0000000000000000 R12: ffffbd13003d3830 R13: ffff975850b436a8 R14: ffff975850b43600 R15: 0000000000000007 ORIGRAX: ffffffffffffffff CS: 0010 SS: 0018 9 [ffffbd13003d3808] ip6polroute at ffffffff8ddb030c 10 [ffffbd13003d3888] ip6polrouteinput at ffffffff8ddb068c 11 [ffffbd13003d3898] fib6rulelookup at ffffffff8ddf02b5 12 [ffffbd13003d3928] ip6routeinput at ffffffff8ddb0f47 13 [ffffbd13003d3a18] ip6rcvfinishcore.constprop.0 at ffffffff8dd950d0 14 [ffffbd13003d3a30] ip6listrcvfinish.constprop.0 at ffffffff8dd96274 15 [ffffbd13003d3a98] ip6sublistrcv at ffffffff8dd96474 16 [ffffbd13003d3af8] ipv6listrcv at ffffffff8dd96615 17 [ffffbd13003d3b60] _netifreceiveskblistcore at ffffffff8dc16fec 18 [ffffbd13003d3be0] netifreceiveskblistinternal at ffffffff8dc176b3 19 [ffffbd13003d3c50] napigroreceive at ffffffff8dc565b9 20 [ffffbd13003d3c80] icereceiveskb at ffffffffc087e4f5 [ice] 21 [ffffbd13003d3c90] icecleanrxirq at ffffffffc0881b80 [ice] 22 [ffffbd13003d3d20] icenapipoll at ffffffffc088232f [ice] 23 [ffffbd13003d3d80] _napipoll at ffffffff8dc18000 24 [ffffbd13003d3db8] netrxaction at ffffffff8dc18581 25 [ffffbd13003d3e40] _dosoftirq at ffffffff8df352e9 26 [ffffbd13003d3eb0] runksoftirqd at ffffffff8ceffe47 27 [ffffbd13003d3ec0] smpbootthreadfn at ffffffff8cf36a30 28 [ffffbd13003d3ee8] kthread at ffffffff8cf2b39f 29 [ffffbd13003d3f28] retfromfork at ffffffff8ce5fa64 30 [ffffbd13003d3f50] retfromforkasm at ffffffff8ce03cbb(CVE-2024-56703)

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

soc: imx8m: Probe the SoC driver as platform driver

With driverasyncprobe=* on kernel command line, the following trace is produced because on i.MX8M Plus hardware because the soc-imx8m.c driver calls ofclkgetbyname() which returns -EPROBEDEFER because the clock driver is not yet probed. This was not detected during regular testing without driverasync_probe.

Convert the SoC code to platform driver and instantiate a platform device in its current deviceinitcall() to probe the platform driver. Rework .socrevision callback to always return valid error code and return SoC revision via parameter. This way, if anything in the .socrevision callback return -EPROBEDEFER, it gets propagated to .probe and the .probe will get retried later.

" ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1 at drivers/soc/imx/soc-imx8m.c:115 imx8mmsocrevision+0xdc/0x180 CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-next-20240924-00002-g2062bb554dea #603 Hardware name: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3) (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : imx8mmsocrevision+0xdc/0x180 lr : imx8mmsocrevision+0xd0/0x180 sp : ffff8000821fbcc0 x29: ffff8000821fbce0 x28: 0000000000000000 x27: ffff800081810120 x26: ffff8000818a9970 x25: 0000000000000006 x24: 0000000000824311 x23: ffff8000817f42c8 x22: ffff0000df8be210 x21: fffffffffffffdfb x20: ffff800082780000 x19: 0000000000000001 x18: ffffffffffffffff x17: ffff800081fff418 x16: ffff8000823e1000 x15: ffff0000c03b65e8 x14: ffff0000c00051b0 x13: ffff800082790000 x12: 0000000000000801 x11: ffff80008278ffff x10: ffff80008209d3a6 x9 : ffff80008062e95c x8 : ffff8000821fb9a0 x7 : 0000000000000000 x6 : 00000000000080e3 x5 : ffff0000df8c03d8 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : fffffffffffffdfb x0 : fffffffffffffdfb Call trace: imx8mmsocrevision+0xdc/0x180 imx8socinit+0xb0/0x1e0 dooneinitcall+0x94/0x1a8 kernelinitfreeable+0x240/0x2a8 kernelinit+0x28/0x140 retfrom_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- SoC: i.MX8MP revision 1.1 "(CVE-2024-56787)

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

net/mlx5e: Skip restore TC rules for vport rep without loaded flag

During driver unload, unregisternetdev is called after unloading vport rep. So, the mlx5ereppriv is already freed while trying to get rpriv->netdev, or walk rpriv->tcht, which results in use-after-free. So add the checking to make sure access the data of vport rep which is still loaded.(CVE-2024-57801)

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

s390/cpum_sf: Handle CPU hotplug remove during sampling

CPU hotplug remove handling triggers the following function call sequence:

CPUHPAPPERFS390SFONLINE --> s390pmusfofflinecpu() ... CPUHPAPPERFONLINE --> perfeventexit_cpu()

The s390 CPUMF sampling CPU hotplug handler invokes:

s390pmusfofflinecpu() +--> cpusfpmusetup() +--> setuppmccpu() +--> deallocate_buffers()

This function de-allocates all sampling data buffers (SDBs) allocated for that CPU at event initialization. It also clears the PMUFRESERVED bit. The CPU is gone and can not be sampled.

With the event still being active on the removed CPU, the CPU event hotplug support in kernel performance subsystem triggers the following function calls on the removed CPU:

perfeventexitcpu() +--> perfeventexitcpucontext() +--> _perfeventexitcontext() +--> _perfremovefromcontext() +--> eventschedout() +--> cpumsfpmudel() +--> cpumsfpmustop() +--> hwperfeventupdate()

to stop and remove the event. During removal of the event, the sampling device driver tries to read out the remaining samples from the sample data buffers (SDBs). But they have already been freed (and may have been re-assigned). This may lead to a use after free situation in which case the samples are most likely invalid. In the best case the memory has not been reassigned and still contains valid data.

Remedy this situation and check if the CPU is still in reserved state (bit PMUFRESERVED set). In this case the SDBs have not been released an contain valid data. This is always the case when the event is removed (and no CPU hotplug off occured). If the PMUFRESERVED bit is not set, the SDB buffers are gone.(CVE-2024-57849)

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

scsi: ufs: pltfrm: Dellocate HBA during ufshcdpltfrmremove()

This will ensure that the scsi host is cleaned up properly using scsihostdev_release(). Otherwise, it may lead to memory leaks.(CVE-2024-57872)

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

ALSA: seq: oss: Fix races at processing SysEx messages

OSS sequencer handles the SysEx messages split in 6 bytes packets, and ALSA sequencer OSS layer tries to combine those. It stores the data in the internal buffer and this access is racy as of now, which may lead to the out-of-bounds access.

As a temporary band-aid fix, introduce a mutex for serializing the process of the SysEx message packets.(CVE-2024-57893)

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

iio: adc: at91: call inputfreedevice() on allocated iio_dev

Current implementation of at91tsregister() calls inputfreedeivce() on st->tsinput, however, the err label can be reached before the allocated iiodev is stored to st->tsinput. Thus call inputfreedevice() on input instead of st->tsinput.(CVE-2024-57904)

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

selinux: ignore unknown extended permissions

When evaluating extended permissions, ignore unknown permissions instead of calling BUG(). This commit ensures that future permissions can be added without interfering with older kernels.(CVE-2024-57931)

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

irqchip/gic-v3-its: Don't enable interrupts in itsirqsetvcpuaffinity()

The following call-chain leads to enabling interrupts in a nested interrupt disabled section:

irqsetvcpuaffinity() irqgetdesclock() rawspinlockirqsave() <--- Disable interrupts itsirqsetvcpuaffinity() guard(rawspinlockirq) <--- Enables interrupts when leaving the guard() irqputdescunlock() <--- Warns because interrupts are enabled

This was broken in commit b97e8a2f7130, which replaced the original rawspin[un]lock() pair with guard(rawspinlockirq).

Fix the issue by using guard(raw_spinlock).

tglx: Massaged change log

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

sched: sch_cake: add bounds checks to host bulk flow fairness counts

Even though we fixed a logic error in the commit cited below, syzbot still managed to trigger an underflow of the per-host bulk flow counters, leading to an out of bounds memory access.

To avoid any such logic errors causing out of bounds memory accesses, this commit factors out all accesses to the per-host bulk flow counters to a series of helpers that perform bounds-checking before any increments and decrements. This also has the benefit of improving readability by moving the conditional checks for the flow mode into these helpers, instead of having them spread out throughout the code (which was the cause of the original logic error).

As part of this change, the flow quantum calculation is consolidated into a helper function, which means that the dithering applied to the ost load scaling is now applied both in the DRR rotation and when a sparse flow's quantum is first initiated. The only user-visible effect of this is that the maximum packet size that can be sent while a flow stays sparse will now vary with +/- one byte in some cases. This should not make a noticeable difference in practice, and thus it's not worth complicating the code to preserve the old behaviour.(CVE-2025-21647)

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

netfilter: conntrack: clamp maximum hashtable size to INT_MAX

Use INTMAX as maximum size for the conntrack hashtable. Otherwise, it is possible to hit WARNONONCE in _kvmallocnodenoprof() when resizing hashtable because _GFPNOWARN is unset. See:

0708a0afe291 ("mm: Consider _GFPNOWARN flag for oversized kvmalloc() calls")

Note: hashtable resize is only possible from init_netns.(CVE-2025-21648)

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

netsched: clsflow: validate TCAFLOWRSHIFT attribute

syzbot found that TCAFLOWRSHIFT attribute was not validated. Right shitfing a 32bit integer is undefined for large shift values.

UBSAN: shift-out-of-bounds in net/sched/clsflow.c:329:23 shift exponent 9445 is too large for 32-bit type 'u32' (aka 'unsigned int') CPU: 1 UID: 0 PID: 54 Comm: kworker/u8:3 Not tainted 6.13.0-rc3-syzkaller-00180-g4f619d518db9 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: ipv6addrconf addrconfdadwork Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 ubsanepilogue lib/ubsan.c:231 [inline] _ubsanhandleshiftoutofbounds+0x3c8/0x420 lib/ubsan.c:468 flowclassify+0x24d5/0x25b0 net/sched/clsflow.c:329 tcclassify include/net/tcwrapper.h:197 [inline] _tcfclassify net/sched/clsapi.c:1771 [inline] tcfclassify+0x420/0x1160 net/sched/clsapi.c:1867 sfbclassify net/sched/schsfb.c:260 [inline] sfbenqueue+0x3ad/0x18b0 net/sched/schsfb.c:318 devqdiscenqueue+0x4b/0x290 net/core/dev.c:3793 _devxmitskb net/core/dev.c:3889 [inline] _devqueuexmit+0xf0e/0x3f50 net/core/dev.c:4400 devqueuexmit include/linux/netdevice.h:3168 [inline] neighhhoutput include/net/neighbour.h:523 [inline] neighoutput include/net/neighbour.h:537 [inline] ipfinishoutput2+0xd41/0x1390 net/ipv4/ipoutput.c:236 iptunnelxmit+0x55d/0x9b0 net/ipv4/iptunnelcore.c:82 udptunnelxmitskb+0x262/0x3b0 net/ipv4/udptunnelcore.c:173 genevexmitskb drivers/net/geneve.c:916 [inline] genevexmit+0x21dc/0x2d00 drivers/net/geneve.c:1039 _netdevstartxmit include/linux/netdevice.h:5002 [inline] netdevstartxmit include/linux/netdevice.h:5011 [inline] xmitone net/core/dev.c:3590 [inline] devhardstartxmit+0x27a/0x7d0 net/core/dev.c:3606 _devqueue_xmit+0x1b73/0x3f50 net/core/dev.c:4434(CVE-2025-21653)

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

iomap: avoid avoid truncating 64-bit offset to 32 bits

on 32-bit kernels, iomapwritedelallocscan() was inadvertently using a 32-bit position due to folionext_index() returning an unsigned long. This could lead to an infinite loop when writing to an xfs filesystem.(CVE-2025-21667)

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

pmdomain: imx8mp-blk-ctrl: add missing loop break condition

Currently imx8mpblkctrl_remove() will continue the for loop until an out-of-bounds exception occurs.

pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : devpmdomaindetach+0x8/0x48 lr : imx8mpblkctrlshutdown+0x58/0x90 sp : ffffffc084f8bbf0 x29: ffffffc084f8bbf0 x28: ffffff80daf32ac0 x27: 0000000000000000 x26: ffffffc081658d78 x25: 0000000000000001 x24: ffffffc08201b028 x23: ffffff80d0db9490 x22: ffffffc082340a78 x21: 00000000000005b0 x20: ffffff80d19bc180 x19: 000000000000000a x18: ffffffffffffffff x17: ffffffc080a39e08 x16: ffffffc080a39c98 x15: 4f435f464f006c72 x14: 0000000000000004 x13: ffffff80d0172110 x12: 0000000000000000 x11: ffffff80d0537740 x10: ffffff80d05376c0 x9 : ffffffc0808ed2d8 x8 : ffffffc084f8bab0 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffffff80d19b9420 x4 : fffffffe03466e60 x3 : 0000000080800077 x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000000 Call trace: devpmdomaindetach+0x8/0x48 platformshutdown+0x2c/0x48 deviceshutdown+0x158/0x268 kernelrestartprepare+0x40/0x58 kernelkexec+0x58/0xe8 _dosysreboot+0x198/0x258 _arm64sysreboot+0x2c/0x40 invokesyscall+0x5c/0x138 el0svccommon.constprop.0+0x48/0xf0 doel0svc+0x24/0x38 el0svc+0x38/0xc8 el0t64synchandler+0x120/0x130 el0t64_sync+0x190/0x198 Code: 8128c2d0 ffffffc0 aa1e03e9 d503201f(CVE-2025-21668)

In the Linux kernel, the following vulnerability has been resolved: fs/proc: fix softlockup in _readvmcore (part 2) Since commit 5cbcb62dddf5 ("fs/proc: fix softlockup in _readvmcore") the number of softlockups in _readvmcore at kdump time have gone down, but they still happen sometimes. In a memory constrained environment like the kdump image, a softlockup is not just a harmless message, but it can interfere with things like RCU freeing memory, causing the crashdump to get stuck. The second loop in _readvmcore has a lot more opportunities for natural sleep points, like scheduling out while waiting for a data write to happen, but apparently that is not always enough. Add a condresched() to the second loop in _read_vmcore to (hopefully) get rid of the softlockups.(CVE-2025-21694)