OESA-2025-1249

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

sched: fix warning in sched_setaffinity

Commit 8f9ea86fdf99b added some logic to sched_setaffinity that included a WARN when a per-task affinity assignment races with a cpuset update.

Specifically, we can have a race where a cpuset update results in the task affinity no longer being a subset of the cpuset. That's fine; we have a fallback to instead use the cpuset mask. However, we have a WARN set up that will trigger if the cpuset mask has no overlap at all with the requested task affinity. This shouldn't be a warning condition; its trivial to create this condition.

Reproduced the warning by the following setup:

• $PID inside a cpuset cgroup
• another thread repeatedly switching the cpuset cpus from 1-2 to just 1
• another thread repeatedly setting the $PID affinity (via taskset) to 2(CVE-2024-41932)

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

riscv: Fix IPIs usage in kfenceprotectpage()

flushtlbkernel_range() may use IPIs to flush the TLBs of all the cores, which triggers the following warning when the irqs are disabled:

[ 3.455330] WARNING: CPU: 1 PID: 0 at kernel/smp.c:815 smpcallfunctionmanycond+0x452/0x520 [ 3.456647] Modules linked in: [ 3.457218] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.12.0-rc7-00010-g91d3de7240b8 #1 [ 3.457416] Hardware name: QEMU QEMU Virtual Machine, BIOS [ 3.457633] epc : smpcallfunctionmanycond+0x452/0x520 [ 3.457736] ra : oneachcpucondmask+0x1e/0x30 [ 3.457786] epc : ffffffff800b669a ra : ffffffff800b67c2 sp : ff2000000000bb50 [ 3.457824] gp : ffffffff815212b8 tp : ff6000008014f080 t0 : 000000000000003f [ 3.457859] t1 : ffffffff815221e0 t2 : 000000000000000f s0 : ff2000000000bc10 [ 3.457920] s1 : 0000000000000040 a0 : ffffffff815221e0 a1 : 0000000000000001 [ 3.457953] a2 : 0000000000010000 a3 : 0000000000000003 a4 : 0000000000000000 [ 3.458006] a5 : 0000000000000000 a6 : ffffffffffffffff a7 : 0000000000000000 [ 3.458042] s2 : ffffffff815223be s3 : 00fffffffffff000 s4 : ff600001ffe38fc0 [ 3.458076] s5 : ff600001ff950d00 s6 : 0000000200000120 s7 : 0000000000000001 [ 3.458109] s8 : 0000000000000001 s9 : ff60000080841ef0 s10: 0000000000000001 [ 3.458141] s11: ffffffff81524812 t3 : 0000000000000001 t4 : ff60000080092bc0 [ 3.458172] t5 : 0000000000000000 t6 : ff200000000236d0 [ 3.458203] status: 0000000200000100 badaddr: ffffffff800b669a cause: 0000000000000003 [ 3.458373] [<ffffffff800b669a>] smpcallfunctionmanycond+0x452/0x520 [ 3.458593] [<ffffffff800b67c2>] oneachcpucondmask+0x1e/0x30 [ 3.458625] [<ffffffff8000e4ca>] _flushtlbrange+0x118/0x1ca [ 3.458656] [<ffffffff8000e6b2>] flushtlbkernelrange+0x1e/0x26 [ 3.458683] [<ffffffff801ea56a>] kfenceprotect+0xc0/0xce [ 3.458717] [<ffffffff801e9456>] kfenceguardedfree+0xc6/0x1c0 [ 3.458742] [<ffffffff801e9d6c>] _kfencefree+0x62/0xc6 [ 3.458764] [<ffffffff801c57d8>] kfree+0x106/0x32c [ 3.458786] [<ffffffff80588cf2>] detachbufsplit+0x188/0x1a8 [ 3.458816] [<ffffffff8058708c>] virtqueuegetbufctx+0xb6/0x1f6 [ 3.458839] [<ffffffff805871da>] virtqueuegetbuf+0xe/0x16 [ 3.458880] [<ffffffff80613d6a>] virtblkdone+0x5c/0xe2 [ 3.458908] [<ffffffff8058766e>] vringinterrupt+0x6a/0x74 [ 3.458930] [<ffffffff800747d8>] _handleirqeventpercpu+0x7c/0xe2 [ 3.458956] [<ffffffff800748f0>] handleirqevent+0x3c/0x86 [ 3.458978] [<ffffffff800786cc>] handlesimpleirq+0x9e/0xbe [ 3.459004] [<ffffffff80073934>] generichandledomainirq+0x1c/0x2a [ 3.459027] [<ffffffff804bf87c>] imsichandleirq+0xba/0x120 [ 3.459056] [<ffffffff80073934>] generichandledomainirq+0x1c/0x2a [ 3.459080] [<ffffffff804bdb76>] riscvintcaiairq+0x24/0x34 [ 3.459103] [<ffffffff809d0452>] handleriscvirq+0x2e/0x4c [ 3.459133] [<ffffffff809d923e>] callonirqstack+0x32/0x40

