OESA-2025-1372

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

SUNRPC: make sure cache entry active before cache_show

The function c_show was called with protection from RCU. This only ensures that cp will not be freed. Therefore, the reference count for cp can drop to zero, which will trigger a refcount use-after-free warning when cache_get is called. To resolve this issue, use cache_get_rcu to ensure that cp remains active.

------------[ cut here ]------------ refcountt: addition on 0; use-after-free. WARNING: CPU: 7 PID: 822 at lib/refcount.c:25 refcountwarnsaturate+0xb1/0x120 CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcountwarn_saturate+0xb1/0x120

Call Trace: <TASK> cshow+0x2fc/0x380 [sunrpc] seqreaditer+0x589/0x770 seqread+0x1e5/0x270 procregread+0xe1/0x140 vfsread+0x125/0x530 ksysread+0xc1/0x160 dosyscall64+0x5f/0x170 entrySYSCALL64afterhwframe+0x76/0x7e(CVE-2024-53174)

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

ipvs: fix UB due to uninitialized stack access in ipvsprotocol_init()

Under certain kernel configurations when building with Clang/LLVM, the compiler does not generate a return or jump as the terminator instruction for ipvsprotocol_init(), triggering the following objtool warning during build time:

vmlinux.o: warning: objtool: ipvsprotocolinit() falls through to next function initstubkmodipvsrr_935123ipvsrrinit6()

At runtime, this either causes an oops when trying to load the ipvs module or a boot-time panic if ipvs is built-in. This same issue has been reported by the Intel kernel test robot previously.

Digging deeper into both LLVM and the kernel code reveals this to be a undefined behavior problem. ipvsprotocolinit() uses a on-stack buffer of 64 chars to store the registered protocol names and leaves it uninitialized after definition. The function calls strnlen() when concatenating protocol names into the buffer. With CONFIGFORTIFY_SOURCE strnlen() performs an extra step to check whether the last byte of the input char buffer is a null character (commit 3009f891bb9f ("fortify: Allow strlen() and strnlen() to pass compile-time known lengths")). This, together with possibly other configurations, cause the following IR to be generated:

define hidden i32 @ipvsprotocolinit() localunnamedaddr #5 section ".init.text" align 16 !kcfitype !29 { %1 = alloca [64 x i8], align 16 ...

14: ; preds = %11 %15 = getelementptr inbounds i8, ptr %1, i64 63 %16 = load i8, ptr %15, align 1 %17 = tail call i1 @llvm.is.constant.i8(i8 %16) %18 = icmp eq i8 %16, 0 %19 = select i1 %17, i1 %18, i1 false br i1 %19, label %20, label %23

20: ; preds = %14 %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23 ...

23: ; preds = %14, %11, %20 %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24 ... }

The above code calculates the address of the last char in the buffer (value %15) and then loads from it (value %16). Because the buffer is never initialized, the LLVM GVN pass marks value %16 as undefined:

%13 = getelementptr inbounds i8, ptr %1, i64 63 br i1 undef, label %14, label %17

This gives later passes (SCCP, in particular) more DCE opportunities by propagating the undef value further, and eventually removes everything after the load on the uninitialized stack location:

define hidden i32 @ipvsprotocolinit() localunnamedaddr #0 section ".init.text" align 16 !kcfitype !11 { %1 = alloca [64 x i8], align 16 ...

12: ; preds = %11 %13 = getelementptr inbounds i8, ptr %1, i64 63 unreachable }

In this way, the generated native code will just fall through to the next function, as LLVM does not generate any code for the unreachable IR instruction and leaves the function without a terminator.

Zero the on-stack buffer to avoid this possible UB.(CVE-2024-53680)

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

net: avoid potential UAF in default_operstate()

syzbot reported an UAF in default_operstate() [1]

Issue is a race between device and netns dismantles.

After calling _rtnlunlock() from netdevruntodo(), we can not assume the netns of each device is still alive.

Make sure the device is not in NETREGUNREGISTERED state, and add an ASSERTRTNL() before the call to _devgetbyindex().

We might move this ASSERTRTNL() in _devgetby_index() in the future.

[1]

BUG: KASAN: slab-use-after-free in _devgetbyindex+0x5d/0x110 net/core/dev.c:852 Read of size 8 at addr ffff888043eba1b0 by task syz.0.0/5339

CPU: 0 UID: 0 PID: 5339 Comm: syz.0.0 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0x169/0x550 mm/kasan/report.c:489 kasanreport+0x143/0x180 mm/kasan/report.c:602 _devgetbyindex+0x5d/0x110 net/core/dev.c:852 defaultoperstate net/core/linkwatch.c:51 [inline] rfc2863policy+0x224/0x300 net/core/linkwatch.c:67 linkwatchdodev+0x3e/0x170 net/core/linkwatch.c:170 netdevruntodo+0x461/0x1000 net/core/dev.c:10894 rtnlunlock net/core/rtnetlink.c:152 [inline] rtnlnetunlock include/linux/rtnetlink.h:133 [inline] rtnldellink+0x760/0x8d0 net/core/rtnetlink.c:3520 rtnetlinkrcvmsg+0x791/0xcf0 net/core/rtnetlink.c:6911 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2541 netlinkunicastkernel net/netlink/afnetlink.c:1321 [inline] netlinkunicast+0x7f6/0x990 net/netlink/afnetlink.c:1347 netlinksendmsg+0x8e4/0xcb0 net/netlink/afnetlink.c:1891 socksendmsgnosec net/socket.c:711 [inline] _socksendmsg+0x221/0x270 net/socket.c:726 syssendmsg+0x52a/0x7e0 net/socket.c:2583 _syssendmsg net/socket.c:2637 [inline] _syssendmsg+0x269/0x350 net/socket.c:2669 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f2a3cb80809 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f2a3d9cd058 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f2a3cd45fa0 RCX: 00007f2a3cb80809 RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000008 RBP: 00007f2a3cbf393e R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f2a3cd45fa0 R15: 00007ffd03bc65c8 </TASK>

