OESA-2025-1285

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

IORINGOPREAD did not correctly consume the provided buffer list when read i/o returned < 0 (except for -EAGAIN and -EIOCBQUEUED return). This can lead to a potential use-after-free when the completion via iorwdone runs at separate context.(CVE-2023-52926)

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

NFS: Fix potential buffer overflowin nfssysfslinkrpcclient()

name is char[64] where the size of clnt->cl_program->name remains unknown. Invoking strcat() directly will also lead to potential buffer overflow. Change them to strscpy() and strncat() to fix potential issues.(CVE-2024-54456)

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

wifi: mac80211: fix mbss changed flags corruption on 32 bit systems

On 32-bit systems, the size of an unsigned long is 4 bytes, while a u64 is 8 bytes. Therefore, when using oreachsetbit(bit, &bits, sizeof(changed) * BITSPER_BYTE), the code is incorrectly searching for a bit in a 32-bit variable that is expected to be 64 bits in size, leading to incorrect bit finding.

Solution: Ensure that the size of the bits variable is correctly adjusted for each architecture.

Call Trace: ? showregs+0x54/0x58 ? _warn+0x6b/0xd4 ? ieee80211linkinfochangenotify+0xcc/0xd4 [mac80211] ? reportbug+0x113/0x150 ? excoverflow+0x30/0x30 ? handlebug+0x27/0x44 ? excinvalidop+0x18/0x50 ? handleexception+0xf6/0xf6 ? excoverflow+0x30/0x30 ? ieee80211linkinfochangenotify+0xcc/0xd4 [mac80211] ? excoverflow+0x30/0x30 ? ieee80211linkinfochangenotify+0xcc/0xd4 [mac80211] ? ieee80211meshwork+0xff/0x260 [mac80211] ? cfg80211wiphywork+0x72/0x98 [cfg80211] ? processonework+0xf1/0x1fc ? workerthread+0x2c0/0x3b4 ? kthread+0xc7/0xf0 ? moddelayedworkon+0x4c/0x4c ? kthreadcompleteandexit+0x14/0x14 ? retfromfork+0x24/0x38 ? kthreadcompleteandexit+0x14/0x14 ? retfromforkasm+0xf/0x14 ? entryINT80_32+0xf0/0xf0

restore no-op path for no changes

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

usb: xhci: Fix NULL pointer dereference on certain command aborts

If a command is queued to the final usable TRB of a ring segment, the enqueue pointer is advanced to the subsequent link TRB and no further. If the command is later aborted, when the abort completion is handled the dequeue pointer is advanced to the first TRB of the next segment.

If no further commands are queued, xhcihandlestoppedcmdring() sees the ring pointers unequal and assumes that there is a pending command, so it calls xhcimodcmdtimer() which crashes if curcmd was NULL.

Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell ring likely is unnecessary too, but it's harmless. Leave it alone.

This is probably Bug 219532, but no confirmation has been received.

The issue has been independently reproduced and confirmed fixed using a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever. Everything continued working normally after several prevented crashes.(CVE-2024-57981)

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

ocfs2: handle a symlink read error correctly

Patch series "Convert ocfs2 to use folios".

Mark did a conversion of ocfs2 to use folios and sent it to me as a giant patch for review ;-)

So I've redone it as individual patches, and credited Mark for the patches where his code is substantially the same. It's not a bad way to do it; his patch had some bugs and my patches had some bugs. Hopefully all our bugs were different from each other. And hopefully Mark likes all the changes I made to his code!

This patch (of 23):

If we can't read the buffer, be sure to unlock the page before returning.(CVE-2024-58001)

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

bpf: bpflocalstorage: Always use bpfmemalloc in PREEMPT_RT

In PREEMPTRT, kmalloc(GFPATOMIC) is still not safe in non preemptible context. bpfmemalloc must be used in PREEMPTRT. This patch is to enforce bpfmemalloc in the bpflocalstorage when CONFIGPREEMPT_RT is enabled.