So only flush the local TLB and let the lazy kfence page fault handling deal with the faults which could happen when a core has an old protected pte version cached in its TLB. That leads to potential inaccuracies which can be tolerated when using kfence.(CVE-2024-53687)

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

Drivers: hv: util: Avoid accessing a ringbuffer not initialized yet

If the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer is fully initialized, we can hit the panic below:

hvutils: Registering HyperV Utility Driver hvvmbus: registering driver hvutils ... BUG: kernel NULL pointer dereference, address: 0000000000000000 CPU: 44 UID: 0 PID: 2552 Comm: hvkvpdaemon Tainted: G E 6.11.0-rc3+ #1 RIP: 0010:hvpktiterfirst+0x12/0xd0 Call Trace: ... vmbusrecvpacket hvkvponchannelcallback vmbusonevent taskletactioncommon taskletaction handlesoftirqs irqexitrcu sysvechypervstimer0 </IRQ> <TASK> asmsysvechypervstimer0 ... kvpregisterdone hvtopread vfsread ksysread _x64sys_read

This can happen because the KVP/VSS channel callback can be invoked even before the channel is fully opened: 1) as soon as hvkvpinit() -> hvutiltransportinit() creates /dev/vmbus/hvkvp, the kvp daemon can open the device file immediately and register itself to the driver by writing a message KVPOPREGISTER1 to the file (which is handled by kvponmsg() ->kvphandlehandshake()) and reading the file for the driver's response, which is handled by hvtopread(), which calls hvt->onread(), i.e. kvpregisterdone().

2) the problem with kvpregisterdone() is that it can cause the channel callback to be called even before the channel is fully opened, and when the channel callback is starting to run, utilprobe()-> vmbusopen() may have not initialized the ringbuffer yet, so the callback can hit the panic of NULL pointer dereference.

To reproduce the panic consistently, we can add a "ssleep(10)" for KVP in _vmbusopen(), just before the first hvringbufferinit(), and then we unload and reload the driver hv_utils, and run the daemon manually within the 10 seconds.

Fix the panic by reordering the steps in utilprobe() so the char dev entry used by the KVP or VSS daemon is not created until after vmbusopen() has completed. This reordering prevents the race condition from happening.(CVE-2024-55916)

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

ALSA: control: Avoid WARN() for symlink errors

Using WARN() for showing the error of symlink creations don't give more information than telling that something goes wrong, since the usual code path is a lregister callback from each control element creation. More badly, the use of WARN() rather confuses fuzzer as if it were serious issues.

This patch downgrades the warning messages to use the normal dev_err() instead of WARN(). For making it clearer, add the function name to the prefix, too.(CVE-2024-56657)

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

netdevsim: prevent bad user input in nsimdevhealthbreakwrite()

If either a zero count or a large one is provided, kernel can crash.(CVE-2024-56716)

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

net: stmmac: fix TSO DMA API usage causing oops

Commit 66600fac7a98 ("net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data") moved the assignment of txskbuffdma[]'s members to be later in stmmactsoxmit().