Allocated by task 5339: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:377 [inline] _kasankmalloc+0x98/0xb0 mm/kasan/common.c:394 kasankmalloc include/linux/kasan.h:260 [inline] _kmalloccachenoprof+0x243/0x390 mm/slub.c:4314 kmallocnoprof include/linux/slab.h:901 [inline] kmallocarraynoprof include/linux/slab.h:945 [inline] netdevcreatehash net/core/dev.c:11870 [inline] netdevinit+0x10c/0x250 net/core/dev.c:11890 opsinit+0x31e/0x590 net/core/netnamespace.c:138 setupnet+0x287/0x9e0 net/core/netnamespace.c:362 copynetns+0x33f/0x570 net/core/netnamespace.c:500 createnewnamespaces+0x425/0x7b0 kernel/nsproxy.c:110 unsharensproxynamespaces+0x124/0x180 kernel/nsproxy.c:228 ksysunshare+0x57d/0xa70 kernel/fork.c:3314 _dosysunshare kernel/fork.c:3385 [inline] _sesysunshare kernel/fork.c:3383 [inline] _x64sysunshare+0x38/0x40 kernel/fork.c:3383 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall_64+0xf3/0x230 arch/x8 ---truncated---(CVE-2024-56635)

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

bpf: fix recursive lock when verdict program return SK_PASS

When the streamverdict program returns SKPASS, it places the received skb into its own receive queue, but a recursive lock eventually occurs, leading to an operating system deadlock. This issue has been present since v6.9.

''' skpsockstrpdataready writelockbh(&sk->skcallbacklock) strpdataready strpreadsock readsock -> tcpreadsock strprecv cb.rcvmsg -> skpsockstrpread # now streamverdict return SKPASS without peer sock assign _SKPASS = skpsockmapverd(SKPASS, NULL) skpsockverdictapply skpsockskbingressself skpsockskbingressenqueue skpsockdataready readlockbh(&sk->skcallbacklock) <= dead lock

'''

This topic has been discussed before, but it has not been fixed. Previous discussion: https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch(CVE-2024-56694)

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

fs: relax assertions on failure to encode file handles

Encoding file handles is usually performed by a filesystem >encode_fh() method that may fail for various reasons.

The legacy users of exportfsencodefh(), namely, nfsd and nametohandle_at(2) syscall are ready to cope with the possibility of failure to encode a file handle.

There are a few other users of exportfsencode{fh,fid}() that currently have a WARNON() assertion when ->encodefh() fails. Relax those assertions because they are wrong.

The second linked bug report states commit 16aac5ad1fa9 ("ovl: support encoding non-decodable file handles") in v6.6 as the regressing commit, but this is not accurate.

The aforementioned commit only increases the chances of the assertion and allows triggering the assertion with the reproducer using overlayfs, inotify and drop_caches.

Triggering this assertion was always possible with other filesystems and other reasons of ->encodefh() failures and more particularly, it was also possible with the exact same reproducer using overlayfs that is mounted with options index=on,nfsexport=on also on kernels < v6.6. Therefore, I am not listing the aforementioned commit as a Fixes commit.

Backport hint: this patch will have a trivial conflict applying to v6.6.y, and other trivial conflicts applying to stable kernels < v6.6.(CVE-2024-57924)

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

hrtimers: Handle CPU state correctly on hotplug

Consider a scenario where a CPU transitions from CPUHPONLINE to halfway through a CPU hotunplug down to CPUHPHRTIMERSPREPARE, and then back to CPUHPONLINE:

Since hrtimerspreparecpu() does not run, cpubase.hresactive remains set to 1 throughout. However, during a CPU unplug operation, the tick and the clockevents are shut down at CPUHPAPTICKDYING. On return to the online state, for instance CFS incorrectly assumes that the hrtick is already active, and the chance of the clockevent device to transition to oneshot mode is also lost forever for the CPU, unless it goes back to a lower state than CPUHPHRTIMERS_PREPARE once.

This round-trip reveals another issue; cpubase.online is not set to 1 after the transition, which appears as a WARNONONCE in enqueuehrtimer().

Aside of that, the bulk of the per CPU state is not reset either, which means there are dangling pointers in the worst case.

Address this by adding a corresponding startup() callback, which resets the stale per CPU state and sets the online flag.

tglx: Make the new callback unconditionally available, remove the online modification in the prepare() callback and clear the remaining state in the starting callback instead of the prepare callback

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

media: uvcvideo: Fix double free in error path

If the uvcstatusinit() function fails to allocate the inturb, it will free the dev->status pointer but doesn't reset the pointer to NULL. This results in the kfree() call in uvcstatus_cleanup() trying to double-free the memory. Fix it by resetting the dev->status pointer to NULL after freeing it.

Reviewed by: Ricardo Ribalda <ribalda@chromium.org>(CVE-2024-57980)

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

tpm: Change to kvalloc() in eventlog/acpi.c

The following failure was reported on HPE ProLiant D320:

[ 10.693310][ T1] tpmtis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/pagealloc.c:4727 allocpagesnoprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:allocpagesnoprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0

The above transcript shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of _allocpagesnoprof(). Address the bug by moving from devmkmalloc() to devmaddaction() and kvmalloc() and devmaddaction().(CVE-2024-58005)

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

HID: multitouch: Add NULL check in mtinputconfigured

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

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

usb: gadget: f_tcm: Don't free command immediately