[ 35.118559] BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 [ 35.118566] inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 1832, name: testprogs [ 35.118569] preemptcount: 1, expected: 0 [ 35.118571] RCU nest depth: 1, expected: 1 [ 35.118577] INFO: lockdep is turned off. ... [ 35.118647] mightresched+0x433/0x5b0 [ 35.118677] rtspinlock+0xc3/0x290 [ 35.118700] _slaballoc+0x72/0xc40 [ 35.118723] _kmallocnoprof+0x13f/0x4e0 [ 35.118732] bpfmapkzalloc+0xe5/0x220 [ 35.118740] bpfselemalloc+0x1d2/0x7b0 [ 35.118755] bpflocalstorageupdate+0x2fa/0x8b0 [ 35.118784] bpfskstoragegettracing+0x15a/0x1d0 [ 35.118791] bpfprog9a118d86fca78ebbtraceinetsocksetstate+0x44/0x66 [ 35.118795] bpftracerun3+0x222/0x400 [ 35.118820] _bpftraceinetsocksetstate+0x11/0x20 [ 35.118824] traceinetsocksetstate+0x112/0x130 [ 35.118830] inetskstatestore+0x41/0x90 [ 35.118836] tcpset_state+0x3b3/0x640

There is no need to adjust the gfpflags passing to the bpfmemcacheallocflags() which only honors the GFPKERNEL. The verifier has ensured GFP_KERNEL is passed only in sleepable context.

It has been an old issue since the first introduction of the bpflocalstorage ~5 years ago, so this patch targets the bpf-next.

bpfmemalloc is needed to solve it, so the Fixes tag is set to the commit when bpfmemalloc was first used in the bpflocalstorage.(CVE-2024-58070)

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

wifi: rtw89: fix race between cancelhwscan and hw_scan completion

The rtwdev->scanning flag isn't protected by mutex originally, so cancelhwscan can pass the condition, but suddenly hwscan completion unset the flag and calls ieee80211scancompleted() that will free local->hwscanreq. Then, cancelhw_scan raises null-ptr-deref and use-after-free. Fix it by moving the check condition to where protected by mutex.

KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] CPU: 2 PID: 6922 Comm: kworker/2:2 Tainted: G OE Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB6WW (2.76 ) 09/10/2019 Workqueue: events cfg80211connwork [cfg80211] RIP: 0010:rtw89fwh2cscanoffloadbe+0xc33/0x13c3 [rtw89core] Code: 00 45 89 6c 24 1c 0f 85 23 01 00 00 48 8b 85 20 ff ff ff 48 8d RSP: 0018:ffff88811fd9f068 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88811fd9f258 RCX: 0000000000000001 RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000089 RBP: ffff88811fd9f170 R08: 0000000000000000 R09: 0000000000000000 R10: ffff88811fd9f108 R11: 0000000000000000 R12: ffff88810e47f960 R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8881d6f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007531dfca55b0 CR3: 00000001be296004 CR4: 00000000001706e0 Call Trace: <TASK> ? showregs+0x61/0x73 ? diebody+0x20/0x73 ? dieaddr+0x4f/0x7b ? excgeneralprotection+0x191/0x1db ? asmexcgeneralprotection+0x27/0x30 ? rtw89fwh2cscanoffloadbe+0xc33/0x13c3 [rtw89core] ? rtw89fwh2cscanoffloadbe+0x458/0x13c3 [rtw89core] ? _pfxrtw89fwh2cscanoffloadbe+0x10/0x10 [rtw89core] ? dorawspinlock+0x75/0xdb ? _pfxdorawspinlock+0x10/0x10 rtw89hwscanoffload+0xb5e/0xbf7 [rtw89core] ? rawspinunlock+0xe/0x24 ? _mutexlock.constprop.0+0x40c/0x471 ? _pfxrtw89hwscanoffload+0x10/0x10 [rtw89core] ? _mutexlockslowpath+0x13/0x1f ? mutexlock+0xa2/0xdc ? _pfxmutexlock+0x10/0x10 rtw89hwscanabort+0x58/0xb7 [rtw89core] rtw89opscancelhwscan+0x120/0x13b [rtw89core] ieee80211scancancel+0x468/0x4d0 [mac80211] ieee80211prepconnection+0x858/0x899 [mac80211] ieee80211mgdauth+0xbea/0xdde [mac80211] ? _pfxieee80211mgdauth+0x10/0x10 [mac80211] ? cfg80211findelem+0x15/0x29 [cfg80211] ? isbss+0x1b7/0x1d7 [cfg80211] ieee80211auth+0x18/0x27 [mac80211] cfg80211mlmeauth+0x3bb/0x3e7 [cfg80211] cfg80211conndowork+0x410/0xb81 [cfg80211] ? _pfxcfg80211conndowork+0x10/0x10 [cfg80211] ? _kasancheckread+0x11/0x1f ? psigroupchange+0x8bc/0x944 ? _kasancheckwrite+0x14/0x22 ? mutexlock+0x8e/0xdc ? _pfxmutexlock+0x10/0x10 ? _pfxradixtreelookup+0x10/0x10 cfg80211connwork+0x245/0x34d [cfg80211] ? pfxcfg80211connwork+0x10/0x10 [cfg80211] ? updatecfsrqloadavg+0x3bc/0x3d7 ? schedclocknoinstr+0x9/0x1a ? schedclock+0x10/0x24 ? schedclockcpu+0x7e/0x42e ? newidlebalance+0x796/0x937 ? _pfxschedclockcpu+0x10/0x10 ? _pfxnewidlebalance+0x10/0x10 ? _kasancheckread+0x11/0x1f ? psigroupchange+0x8bc/0x944 ? rawspinunlock+0xe/0x24 ? rawspinrqunlock+0x47/0x54 ? rawspinrqunlockirq+0x9/0x1f ? finishtaskswitch.isra.0+0x347/0x586 ? _schedule+0x27bf/0x2892 ? mutexunlock+0x80/0xd0 ? dorawspinlock+0x75/0xdb ? _pfxschedule+0x10/0x10 processscheduledworks+0x58c/0x821 workerthread+0x4c7/0x586 ? _kasancheckread+0x11/0x1f kthread+0x285/0x294 ? _pfxworkerthread+0x10/0x10 ? _pfxkthread+0x10/0x10 retfromfork+0x29/0x6f ? _pfxkthread+0x10/0x10 retfromfork_asm+0x1b/0x30 </TASK>(CVE-2025-21729)

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

RDMA/mlx5: Fix a race for an ODP MR which leads to CQE with error

This patch addresses a race condition for an ODP MR that can result in a CQE with an error on the UMR QP.

During the _mlx5ibderegmr() flow, the following sequence of calls occurs:

mlx5revokemr() mlx5rumrrevokemr() mlx5rumrpostsend_wait()

At this point, the lkey is freed from the hardware's perspective.

However, concurrently, mlx5ibinvalidate_range() might be triggered by another task attempting to invalidate a range for the same freed lkey.

This task will: - Acquire the umemodp->umemmutex lock. - Call mlx5rumrupdate_xlt() on the UMR QP. - Since the lkey has already been freed, this can lead to a CQE error, causing the UMR QP to enter an error state [1].

To resolve this race condition, the umemodp->umemmutex lock is now also acquired as part of the mlx5revokemr() scope. Upon successful revoke, we set umem_odp->private which points to that MR to NULL, preventing any further invalidation attempts on its lkey.

[1] From dmesg:

infiniband rocep8s0f0: dumpcqe:277:(pid 0): WC error: 6, Message: memory bind operation error cqedump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqedump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqedump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2