The buf (dma cookie) and len stored in this structure are passed to dmaunmapsingle() by stmmactxclean(). The DMA API requires that the dma cookie passed to dmaunmapsingle() is the same as the value returned from dmamapsingle(). However, by moving the assignment later, this is not the case when priv->dmacap.addr64 > 32 as "des" is offset by protohdr_len.

This causes problems such as:

dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed

and with DMAAPIDEBUG enabled:

DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes]

Fix this by maintaining "des" as the original DMA cookie, and use tsodes to pass the offset DMA cookie to stmmactso_allocator().

Full details of the crashes can be found at: https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/ https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/(CVE-2024-56719)

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

powerpc/pseries/vas: Add close() callback in vasvmops struct

The mapping VMA address is saved in VAS window struct when the paste address is mapped. This VMA address is used during migration to unmap the paste address if the window is active. The paste address mapping will be removed when the window is closed or with the munmap(). But the VMA address in the VAS window is not updated with munmap() which is causing invalid access during migration.

The KASAN report shows: [16386.254991] BUG: KASAN: slab-use-after-free in reconfigclosewindows+0x1a0/0x4e8 [16386.255043] Read of size 8 at addr c00000014a819670 by task drmgr/696928

[16386.255096] CPU: 29 UID: 0 PID: 696928 Comm: drmgr Kdump: loaded Tainted: G B 6.11.0-rc5-nxgzip #2 [16386.255128] Tainted: [B]=BADPAGE [16386.255148] Hardware name: IBM,9080-HEX Power11 (architected) 0x820200 0xf000007 of:IBM,FW1110.00 (NH1110016) hv:phyp pSeries [16386.255181] Call Trace: [16386.255202] [c00000016b297660] [c0000000018ad0ac] dumpstacklvl+0x84/0xe8 (unreliable) [16386.255246] [c00000016b297690] [c0000000006e8a90] printreport+0x19c/0x764 [16386.255285] [c00000016b297760] [c0000000006e9490] kasanreport+0x128/0x1f8 [16386.255309] [c00000016b297880] [c0000000006eb5c8] _asanload8+0xac/0xe0 [16386.255326] [c00000016b2978a0] [c00000000013f898] reconfigclosewindows+0x1a0/0x4e8 [16386.255343] [c00000016b297990] [c000000000140e58] vasmigrationhandler+0x3a4/0x3fc [16386.255368] [c00000016b297a90] [c000000000128848] pseriesmigratepartition+0x4c/0x4c4 ...

[16386.256136] Allocated by task 696554 on cpu 31 at 16377.277618s: [16386.256149] kasansavestack+0x34/0x68 [16386.256163] kasansavetrack+0x34/0x80 [16386.256175] kasansaveallocinfo+0x58/0x74 [16386.256196] _kasanslaballoc+0xb8/0xdc [16386.256209] kmemcacheallocnoprof+0x200/0x3d0 [16386.256225] vmareaalloc+0x44/0x150 [16386.256245] mmapregion+0x214/0x10c4 [16386.256265] dommap+0x5fc/0x750 [16386.256277] vmmmappgoff+0x14c/0x24c [16386.256292] ksysmmappgoff+0x20c/0x348 [16386.256303] sysmmap+0xd0/0x160 ...

[16386.256350] Freed by task 0 on cpu 31 at 16386.204848s: [16386.256363] kasansavestack+0x34/0x68 [16386.256374] kasansavetrack+0x34/0x80 [16386.256384] kasansavefreeinfo+0x64/0x10c [16386.256396] _kasanslabfree+0x120/0x204 [16386.256415] kmemcachefree+0x128/0x450 [16386.256428] vmareafreercucb+0xa8/0xd8 [16386.256441] rcudobatch+0x2c8/0xcf0 [16386.256458] rcucore+0x378/0x3c4 [16386.256473] handlesoftirqs+0x20c/0x60c [16386.256495] dosoftirqownstack+0x6c/0x88 [16386.256509] dosoftirqownstack+0x58/0x88 [16386.256521] _irqexitrcu+0x1a4/0x20c [16386.256533] irqexit+0x20/0x38 [16386.256544] interruptasyncexit_prepare.constprop.0+0x18/0x2c ...