Don't prematurely free the command. Wait for the status completion of the sense status. It can be freed then. Otherwise we will double-free the command.(CVE-2024-58055)

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

ASoC: soc-pcm: don't use socpcmret() on .prepare callback

commit 1f5664351410 ("ASoC: lower "no backend DAIs enabled for ... Port" log severity") ignores -EINVAL error message on common socpcmret(). It is used from many functions, ignoring -EINVAL is over-kill.

The reason why -EINVAL was ignored was it really should only be used upon invalid parameters coming from userspace and in that case we don't want to log an error since we do not want to give userspace a way to do a denial-of-service attack on the syslog / diskspace.

So don't use socpcmret() on .prepare callback is better idea.(CVE-2024-58077)

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

misc: miscminoralloc to use ida for all dynamic/misc dynamic minors

miscminoralloc was allocating id using ida for minor only in case of MISCDYNAMICMINOR but miscminorfree was always freeing ids using idafree causing a mismatch and following warn: > > WARNING: CPU: 0 PID: 159 at lib/idr.c:525 idafree+0x3e0/0x41f > > idafree called for id=127 which is not allocated. > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ... > > [<60941eb4>] idafree+0x3e0/0x41f > > [<605ac993>] miscminorfree+0x3e/0xbc > > [<605acb82>] misc_deregister+0x171/0x1b3

miscminoralloc is changed to allocate id from ida for all minors falling in the range of dynamic/ misc dynamic minors(CVE-2024-58078)

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

smb: client: fix double free of TCPServerInfo::hostname

When shutting down the server in cifsputtcp_session(), cifsd thread might be reconnecting to multiple DFS targets before it realizes it should exit the loop, so @server->hostname can't be freed as long as cifsd thread isn't done. Otherwise the following can happen:

RIP: 0010:_slabfree+0x223/0x3c0 Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <0f> 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80 RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246 RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068 RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400 RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000 R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500 R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068 FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000) 000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4: PKRU: 55555554 Call Trace: <TASK> ? showtraceloglvl+0x1c4/0x2df ? showtraceloglvl+0x1c4/0x2df ? _reconnecttargetunlocked+0x3e/0x160 [cifs] ? _diebody.cold+0x8/0xd ? die+0x2b/0x50 ? dotrap+0xce/0x120 ? _slabfree+0x223/0x3c0 ? doerrortrap+0x65/0x80 ? _slabfree+0x223/0x3c0 ? excinvalidop+0x4e/0x70 ? _slabfree+0x223/0x3c0 ? asmexcinvalidop+0x16/0x20 ? _slabfree+0x223/0x3c0 ? extracthostname+0x5c/0xa0 [cifs] ? extracthostname+0x5c/0xa0 [cifs] ? _kmalloc+0x4b/0x140 _reconnecttargetunlocked+0x3e/0x160 [cifs] reconnectdfsserver+0x145/0x430 [cifs] cifshandlestandard+0x1ad/0x1d0 [cifs] cifsdemultiplexthread+0x592/0x730 [cifs] ? _pfxcifsdemultiplexthread+0x10/0x10 [cifs] kthread+0xdd/0x100 ? _pfxkthread+0x10/0x10 retfrom_fork+0x29/0x50 </TASK>(CVE-2025-21673)

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

net/mlx5e: Fix inversion dependency warning while enabling IPsec tunnel

Attempt to enable IPsec packet offload in tunnel mode in debug kernel generates the following kernel panic, which is happening due to two issues: 1. In SA add section, the should be bh() variant when marking SA mode. 2. There is not needed flushworkqueue in SA delete routine. It is not needed as at this stage as it is removed from SADB and the running work will be canceled later in SA free.

===================================================== WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected 6.12.0+ #4 Not tainted