WARNING: CPU: 15 PID: 1506 at drivers/infiniband/hw/mlx5/umr.c:394 mlx5rumrpostsendwait+0x15a/0x2b0 [mlx5ib] Modules linked in: ip6tablemangle ip6tablenatip6tablefilter ip6tables iptablemangle xtconntrack xtMASQUERADE nfconntracknetlink nfnetlink xtaddrtype iptablenat nfnat brnetfilter rpcsecgsskrb5 authrpcgss oidregistry overlay rpcrdma rdmaucm ibiser libiscsi scsitransportiscsi rdmacm iwcm ibumad ibipoib ibcm mlx5ib ibuverbs ibcore fuse mlx5core CPU: 15 UID: 0 PID: 1506 Comm: ibvrcpingpong Not tainted 6.12.0-rc7+ #1626 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5rumrpostsendwait+0x15a/0x2b0 [mlx5ib] [..] Call Trace: <TASK> mlx5rumrupdatexlt+0x23c/0x3e0 [mlx5ib] mlx5ibinvalidaterange+0x2e1/0x330 [mlx5ib] _mmunotifierinvalidaterangestart+0x1e1/0x240 zappagerangesingle+0xf1/0x1a0 madvisevmabehavior+0x677/0x6e0 domadvise+0x1a2/0x4b0 _x64sysmadvise+0x25/0x30 dosyscall64+0x6b/0x140 entrySYSCALL64afterhwframe+0x76/0x7e(CVE-2025-21732)

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

nilfs2: fix possible int overflows in nilfs_fiemap()

Since nilfsbmaplookupcontig() in nilfsfiemap() calculates its result by being prepared to go through potentially maxblocks == INT_MAX blocks, the value in n may experience an overflow caused by left shift of blkbits.

While it is extremely unlikely to occur, play it safe and cast right hand expression to wider type to mitigate the issue.

Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.(CVE-2025-21736)

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

usbnet: ipheth: fix possible overflow in DPE length check

Originally, it was possible for the DPE length check to overflow if wDatagramIndex + wDatagramLength > U16_MAX. This could lead to an OoB read.

Move the wDatagramIndex term to the other side of the inequality.

An existing condition ensures that wDatagramIndex < urb->actual_length.(CVE-2025-21743)

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

clocksource: Use migratedisable() to avoid calling getrandom_u32() in atomic context

The following bug report happened with a PREEMPT_RT kernel:

BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 2012, name: kwatchdog preemptcount: 1, expected: 0 RCU nest depth: 0, expected: 0 getrandomu32+0x4f/0x110 clocksourceverifychoosecpus+0xab/0x1a0 clocksourceverifypercpu.part.0+0x6b/0x330 clocksourcewatchdogkthread+0x193/0x1a0

It is due to the fact that clocksourceverifychoosecpus() is invoked with preemption disabled. This function invokes getrandomu32() to obtain random numbers for choosing CPUs. The batchedentropy32 local lock and/or the basecrng.lock spinlock in driver/char/random.c will be acquired during the call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot be acquired in atomic context.

Fix this problem by using migratedisable() to allow smpprocessorid() to be reliably used without introducing atomic context. preemptdisable() is then called after clocksourceverifychoose_cpus() but before the clocksource measurement is being run to avoid introducing unexpected latency.(CVE-2025-21767)

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

USB: hub: Ignore non-compliant devices with too many configs or interfaces

Robert Morris created a test program which can cause usbhubtostructhub() to dereference a NULL or inappropriate pointer:

Oops: general protection fault, probably for non-canonical address 0xcccccccccccccccc: 0000 [#1] SMP DEBUGPAGEALLOC PTI CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14 Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021 Workqueue: usbhubwq hubevent RIP: 0010:usbhubadjustdeviceremovable+0x78/0x110 ... Call Trace: <TASK> ? dieaddr+0x31/0x80 ? excgeneralprotection+0x1b4/0x3c0 ? asmexcgeneralprotection+0x26/0x30 ? usbhubadjustdeviceremovable+0x78/0x110 hubprobe+0x7c7/0xab0 usbprobeinterface+0x14b/0x350 reallyprobe+0xd0/0x2d0 ? pfxdeviceattachdriver+0x10/0x10 _driverprobedevice+0x6e/0x110 driverprobedevice+0x1a/0x90 _deviceattachdriver+0x7e/0xc0 busforeachdrv+0x7f/0xd0 _deviceattach+0xaa/0x1a0 busprobedevice+0x8b/0xa0 deviceadd+0x62e/0x810 usbsetconfiguration+0x65d/0x990 usbgenericdriverprobe+0x4b/0x70 usbprobedevice+0x36/0xd0

The cause of this error is that the device has two interfaces, and the hub driver binds to interface 1 instead of interface 0, which is where usbhubtostructhub() looks.

We can prevent the problem from occurring by refusing to accept hub devices that violate the USB spec by having more than one configuration or interface.(CVE-2025-21776)

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

orangefs: fix a oob in orangefsdebugwrite

I got a syzbot report: slab-out-of-bounds Read in orangefsdebugwrite... several people suggested fixes, I tested Al Viro's suggestion and made this patch.(CVE-2025-21782)

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

gpiolib: Fix crash on error in gpiochipgetngpios()

The gpiochipgetngpios() uses chip*() macros to print messages. However these macros rely on gpiodev to be initialised and set, which is not the case when called via bgpioinit(). In such a case the printing messages will crash on NULL pointer dereference. Replace chip*() macros by the respective dev*() ones to avoid such crash.(CVE-2025-21783)

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

LoongArch: csum: Fix OoB access in IP checksum code for negative lengths

Commit 69e3a6aa6be2 ("LoongArch: Add checksum optimization for 64-bit system") would cause an undefined shift and an out-of-bounds read.

Commit 8bd795fedb84 ("arm64: csum: Fix OoB access in IP checksum code for negative lengths") fixes the same issue on ARM64.(CVE-2025-21789)

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

NFSD: fix hang in nfsd4shutdowncallback

If nfs4client is in courtesy state then there is no point to send the callback. This causes nfsd4shutdowncallback to hang since clcb_inflight is not 0. This hang lasts about 15 minutes until TCP notifies NFSD that the connection was dropped.

This patch modifies nfsd4runcbwork to skip the RPC call if nfs4client is in courtesy state.(CVE-2025-21795)

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

nfsd: clear aclaccess/acldefault after releasing them

If getting acldefault fails, aclaccess and acldefault will be released simultaneously. However, aclaccess will still retain a pointer pointing to the released posixacl, which will trigger a WARNING in nfs3svcrelease_getacl like this:

------------[ cut here ]------------ refcountt: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcountwarnsaturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcountwarnsaturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS: 0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? refcountwarnsaturate+0xb5/0x170 ? _warn+0xa5/0x140 ? refcountwarnsaturate+0xb5/0x170 ? reportbug+0x1b1/0x1e0 ? handlebug+0x53/0xa0 ? excinvalidop+0x17/0x40 ? asmexcinvalidop+0x1a/0x20 ? ticknohztickstopped+0x1e/0x40 ? refcountwarnsaturate+0xb5/0x170 ? refcountwarnsaturate+0xb5/0x170 nfs3svcreleasegetacl+0xc9/0xe0 svcprocesscommon+0x5db/0xb60 ? _pfxsvcprocesscommon+0x10/0x10 ? _rcureadunlock+0x69/0xa0 ? _pfxnfsddispatch+0x10/0x10 ? svcxprtreceived+0xa1/0x120 ? xdrinitdecode+0x11d/0x190 svcprocess+0x2a7/0x330 svchandlexprt+0x69d/0x940 svcrecv+0x180/0x2d0 nfsd+0x168/0x200 ? _pfxnfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? _pfxkthread+0x10/0x10 retfromfork+0x34/0x60 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> Kernel panic - not syncing: kernel: panicon_warn set ...

Clear aclaccess/acldefault after posixaclrelease is called to prevent UAF from being triggered.(CVE-2025-21796)

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

ptp: Ensure info->enable callback is always set

The ioctl and sysfs handlers unconditionally call the ->enable callback. Not all drivers implement that callback, leading to NULL dereferences. Example of affected drivers: ptps390.c, ptpvclock.c and ptp_mock.c.

Instead use a dummy callback if no better was specified by the driver.(CVE-2025-21814)

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

block: mark GFP_NOIO around sysfs ->store()

sysfs ->store is called with queue freezed, meantime we have several ->store() callbacks(updatenrrequests, wbt, scheduler) to allocate memory with GFP_KERNEL which may run into direct reclaim code path, then potential deadlock can be caused.

Fix the issue by marking NOIO around sysfs ->store()(CVE-2025-21817)