[16386.256717] Last potentially related work creation: [16386.256729] kasansavestack+0x34/0x68 [16386.256741] _kasanrecordauxstack+0xcc/0x12c [16386.256753] _callrcucommon.constprop.0+0x94/0xd04 [16386.256766] vmareafree+0x28/0x3c [16386.256778] removevma+0xf4/0x114 [16386.256797] dovmialignmunmap.constprop.0+0x684/0x870 [16386.256811] _vmmunmap+0xe0/0x1f8 [16386.256821] sysmunmap+0x54/0x6c [16386.256830] systemcallexception+0x1a0/0x4a0 [16386.256841] systemcallvectored_common+0x15c/0x2ec

[16386.256868] The buggy address belongs to the object at c00000014a819670 which belongs to the cache vmareastruct of size 168 [16386.256887] The buggy address is located 0 bytes inside of freed 168-byte region [c00000014a819670, c00000014a819718)

[16386.256915] The buggy address belongs to the physical page: [16386.256928] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14a81 [16386.256950] memcg:c0000000ba430001 [16386.256961] anon flags: 0x43ffff800000000(node=4|zone=0|lastcpupid=0x7ffff) [16386.256975] page_type: 0xfdffffff(slab) [16386 ---truncated---(CVE-2024-56765)

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

net/sched: netem: account for backlog updates from child qdisc

In general, 'qlen' of any classful qdisc should keep track of the number of packets that the qdisc itself and all of its children holds. In case of netem, 'qlen' only accounts for the packets in its internal tfifo. When netem is used with a child qdisc, the child qdisc can use 'qdisctreereduce_backlog' to inform its parent, netem, about created or dropped SKBs. This function updates 'qlen' and the backlog statistics of netem, but netem does not account for changes made by a child qdisc. 'qlen' then indicates the wrong number of packets in the tfifo. If a child qdisc creates new SKBs during enqueue and informs its parent about this, netem's 'qlen' value is increased. When netem dequeues the newly created SKBs from the child, the 'qlen' in netem is not updated. If 'qlen' reaches the configured sch->limit, the enqueue function stops working, even though the tfifo is not full.

Reproduce the bug: Ensure that the sender machine has GSO enabled. Configure netem as root qdisc and tbf as its child on the outgoing interface of the machine as follows: $ tc qdisc add dev <oif> root handle 1: netem delay 100ms limit 100 $ tc qdisc add dev <oif> parent 1:0 tbf rate 50Mbit burst 1542 latency 50ms

Send bulk TCP traffic out via this interface, e.g., by running an iPerf3 client on the machine. Check the qdisc statistics: $ tc -s qdisc show dev <oif>

Statistics after 10s of iPerf3 TCP test before the fix (note that netem's backlog > limit, netem stopped accepting packets): qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0) backlog 4294528236b 1155p requeues 0 qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0) backlog 0b 0p requeues 0

Statistics after the fix: qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0) backlog 0b 0p requeues 0

tbf segments the GSO SKBs (tbf_segment) and updates the netem's 'qlen'. The interface fully stops transferring packets and "locks". In this case, the child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is at its limit and no more packets are accepted.

This patch adds a counter for the entries in the tfifo. Netem's 'qlen' is only decreased when a packet is returned by its dequeue function, and not during enqueuing into the child qdisc. External updates to 'qlen' are thus accounted for and only the behavior of the backlog statistics changes. As in other qdiscs, 'qlen' then keeps track of how many packets are held in netem and all of its children. As before, sch->limit remains as the maximum number of packets in the tfifo. The same applies to netem's backlog statistics.(CVE-2024-56770)

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

drm/dpmst: Ensure mstprimary pointer is valid in drmdpmsthandleup_req()

While receiving an MST up request message from one thread in drmdpmsthandleupreq(), the MST topology could be removed from another thread via drmdpmsttopologymgrsetmst(false), freeing mstprimary and setting drmdpmsttopologymgr::mstprimary to NULL. This could lead to a NULL deref/use-after-free of mstprimary in drmdpmsthandleup_req().

Avoid the above by holding a reference for mstprimary in drmdpmsthandleupreq() while it's used.

v2: Fix kfreeing the request if getting an mst_primary reference fails.(CVE-2024-57798)

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

iio: adc: rockchip_saradc: fix information leak in triggered buffer

The 'data' local struct is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iioforeachactivechannel() to assign new values.

Initialize the struct to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57907)

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