charon/1337 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire: ffff88810f365020 (&xa->xalock#24){+.+.}-{3:3}, at: mlx5exfrmdelstate+0xca/0x1e0 [mlx5_core]

and this task is already holding: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrmstatedelete+0x16/0x30 which would create a new lock dependency: (&x->lock){+.-.}-{3:3} -> (&xa->xa_lock#24){+.+.}-{3:3}

but this new dependency connects a SOFTIRQ-irq-safe lock: (&x->lock){+.-.}-{3:3}

... which became SOFTIRQ-irq-safe at: lockacquire+0x1be/0x520 _rawspinlockbh+0x34/0x40 xfrmtimerhandler+0x91/0xd70 _hrtimerrunqueues+0x1dd/0xa60 hrtimerrunsoftirq+0x146/0x2e0 handlesoftirqs+0x266/0x860 irqexitrcu+0x115/0x1a0 sysvecapictimerinterrupt+0x6e/0x90 asmsysvecapictimerinterrupt+0x16/0x20 defaultidle+0x13/0x20 defaultidlecall+0x67/0xa0 doidle+0x2da/0x320 cpustartupentry+0x50/0x60 startsecondary+0x213/0x2a0 commonstartup64+0x129/0x138

to a SOFTIRQ-irq-unsafe lock: (&xa->xa_lock#24){+.+.}-{3:3}

... which became SOFTIRQ-irq-unsafe at: ... lockacquire+0x1be/0x520 _rawspinlock+0x2c/0x40 xasetmark+0x70/0x110 mlx5exfrmaddstate+0xe48/0x2290 [mlx5core] xfrmdevstateadd+0x3bb/0xd70 xfrmaddsa+0x2451/0x4a90 xfrmuserrcvmsg+0x493/0x880 netlinkrcvskb+0x12e/0x380 xfrmnetlinkrcv+0x6d/0x90 netlinkunicast+0x42f/0x740 netlinksendmsg+0x745/0xbe0 _socksendmsg+0xc5/0x190 _syssendto+0x1fe/0x2c0 _x64syssendto+0xdc/0x1b0 dosyscall64+0x6d/0x140 entrySYSCALL64afterhwframe+0x4b/0x53

other info that might help us debug this:

Possible interrupt unsafe locking scenario:

    CPU0                    CPU1
    ----                    ----

lock(&xa->xalock#24); localirqdisable(); lock(&x->lock); lock(&xa->xalock#24); <Interrupt> lock(&x->lock);

* DEADLOCK *

2 locks held by charon/1337: #0: ffffffff87f8f858 (&net->xfrm.xfrmcfgmutex){+.+.}-{4:4}, at: xfrmnetlinkrcv+0x5e/0x90 #1: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrmstatedelete+0x16/0x30

the dependencies between SOFTIRQ-irq-safe lock and the holding lock: -> (&x->lock){+.-.}-{3:3} ops: 29 { HARDIRQ-ON-W at: lockacquire+0x1be/0x520 _rawspinlockbh+0x34/0x40 xfrmallocspi+0xc0/0xe60 xfrmallocuserspi+0x5f6/0xbc0 xfrmuserrcvmsg+0x493/0x880 netlinkrcvskb+0x12e/0x380 xfrmnetlinkrcv+0x6d/0x90 netlinkunicast+0x42f/0x740 netlinksendmsg+0x745/0xbe0 _socksendmsg+0xc5/0x190 _syssendto+0x1fe/0x2c0 _x64syssendto+0xdc/0x1b0 dosyscall64+0x6d/0x140 entrySYSCALL64afterhwframe+0x4b/0x53 IN-SOFTIRQ-W at: lockacquire+0x1be/0x520 _rawspinlockbh+0x34/0x40 xfrmtimerhandler+0x91/0xd70 _hrtimerrun_queues+0x1dd/0xa60

---truncated---(CVE-2025-21674)

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

pktgen: Avoid out-of-bounds access in getimixentries

Passing a sufficient amount of imix entries leads to invalid access to the pktdev->imixentries array because of the incorrect boundary check.

UBSAN: array-index-out-of-bounds in net/core/pktgen.c:874:24 index 20 is out of range for type 'imixpkt [20]' CPU: 2 PID: 1210 Comm: bash Not tainted 6.10.0-rc1 #121 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dumpstacklvl lib/dumpstack.c:117 _ubsanhandleoutofbounds lib/ubsan.c:429 getimixentries net/core/pktgen.c:874 pktgenifwrite net/core/pktgen.c:1063 pdewrite fs/proc/inode.c:334 procregwrite fs/proc/inode.c:346 vfswrite fs/readwrite.c:593 ksyswrite fs/readwrite.c:644 dosyscall64 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe arch/x86/entry/entry_64.S:130

Found by Linux Verification Center (linuxtesting.org) with SVACE.

fp: allow to fill the array completely; minor changelog cleanup

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

openvswitch: fix lockup on tx to unregistering netdev with carrier

Commit in a fixes tag attempted to fix the issue in the following sequence of calls:

do_output
-> ovs_vport_send
   -> dev_queue_xmit
      -> __dev_queue_xmit
         -> netdev_core_pick_tx
            -> skb_tx_hash

When device is unregistering, the 'dev->realnumtxqueues' goes to zero and the 'while (unlikely(hash >= qcount))' loop inside the 'skbtx_hash' becomes infinite, locking up the core forever.

But unfortunately, checking just the carrier status is not enough to fix the issue, because some devices may still be in unregistering state while reporting carrier status OK.

One example of such device is a net/dummy. It sets carrier ON on start, but it doesn't implement .ndostop to set the carrier off. And it makes sense, because dummy doesn't really have a carrier. Therefore, while this device is unregistering, it's still easy to hit the infinite loop in the skbtx_hash() from the OVS datapath. There might be other drivers that do the same, but dummy by itself is important for the OVS ecosystem, because it is frequently used as a packet sink for tcpdump while debugging OVS deployments. And when the issue is hit, the only way to recover is to reboot.

Fix that by also checking if the device is running. The running state is handled by the net core during unregistering, so it covers unregistering case better, and we don't really need to send packets to devices that are not running anyway.

While only checking the running state might be enough, the carrier check is preserved. The running and the carrier states seem disjoined throughout the code and different drivers. And other core functions like _devdirect_xmit() check both before attempting to transmit a packet. So, it seems safer to check both flags in OVS as well.(CVE-2025-21681)

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

bpf: Fix bpfskselect_reuseport() memory leak

As pointed out in the original comment, lookup in sockmap can return a TCP ESTABLISHED socket. Such TCP socket may have had SOATTACHREUSEPORTEBPF set before it was ESTABLISHED. In other words, a non-NULL skreuseport_cb does not imply a non-refcounted socket.

Drop sk's reference in both error paths.

unreferenced object 0xffff888101911800 (size 2048): comm "testprogs", pid 44109, jiffies 4297131437 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 9336483b): _kmallocnoprof+0x3bf/0x560 _reuseportalloc+0x1d/0x40 reuseportalloc+0xca/0x150 reuseportattachprog+0x87/0x140 skreuseportattachbpf+0xc8/0x100 sksetsockopt+0x1181/0x1990 dosocksetsockopt+0x12b/0x160 _syssetsockopt+0x7b/0xc0 _x64syssetsockopt+0x1b/0x30 dosyscall64+0x93/0x180 entrySYSCALL64after_hwframe+0x76/0x7e(CVE-2025-21683)

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

cachestat: fix page cache statistics permission checking

When the 'cachestat()' system call was added in commit cf264e1329fb ("cachestat: implement cachestat syscall"), it was meant to be a much more convenient (and performant) version of mincore() that didn't need mapping things into the user virtual address space in order to work.

But it ended up missing the "check for writability or ownership" fix for mincore(), done in commit 134fca9063ad ("mm/mincore.c: make mincore() more conservative").

This just adds equivalent logic to 'cachestat()', modified for the file context (rather than vma).(CVE-2025-21691)

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

net: rose: fix timer races against user threads

Rose timers only acquire the socket spinlock, without checking if the socket is owned by one user thread.

Add a check and rearm the timers if needed.

BUG: KASAN: slab-use-after-free in rosetimerexpiry+0x31d/0x360 net/rose/rose_timer.c:174 Read of size 2 at addr ffff88802f09b82a by task swapper/0/0

CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0x169/0x550 mm/kasan/report.c:489 kasanreport+0x143/0x180 mm/kasan/report.c:602 rosetimerexpiry+0x31d/0x360 net/rose/rosetimer.c:174 calltimerfn+0x187/0x650 kernel/time/timer.c:1793 expiretimers kernel/time/timer.c:1844 [inline] _runtimers kernel/time/timer.c:2418 [inline] _runtimerbase+0x66a/0x8e0 kernel/time/timer.c:2430 runtimerbase kernel/time/timer.c:2439 [inline] runtimersoftirq+0xb7/0x170 kernel/time/timer.c:2449 handlesoftirqs+0x2d4/0x9b0 kernel/softirq.c:561 _dosoftirq kernel/softirq.c:595 [inline] invokesoftirq kernel/softirq.c:435 [inline] _irqexitrcu+0xf7/0x220 kernel/softirq.c:662 irqexitrcu+0x9/0x30 kernel/softirq.c:678 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvecapictimer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049 </IRQ>(CVE-2025-21718)

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

nilfs2: do not force clear folio if buffer is referenced

Patch series "nilfs2: protect busy buffer heads from being force-cleared".

This series fixes the buffer head state inconsistency issues reported by syzbot that occurs when the filesystem is corrupted and falls back to read-only, and the associated buffer head use-after-free issue.

This patch (of 2):

Syzbot has reported that after nilfs2 detects filesystem corruption and falls back to read-only, inconsistencies in the buffer state may occur.

One of the inconsistencies is that when nilfs2 calls markbufferdirty() to set a data or metadata buffer as dirty, but it detects that the buffer is not in the uptodate state:

WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 markbufferdirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: <TASK> nilfspalloccommitallocentry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfsifilecreateinode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfsnewinode+0x254/0x830 fs/nilfs2/inode.c:344 nilfsmkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfsmkdir+0x2f9/0x4f0 fs/namei.c:4257 domkdirat+0x264/0x3a0 fs/namei.c:4280 _dosysmkdirat fs/namei.c:4295 [inline] _sesysmkdirat fs/namei.c:4293 [inline] _x64sysmkdirat+0x87/0xa0 fs/namei.c:4293 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

The other is when nilfsbtreepropagate(), which propagates the dirty state to the ancestor nodes of a b-tree that point to a dirty buffer, detects that the origin buffer is not dirty, even though it should be:

WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfsbtreepropagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: <TASK> nilfsbmappropagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfscollectfiledata+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfssegctorapplybuffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfssegctorscanfile+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfssegctorcollectblocks fs/nilfs2/segment.c:1216 [inline] nilfssegctorcollect fs/nilfs2/segment.c:1540 [inline] nilfssegctordoconstruct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfssegctorconstruct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfssegctorthreadconstruct fs/nilfs2/segment.c:2587 [inline] nilfssegctorthread+0x69e/0xe80 fs/nilfs2/segment.c:2701 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244 </TASK>

Both of these issues are caused by the callbacks that handle the page/folio write requests, forcibly clear various states, including the working state of the buffers they hold, at unexpected times when they detect read-only fallback.

Fix these issues by checking if the buffer is referenced before clearing the page/folio state, and skipping the clear if it is.(CVE-2025-21722)

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

misc: fastrpc: Fix copy buffer page size

For non-registered buffer, fastrpc driver copies the buffer and pass it to the remote subsystem. There is a problem with current implementation of page size calculation which is not considering the offset in the calculation. This might lead to passing of improper and out-of-bounds page size which could result in memory issue. Calculate page start and page end using the offset adjusted address instead of absolute address.(CVE-2025-21734)

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

ata: libata-sff: Ensure that we cannot write outside the allocated buffer

reveliofuzzing reported that a SCSIIOCTLSENDCOMMAND ioctl with outlen set to 0xd42, SCSI command set to ATA16 PASS-THROUGH, ATA command set to ATANOP, and protocol set to ATAPROTPIO, can cause atapiosector() to write outside the allocated buffer, overwriting random memory.

While a ATA device is supposed to abort a ATANOP command, there does seem to be a bug either in libata-sff or QEMU, where either this status is not set, or the status is cleared before read by atasffhsmmove(). Anyway, that is most likely a separate bug.

Looking at _atapipiobytes(), it already has a safety check to ensure that _atapipiobytes() cannot write outside the allocated buffer.

Add a similar check to atapiosector(), such that also atapiosector() cannot write outside the allocated buffer.(CVE-2025-21738)

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

btrfs: fix assertion failure when splitting ordered extent after transaction abort

If while we are doing a direct IO write a transaction abort happens, we mark all existing ordered extents with the BTRFSORDEREDIOERR flag (done at btrfsdestroyorderedextents()), and then after that if we enter btrfssplitorderedextent() and the ordered extent has bytes left (meaning we have a bio that doesn't cover the whole ordered extent, see details at btrfsextractorderedextent()), we will fail on the following assertion at btrfssplitorderedextent():

ASSERT(!(flags & ~BTRFSORDEREDTYPE_FLAGS));

because the BTRFSORDEREDIOERR flag is set and the definition of BTRFSORDEREDTYPE_FLAGS is just the union of all flags that identify the type of write (regular, nocow, prealloc, compressed, direct IO, encoded).

Fix this by returning an error from btrfsextractorderedextent() if we find the BTRFSORDERED_IOERR flag in the ordered extent. The error will be the error that resulted in the transaction abort or -EIO if no transaction abort happened.

This was recently reported by syzbot with the following trace:

FAULTINJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 CPU: 0 UID: 0 PID: 5321 Comm: syz.0.0 Not tainted 6.13.0-rc5-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 faildump lib/fault-inject.c:53 [inline] shouldfailex+0x3b0/0x4e0 lib/fault-inject.c:154 shouldfailslab+0xac/0x100 mm/failslab.c:46 slabpreallochook mm/slub.c:4072 [inline] slaballocnode mm/slub.c:4148 [inline] _dokmallocnode mm/slub.c:4297 [inline] _kmallocnoprof+0xdd/0x4c0 mm/slub.c:4310 kmallocnoprof include/linux/slab.h:905 [inline] kzallocnoprof include/linux/slab.h:1037 [inline] btrfschunkallocaddchunkitem+0x244/0x1100 fs/btrfs/volumes.c:5742 reservechunkspace+0x1ca/0x2c0 fs/btrfs/block-group.c:4292 checksystemchunk fs/btrfs/block-group.c:4319 [inline] dochunkalloc fs/btrfs/block-group.c:3891 [inline] btrfschunkalloc+0x77b/0xf80 fs/btrfs/block-group.c:4187 findfreeextentupdateloop fs/btrfs/extent-tree.c:4166 [inline] findfreeextent+0x42d1/0x5810 fs/btrfs/extent-tree.c:4579 btrfsreserveextent+0x422/0x810 fs/btrfs/extent-tree.c:4672 btrfsnewextentdirect fs/btrfs/direct-io.c:186 [inline] btrfsgetblocksdirectwrite+0x706/0xfa0 fs/btrfs/direct-io.c:321 btrfsdioiomapbegin+0xbb7/0x1180 fs/btrfs/direct-io.c:525 iomapiter+0x697/0xf60 fs/iomap/iter.c:90 _iomapdiorw+0xeb9/0x25b0 fs/iomap/direct-io.c:702 btrfsdiowrite fs/btrfs/direct-io.c:775 [inline] btrfsdirectwrite+0x610/0xa30 fs/btrfs/direct-io.c:880 btrfsdowriteiter+0x2a0/0x760 fs/btrfs/file.c:1397 doiterreadvwritev+0x600/0x880 vfswritev+0x376/0xba0 fs/readwrite.c:1050 dopwritev fs/readwrite.c:1146 [inline] _dosyspwritev2 fs/readwrite.c:1204 [inline] _sesyspwritev2+0x196/0x2b0 fs/readwrite.c:1195 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f1281f85d29 RSP: 002b:00007f12819fe038 EFLAGS: 00000246 ORIG_RAX: 0000000000000148 RAX: ffffffffffffffda RBX: 00007f1282176080 RCX: 00007f1281f85d29 RDX: 0000000000000001 RSI: 0000000020000240 RDI: 0000000000000005 RBP: 00007f12819fe090 R08: 0000000000000000 R09: 0000000000000003 R10: 0000000000007000 R11: 0000000000000246 R12: 0000000000000002 R13: 0000000000000000 R14: 00007f1282176080 R15: 00007ffcb9e23328 </TASK> BTRFS error (device loop0 state A): Transaction aborted (error -12) BTRFS: error (device loop0 state A ---truncated---(CVE-2025-21754)

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

vsock: Keep the binding until socket destruction

Preserve sockets bindings; this includes both resulting from an explicit bind() and those implicitly bound through autobind during connect().

Prevents socket unbinding during a transport reassignment, which fixes a use-after-free:

1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)
2. transport->release() calls vsock_remove_bound() without checking if
   sk was bound and moved to bound list (refcnt=1)
3. vsock_bind() assumes sk is in unbound list and before
   __vsock_insert_bound(vsock_bound_sockets()) calls
   __vsock_remove_bound() which does:
       list_del_init(&vsk->bound_table); // nop
       sock_put(&vsk->sk);               // refcnt=0

BUG: KASAN: slab-use-after-free in _vsockbind+0x62e/0x730 Read of size 4 at addr ffff88816b46a74c by task a.out/2057 dumpstacklvl+0x68/0x90 printreport+0x174/0x4f6 kasanreport+0xb9/0x190 _vsockbind+0x62e/0x730 vsockbind+0x97/0xe0 _sysbind+0x154/0x1f0 _x64sysbind+0x6e/0xb0 dosyscall64+0x93/0x1b0 entrySYSCALL64afterhwframe+0x76/0x7e

Allocated by task 2057: kasansavestack+0x1e/0x40 kasansavetrack+0x10/0x30 _kasanslaballoc+0x85/0x90 kmemcacheallocnoprof+0x131/0x450 skprotalloc+0x5b/0x220 skalloc+0x2c/0x870 _vsockcreate.constprop.0+0x2e/0xb60 vsockcreate+0xe4/0x420 _sockcreate+0x241/0x650 _syssocket+0xf2/0x1a0 _x64syssocket+0x6e/0xb0 dosyscall64+0x93/0x1b0 entrySYSCALL64after_hwframe+0x76/0x7e

Freed by task 2057: kasansavestack+0x1e/0x40 kasansavetrack+0x10/0x30 kasansavefreeinfo+0x37/0x60 _kasanslabfree+0x4b/0x70 kmemcachefree+0x1a1/0x590 _skdestruct+0x388/0x5a0 _vsockbind+0x5e1/0x730 vsockbind+0x97/0xe0 _sysbind+0x154/0x1f0 _x64sysbind+0x6e/0xb0 dosyscall64+0x93/0x1b0 entrySYSCALL64afterhwframe+0x76/0x7e

refcountt: addition on 0; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcountwarnsaturate+0xce/0x150 RIP: 0010:refcountwarnsaturate+0xce/0x150 _vsockbind+0x66d/0x730 vsockbind+0x97/0xe0 _sysbind+0x154/0x1f0 _x64sysbind+0x6e/0xb0 dosyscall64+0x93/0x1b0 entrySYSCALL64after_hwframe+0x76/0x7e

refcountt: underflow; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcountwarnsaturate+0xee/0x150 RIP: 0010:refcountwarnsaturate+0xee/0x150 vsockremovebound+0x187/0x1e0 _vsockrelease+0x383/0x4a0 vsockrelease+0x90/0x120 _sockrelease+0xa3/0x250 sockclose+0x14/0x20 _fput+0x359/0xa80 taskworkrun+0x107/0x1d0 doexit+0x847/0x2560 dogroupexit+0xb8/0x250 _x64sysexitgroup+0x3a/0x50 x64syscall+0xfec/0x14f0 dosyscall64+0x93/0x1b0 entrySYSCALL64after_hwframe+0x76/0x7e(CVE-2025-21756)

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

arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array

The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level).(CVE-2025-21785)

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

team: better TEAMOPTIONTYPE_STRING validation

syzbot reported following splat [1]

Make sure user-provided data contains one nul byte.

[1] BUG: KMSAN: uninit-value in stringnocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 stringnocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 requestmodule+0x252/0x9f0 kernel/module/kmod.c:149 teammodeget drivers/net/team/teamcore.c:480 [inline] teamchangemode drivers/net/team/teamcore.c:607 [inline] teammodeoptionset+0x437/0x970 drivers/net/team/teamcore.c:1401 teamoptionset drivers/net/team/teamcore.c:375 [inline] teamnloptionssetdoit+0x1339/0x1f90 drivers/net/team/teamcore.c:2662 genlfamilyrcvmsgdoit net/netlink/genetlink.c:1115 [inline] genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlinkrcvskb+0x375/0x650 net/netlink/afnetlink.c:2543 genlrcv+0x40/0x60 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1322 [inline] netlinkunicast+0xf52/0x1260 net/netlink/afnetlink.c:1348 netlinksendmsg+0x10da/0x11e0 net/netlink/afnetlink.c:1892 socksendmsgnosec net/socket.c:718 [inline] _socksendmsg+0x30f/0x380 net/socket.c:733 _syssendmsg+0x877/0xb60 net/socket.c:2573 _syssendmsg+0x28d/0x3c0 net/socket.c:2627 _syssendmsg net/socket.c:2659 [inline] _dosyssendmsg net/socket.c:2664 [inline] _sesyssendmsg net/socket.c:2662 [inline] _x64syssendmsg+0x212/0x3c0 net/socket.c:2662 x64syscall+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls64.h:47 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f(CVE-2025-21787)

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

vrf: use RCU protection in l3mdevl3out()

l3mdevl3out() can be called without RCU being held:

rawsendmsg() ippushpendingframes() ipsendskb() iplocalout() _iplocalout() l3mdevip_out()

Add rcureadlock() / rcureadunlock() pair to avoid a potential UAF.(CVE-2025-21791)

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

hrtimers: Force migrate away hrtimers queued after CPUHPAPHRTIMERS_DYING

hrtimers are migrated away from the dying CPU to any online target at the CPUHPAPHRTIMERS_DYING stage in order not to delay bandwidth timers handling tasks involved in the CPU hotplug forward progress.

However wakeups can still be performed by the outgoing CPU after CPUHPAPHRTIMERS_DYING. Those can result again in bandwidth timers being armed. Depending on several considerations (crystal ball power management based election, earliest timer already enqueued, timer migration enabled or not), the target may eventually be the current CPU even if offline. If that happens, the timer is eventually ignored.

The most notable example is RCU which had to deal with each and every of those wake-ups by deferring them to an online CPU, along with related workarounds:

_ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying) _ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU) _ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)

The problem isn't confined to RCU though as the stop machine kthread (which runs CPUHPAPHRTIMERSDYING) reports its completion at the end of its work through cpustopsignaldone() and performs a wake up that eventually arms the deadline server timer:

WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimerstartrangens+0x289/0x2d0 CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted Stopper: multicpustop+0x0/0x120 <- stopmachinecpuslocked+0x66/0xc0 RIP: 0010:hrtimerstartrangens+0x289/0x2d0 Call Trace: <TASK> startdltimer enqueuedlentity dlserverstart enqueuetaskfair enqueuetask ttwudoactivate trytowakeup complete cpustopperthread

Instead of providing yet another bandaid to work around the situation, fix it in the hrtimers infrastructure instead: always migrate away a timer to an online target whenever it is enqueued from an offline CPU.

This will also allow to revert all the above RCU disgraceful hacks.(CVE-2025-21816)

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

tty: xilinx_uartps: split sysrq handling

lockdep detects the following circular locking dependency:

CPU 0 CPU 1 ========================== ============================ cdnsuartisr() printk() uartportlock(port) consolelock() cdnsuartconsolewrite() if (!port->sysrq) uartportlock(port) uarthandlebreak() port->sysrq = ... uarthandlesysrqchar() printk() consolelock()

The fixed commit attempts to avoid this situation by only taking the port lock in cdnsuartconsolewrite if port->sysrq unset. However, if (as shown above) cdnsuartconsolewrite runs before port->sysrq is set, then it will try to take the port lock anyway. This may result in a deadlock.

Fix this by splitting sysrq handling into two parts. We use the prepare helper under the port lock and defer handling until we release the lock.(CVE-2025-21820)

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

batman-adv: Drop unmanaged ELP metric worker

The ELP worker needs to calculate new metric values for all neighbors "reachable" over an interface. Some of the used metric sources require locks which might need to sleep. This sleep is incompatible with the RCU list iterator used for the recorded neighbors. The initial approach to work around of this problem was to queue another work item per neighbor and then run this in a new context.

Even when this solved the RCU vs might_sleep() conflict, it has a major problems: Nothing was stopping the work item in case it is not needed anymore - for example because one of the related interfaces was removed or the batman-adv module was unloaded - resulting in potential invalid memory accesses.

Directly canceling the metric worker also has various problems:

• cancelworksync for a to-be-deactivated interface is called with rtnllock held. But the code in the ELP metric worker also tries to use rtnllock() - which will never return in this case. This also means that cancelworksync would never return because it is waiting for the worker to finish.
• iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must "stop" all still running workers)