RDMA/hns: Fix accessing invalid dip_ctx during destroying QP

If it fails to modify QP to RTR, dipctx will not be attached. And during detroying QP, the invalid dipctx pointer will be accessed.(CVE-2024-57935)

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

memcg: fix soft lockup in the OOM process

A soft lockup issue was found in the product with about 56,000 tasks were in the OOM cgroup, it was traversing them when the soft lockup was triggered.

watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066] CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G Hardware name: Huawei Cloud OpenStack Nova, BIOS RIP: 0010:consoleunlock+0x343/0x540 RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIGRAX: ffffffffffffff13 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247 RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040 R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0 R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vprintkemit+0x193/0x280 printk+0x52/0x6e dumptask+0x114/0x130 memcgroupscantasks+0x76/0x100 dumpheader+0x1fe/0x210 oomkillprocess+0xd1/0x100 outofmemory+0x125/0x570 memcgroupoutofmemory+0xb5/0xd0 trycharge+0x720/0x770 memcgrouptrycharge+0x86/0x180 memcgrouptrychargedelay+0x1c/0x40 doanonymouspage+0xb5/0x390 handlemmfault+0xc4/0x1f0

This is because thousands of processes are in the OOM cgroup, it takes a long time to traverse all of them. As a result, this lead to soft lockup in the OOM process.

To fix this issue, call 'condresched' in the 'memcgroupscantasks' function per 1000 iterations. For global OOM, call 'touchsoftlockupwatchdog' per 1000 iterations to avoid this issue.(CVE-2024-57977)

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

binfmt_flat: Fix integer overflow bug on 32 bit systems

Most of these sizes and counts are capped at 256MB so the math doesn't result in an integer overflow. The "relocs" count needs to be checked as well. Otherwise on 32bit systems the calculation of "full_data" could be wrong.

full_data = data_len + relocs * sizeof(unsigned long);(CVE-2024-58010)

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

cgroup/cpuset: remove kernfs active break

A warning was found:

WARNING: CPU: 10 PID: 3486953 at fs/kernfs/file.c:828 CPU: 10 PID: 3486953 Comm: rmdir Kdump: loaded Tainted: G RIP: 0010:kernfsshoulddrainopenfiles+0x1a1/0x1b0 RSP: 0018:ffff8881107ef9e0 EFLAGS: 00010202 RAX: 0000000080000002 RBX: ffff888154738c00 RCX: dffffc0000000000 RDX: 0000000000000007 RSI: 0000000000000004 RDI: ffff888154738c04 RBP: ffff888154738c04 R08: ffffffffaf27fa15 R09: ffffed102a8e7180 R10: ffff888154738c07 R11: 0000000000000000 R12: ffff888154738c08 R13: ffff888750f8c000 R14: ffff888750f8c0e8 R15: ffff888154738ca0 FS: 00007f84cd0be740(0000) GS:ffff8887ddc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555f9fbe00c8 CR3: 0000000153eec001 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: kernfsdrain+0x15e/0x2f0 _kernfsremove+0x165/0x300 kernfsremovebynamens+0x7b/0xc0 cgrouprmfile+0x154/0x1c0 cgroupaddrmfiles+0x1c2/0x1f0 csscleardir+0x77/0x110 killcss+0x4c/0x1b0 cgroupdestroylocked+0x194/0x380 cgroup_rmdir+0x2a/0x140

It can be explained by: rmdir echo 1 > cpuset.cpus kernfsfopwriteiter // active=0 cgrouprmfile kernfsremovebynamens kernfsgetactive // active=1 _kernfsremove // active=0x80000002 kernfsdrain cpusetwriteresmask waitevent //waiting (active == 0x80000001) kernfsbreakactiveprotection // active = 0x80000001 // continue kernfsunbreakactiveprotection // active = 0x80000002 ... kernfsshoulddrainopenfiles // warning occurs kernfsput_active

This warning is caused by 'kernfsbreakactive_protection' when it is writing to cpuset.cpus, and the cgroup is removed concurrently.

The commit 3a5a6d0c2b03 ("cpuset: don't nest cgroupmutex inside getonlinecpus()") made cpusethotplugworkfn asynchronous, This change involves calling flushwork(), which can create a multiple processes circular locking dependency that involve cgroupmutex, potentially leading to a deadlock. To avoid deadlock. the commit 76bb5ab8f6e3 ("cpuset: break kernfs active protection in cpusetwriteresmask()") added 'kernfsbreakactiveprotection' in the cpusetwriteresmask. This could lead to this warning.

After the commit 2125c0034c5d ("cgroup/cpuset: Make cpuset hotplug processing synchronous"), the cpusetwriteresmask no longer needs to wait the hotplug to finish, which means that concurrent hotplug and cpuset operations are no longer possible. Therefore, the deadlock doesn't exist anymore and it does not have to 'break active protection' now. To fix this warning, just remove kernfsbreakactiveprotection operation in the 'cpusetwrite_resmask'.(CVE-2025-21634)

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

net: hns3: don't auto enable misc vector

Currently, there is a time window between misc irq enabled and service task inited. If an interrupte is reported at this time, it will cause warning like below:

[ 16.324639] Call trace: [ 16.324641] _queuedelayedwork+0xb8/0xe0 [ 16.324643] moddelayedworkon+0x78/0xd0 [ 16.324655] hclgeerrhandtaskschedule+0x58/0x90 [hclge] [ 16.324662] hclgemiscirqhandle+0x168/0x240 [hclge] [ 16.324666] _handleirqeventpercpu+0x64/0x1e0 [ 16.324667] handleirqevent+0x80/0x170 [ 16.324670] handlefasteoiedgeirq+0x110/0x2bc [ 16.324671] _handledomainirq+0x84/0xfc [ 16.324673] gichandleirq+0x88/0x2c0 [ 16.324674] el1irq+0xb8/0x140 [ 16.324677] archcpuidle+0x18/0x40 [ 16.324679] defaultidlecall+0x5c/0x1bc [ 16.324682] cpuidleidlecall+0x18c/0x1c4 [ 16.324684] doidle+0x174/0x17c [ 16.324685] cpustartupentry+0x30/0x6c [ 16.324687] secondarystartkernel+0x1a4/0x280 [ 16.324688] ---[ end trace 6aa0bff672a964aa ]---

So don't auto enable misc vector when request irq..(CVE-2025-21651)

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

nbd: don't allow reconnect after disconnect

Following process can cause nbd_config UAF:

1) grab nbd_config temporarily;

2) nbdgenldisconnect() flush all recv_work() and release the initial reference:

nbdgenldisconnect nbddisconnectandput nbddisconnect flushworkqueue(nbd->recvworkq) if (testandclearbit(NBDRTHASCONFIGREF, ...)) nbdconfig_put -> due to step 1), reference is still not zero

3) nbdgenlreconfigure() queue recv_work() again;

nbdgenlreconfigure config = nbdgetconfigunlocked(nbd) if (!config) -> succeed if (!testbit(NBDRTBOUND, ...)) -> succeed nbdreconnectsocket queuework(nbd->recvworkq, &args->work)

4) step 1) release the reference;

5) Finially, recv_work() will trigger UAF:

recvwork nbdconfigput(nbd) -> nbdconfig is freed atomicdec(&config->recvthreads) -> UAF

Fix the problem by clearing NBDRTBOUND in nbdgenldisconnect(), so that nbdgenlreconfigure() will fail.(CVE-2025-21731)

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

tracing/osnoise: Fix resetting of tracepoints

If a timerlat tracer is started with the osnoise option OSNOISE_WORKLOAD disabled, but then that option is enabled and timerlat is removed, the tracepoints that were enabled on timerlat registration do not get disabled. If the option is disabled again and timelat is started, then it triggers a warning in the tracepoint code due to registering the tracepoint again without ever disabling it.