The better approch is to get rid of the per interface neighbor metric worker and handle everything in the interface worker. The original problems are solved by:

• creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context
• only use rcutrylock inside metric gathering code to avoid a deadlock when the canceldelayedworksync is called in the interface removal code (which is called with the rtnl_lock held)(CVE-2025-21823)

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

block: don't revert iter for -EIOCBQUEUED

blkdevreaditer() has a few odd checks, like gating the position and count adjustment on whether or not the result is bigger-than-or-equal to zero (where bigger than makes more sense), and not checking the return value of blkdevdirectIO() before doing an ioviterrevert(). The latter can lead to attempting to revert with a negative value, which when passed to ioviterrevert() as an unsigned value will lead to throwing a WARNON() because unroll is bigger than MAXRW_COUNT.

Be sane and don't revert for -EIOCBQUEUED, like what is done in other spots.(CVE-2025-21832)

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

smb: client: Add check for nextbuffer in receiveencrypted_standard()

Add check for the return value of cifsbufget() and cifssmallbufget() in receiveencrypted_standard() to prevent null pointer dereference.(CVE-2025-21844)

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

acct: perform last write from workqueue

In [1] it was reported that the acct(2) system call can be used to trigger NULL deref in cases where it is set to write to a file that triggers an internal lookup. This can e.g., happen when pointing acc(2) to /sys/power/resume. At the point the where the write to this file happens the calling task has already exited and called exit_fs(). A lookup will thus trigger a NULL-deref when accessing current->fs.