Do not use the same user space defined options to know to disable the tracepoints when timerlat is removed. Instead, set a global flag when it is enabled and use that flag to know to disable the events.

~# echo NOOSNOISEWORKLOAD > /sys/kernel/tracing/osnoise/options ~# echo timerlat > /sys/kernel/tracing/currenttracer ~# echo OSNOISEWORKLOAD > /sys/kernel/tracing/osnoise/options ~# echo nop > /sys/kernel/tracing/currenttracer ~# echo NOOSNOISEWORKLOAD > /sys/kernel/tracing/osnoise/options ~# echo timerlat > /sys/kernel/tracing/currenttracer

Triggers:

------------[ cut here ]------------ WARNING: CPU: 6 PID: 1337 at kernel/tracepoint.c:294 tracepointaddfunc+0x3b6/0x3f0 Modules linked in: CPU: 6 UID: 0 PID: 1337 Comm: rtla Not tainted 6.13.0-rc4-test-00018-ga867c441128e-dirty #73 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tracepointaddfunc+0x3b6/0x3f0 Code: 48 8b 53 28 48 8b 73 20 4c 89 04 24 e8 23 59 11 00 4c 8b 04 24 e9 36 fe ff ff 0f 0b b8 ea ff ff ff 45 84 e4 0f 84 68 fe ff ff <0f> 0b e9 61 fe ff ff 48 8b 7b 18 48 85 ff 0f 84 4f ff ff ff 49 8b RSP: 0018:ffffb9b003a87ca0 EFLAGS: 00010202 RAX: 00000000ffffffef RBX: ffffffff92f30860 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9bf59e91ccd0 RDI: ffffffff913b6410 RBP: 000000000000000a R08: 00000000000005c7 R09: 0000000000000002 R10: ffffb9b003a87ce0 R11: 0000000000000002 R12: 0000000000000001 R13: ffffb9b003a87ce0 R14: ffffffffffffffef R15: 0000000000000008 FS: 00007fce81209240(0000) GS:ffff9bf6fdd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055e99b728000 CR3: 00000001277c0002 CR4: 0000000000172ef0 Call Trace: <TASK> ? _warn.cold+0xb7/0x14d ? tracepointaddfunc+0x3b6/0x3f0 ? reportbug+0xea/0x170 ? handlebug+0x58/0x90 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? _pfxtraceschedmigratecallback+0x10/0x10 ? tracepointaddfunc+0x3b6/0x3f0 ? _pfxtraceschedmigratecallback+0x10/0x10 ? _pfxtraceschedmigratecallback+0x10/0x10 tracepointproberegister+0x78/0xb0 ? _pfxtraceschedmigratecallback+0x10/0x10 osnoiseworkloadstart+0x2b5/0x370 timerlattracerinit+0x76/0x1b0 tracingsettracer+0x244/0x400 tracingsettracewrite+0xa0/0xe0 vfswrite+0xfc/0x570 ? dosysopenat2+0x9c/0xe0 ksyswrite+0x72/0xf0 dosyscall64+0x79/0x1c0 entrySYSCALL64after_hwframe+0x76/0x7e(CVE-2025-21733)

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

net: hns3: fix oops when unload drivers paralleling

When unload hclge driver, it tries to disable sriov first for each aedev node from hnae3aedevlist. If user unloads hns3 driver at the time, because it removes all the ae_dev nodes, and it may cause oops.

But we can't simply use hnae3commonlock for this. Because in the process flow of pcidisablesriov(), it will trigger the remove flow of VF, which will also take hnae3commonlock.

To fixes it, introduce a new mutex to protect the unload process.(CVE-2025-21802)

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

mm/compaction: fix UBSAN shift-out-of-bounds warning

syzkaller reported a UBSAN shift-out-of-bounds warning of (1UL << order) in isolatefreepagesblock(). The bogus compoundorder can be any value because it is union with flags. Add back the MAXPAGE_ORDER check to fix the warning.(CVE-2025-21815)