Reorganize the code so that the the final write happens from the workqueue but with the caller's credentials. This preserves the (strange) permission model and has almost no regression risk.

This api should stop to exist though.(CVE-2025-21846)

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

s390/ism: add release function for struct device

According to device_release() in /drivers/base/core.c, a device without a release function is a broken device and must be fixed.

The current code directly frees the device after calling device_add() without waiting for other kernel parts to release their references. Thus, a reference could still be held to a struct device, e.g., by sysfs, leading to potential use-after-free issues if a proper release function is not set.(CVE-2025-21856)

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

io_uring: prevent opcode speculation

sqe->opcode is used for different tables, make sure we santitise it against speculations.(CVE-2025-21863)

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

ovl: fix UAF in ovldentryupdatereval by moving dput() in ovllink_up

The issue was caused by dput(upper) being called before ovldentryupdatereval(), while upper->dflags was still accessed in ovldentryremote().

Move dput(upper) after its last use to prevent use-after-free.

BUG: KASAN: slab-use-after-free in ovldentryremote fs/overlayfs/util.c:162 [inline] BUG: KASAN: slab-use-after-free in ovldentryupdate_reval+0xd2/0xf0 fs/overlayfs/util.c:167

Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:114 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc3/0x620 mm/kasan/report.c:488 kasanreport+0xd9/0x110 mm/kasan/report.c:601 ovldentryremote fs/overlayfs/util.c:162 [inline] ovldentryupdatereval+0xd2/0xf0 fs/overlayfs/util.c:167 ovllinkup fs/overlayfs/copyup.c:610 [inline] ovlcopyupone+0x2105/0x3490 fs/overlayfs/copyup.c:1170 ovlcopyupflags+0x18d/0x200 fs/overlayfs/copyup.c:1223 ovlrename+0x39e/0x18c0 fs/overlayfs/dir.c:1136 vfsrename+0xf84/0x20a0 fs/namei.c:4893 ... </TASK>(CVE-2025-21887)

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

perf/core: Add RCU read lock protection to perfiteratectx()

The perfiteratectx() function performs RCU list traversal but currently lacks RCU read lock protection. This causes lockdep warnings when running perf probe with unshare(1) under CONFIGPROVERCU_LIST=y:

WARNING: suspicious RCU usage
kernel/events/core.c:8168 RCU-list traversed in non-reader section!!

 Call Trace:
  lockdep_rcu_suspicious
  ? perf_event_addr_filters_apply
  perf_iterate_ctx
  perf_event_exec
  begin_new_exec
  ? load_elf_phdrs
  load_elf_binary
  ? lock_acquire
  ? find_held_lock
  ? bprm_execve
  bprm_execve
  do_execveat_common.isra.0
  __x64_sys_execve
  do_syscall_64
  entry_SYSCALL_64_after_hwframe

This protection was previously present but was removed in commit bd2756811766 ("perf: Rewrite core context handling"). Add back the necessary rcureadlock()/rcureadunlock() pair around perfiteratectx() call in perfeventexec().

mingo: Use scoped_guard() as suggested by Peter