OESA-2025-2554

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ext4: fix potential out of bound read in ext4fcreplay_scan()

For scan loop must ensure that at least EXT4FCTAGBASELEN space. If remain space less than EXT4FCTAGBASELEN which will lead to out of bound read when mounting corrupt file system image. ADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this three tags will read data during scan, tag length couldn't less than data length which will read.(CVE-2022-50306)

A use-after-free vulnerability in the Linux kernel s netfilter: nftables component can be exploited to achieve local privilege escalation.Due to a race condition between nftables netlink control plane transaction and nft_set element garbage collection, it is possible to underflow the reference counter causing a use-after-free vulnerability.We recommend upgrading past commit 3e91b0ebd994635df2346353322ac51ce84ce6d8.(CVE-2023-4244)

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

HID: multitouch: Correct devm device reference for hidinput input_dev name

Reference the HID device rather than the input device for the devm allocation of the inputdev name. Referencing the inputdev would lead to a use-after-free when the input_dev was unregistered and subsequently fires a uevent that depends on the name. At the point of firing the uevent, the name would be freed by devres management.

Use devmkasprintf to simplify the logic for allocating memory and formatting the inputdev name string.(CVE-2023-53454)

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

scsi: qla2xxx: Fix deletion race condition

System crash when using debug kernel due to link list corruption. The cause of the link list corruption is due to session deletion was allowed to queue up twice. Here's the internal trace that show the same port was allowed to double queue for deletion on different cpu.

20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4type 1 20808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4type 1

Move the clearing/setting of deleted flag lock.(CVE-2023-53615)

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

scsi: ses: Fix possible desc_ptr out-of-bounds accesses

Sanitize possible descptr out-of-bounds accesses in sesenclosuredataprocess().(CVE-2023-53675)

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

NFS: Fix a potential data corruption

We must ensure that the subrequests are joined back into the head before we can retransmit a request. If the head was not on the commit lists, because the server wrote it synchronously, we still need to add it back to the retransmission list. Add a call that mirrors the effect of nfscancelremoveinode() for ODIRECT.(CVE-2023-53711)

In the Linux kernel, the following vulnerability has been resolved: md: raid1: fix potential OOB in raid1removedisk(). If rddev->raiddisk is greater than mddev->raiddisks, there will be an out-of-bounds in raid1removedisk(). We have already found similar reports as follows: 1) commit d17f744e883b ("md-raid10: fix KASAN warning") 2) commit 1ebc2cec0b7d ("dm raid: fix KASAN warning in raid5removedisk"). Fix this bug by checking whether the "number" variable is valid.(CVE-2023-53722)

In the Linux kernel, the following vulnerability has been resolved:posix-timers: Ensure timer ID search-loop limit is validposixtimeradd() tries to allocate a posix timer ID by starting from thecached ID which was stored by the last successful allocation.This is done in a loop searching the ID space for a free slot one byone. The loop has to terminate when the search wrapped around to thestarting point.But that s racy vs. establishing the starting point. That is read outlockless, which leads to the following problem:CPU0 CPU1posixtimeradd() start = sig->posixtimerid; lock(hashlock); ... posixtimeradd() if (++sig->posixtimerid < 0) start = sig->posixtimerid; sig->posixtimerid = 0;So CPU1 can observe a negative start value, i.e. -1, and the loop breaknever happens because the condition can never be true: if (sig->posixtimerid == start) break;While this is unlikely to ever turn into an endless loop as the ID space ishuge (INTMAX), the racy read of the start value caught the attention ofKCSAN and Dmitry unearthed that incorrectness.Rewrite it so that all id operations are under the hash lock.(CVE-2023-53728)

In the Linux kernel, the following vulnerability has been resolved:posix-clock: posix-clock: Fix unbalanced locking in pcclocksettime()If getclockdesc() succeeds, it calls fget() for the clockid s fd,and get the clk->rwsem read lock, so the error path should releasethe lock to make the lock balance and fput the clockid s fd to makethe refcount balance and release the fd related resource.However the below commit left the error path locked behind resulting inunbalanced locking. Check timespec64validstrict() beforegetclockdesc() to fix it, because the ts is not changedafter that.pabeni@redhat.com: fixed commit message typo

In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcpwritetimerhandler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: <IRQ> dumpstacklvl+0x68/0xa0 printaddressdescription.constprop.0+0x2c/0x3d0 printreport+0xb4/0x270 kasanreport+0xbd/0xf0 tcpwritetimerhandler+0x156/0x3e0 tcpwritetimer+0x66/0x170 calltimerfn+0xfb/0x1d0 _runtimers+0x3f8/0x480 runtimersoftirq+0x9b/0x100 handlesoftirqs+0x153/0x390 _irqexitrcu+0x103/0x120 irqexitrcu+0xe/0x20 sysvecapictimerinterrupt+0x76/0x90 </IRQ> <TASK> asmsysvecapictimerinterrupt+0x1a/0x20RIP: 0010:defaultidle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 defaultidlecall+0x6b/0xa0 cpuidleidlecall+0x1af/0x1f0 doidle+0xbc/0x130 cpustartupentry+0x33/0x40 restinit+0x11f/0x210 startkernel+0x39a/0x420 x8664startreservations+0x18/0x30 x8664startkernel+0x97/0xa0 commonstartup64+0x13e/0x141 </TASK>Allocated by task 595: kasansavestack+0x24/0x50 kasansavetrack+0x14/0x30 _kasanslaballoc+0x87/0x90 kmemcacheallocnoprof+0x12b/0x3f0 copynetns+0x94/0x380 createnewnamespaces+0x24c/0x500 unsharensproxynamespaces+0x75/0xf0 ksysunshare+0x24e/0x4f0 _x64sysunshare+0x1f/0x30 dosyscall64+0x70/0x180 entrySYSCALL64afterhwframe+0x76/0x7eFreed by task 100: kasansavestack+0x24/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 _kasanslabfree+0x54/0x70 kmemcachefree+0x156/0x5d0 cleanupnet+0x5d3/0x670 processonework+0x776/0xa90 workerthread+0x2e2/0x560 kthread+0x1a8/0x1f0 retfromfork+0x34/0x60 retfromforkasm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,norootsquash *:/mnt/nfsshareip netns add netns1ip link add name veth1peer type veth peer veth1ifconfig veth1peer 11.11.0.254 upip link set veth1 netns netns1ip netns exec netns1 ifconfig veth1 11.11.0.1ip netns exec netns1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROYCLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns1ip netns del netns1The reason here is that the tcp socket in netns1 (nfs side) has beenshutdown and closed (done in xsdestroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)

In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Properly hide first-in-list PCIe extended capabilityThere are cases where a PCIe extended capability should be hidden fromthe user. For example, an unknown capability (i.e., capability with IDgreater than PCIEXTCAPIDMAX) or a capability that is intentionallychosen to be hidden from the user.Hiding a capability is done by virtualizing and modifying the NextCapability Offset field of the previous capability so it points to thecapability after the one that should be hidden.The special case where the first capability in the list should be hiddenis handled differently because there is no previous capability that canbe modified. In this case, the capability ID and version are zeroedwhile leaving the next pointer intact. This hides the capability andleaves an anchor for the rest of the capability list.However, today, hiding the first capability in the list is not doneproperly if the capability is unknown, as structvfiopcicoredevice->pciconfigmap is set to the capability ID duringinitialization but the capability ID is not properly checked later whenused in vfioconfigdorw(). This leads to the following warning [1] andto an out-of-bounds access to ecapperms array.Fix it by checking capid in vfioconfigdorw(), and if it is greaterthan PCIEXTCAPIDMAX, use an alternative struct permbits for directread only access instead of the ecapperms array.Note that this is safe since the above is the only case where capid canexceed PCIEXTCAPIDMAX (except for the special capabilities, whichare already checked before).[1]WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfiopciconfig.c:1900 vfiopciconfigrw+0x395/0x430 [vfiopcicore]CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1(snip)Call Trace: <TASK> ? showregs+0x69/0x80 ? _warn+0x8d/0x140 ? vfiopciconfigrw+0x395/0x430 [vfiopcicore] ? reportbug+0x18f/0x1a0 ? handlebug+0x63/0xa0 ? excinvalidop+0x19/0x70 ? asmexcinvalidop+0x1b/0x20 ? vfiopciconfigrw+0x395/0x430 [vfiopcicore] ? vfiopciconfigrw+0x244/0x430 [vfiopcicore] vfiopcirw+0x101/0x1b0 [vfiopcicore] vfiopcicoreread+0x1d/0x30 [vfiopcicore] vfiodevicefopsread+0x27/0x40 [vfio] vfsread+0xbd/0x340 ? vfiodevicefopsunlioctl+0xbb/0x740 [vfio] ? _rseqhandlenotifyresume+0xa4/0x4b0 _x64syspread64+0x96/0xc0 x64syscall+0x1c3d/0x20d0 dosyscall64+0x4d/0x120 entrySYSCALL64after_hwframe+0x76/0x7e(CVE-2024-53214)

In the Linux kernel, the following vulnerability has been resolved:net: ieee802154: do not leave a dangling sk pointer in ieee802154create()sockinitdata() attaches the allocated sk object to the provided sockobject. If ieee802154create() fails later, the allocated sk object isfreed, but the dangling pointer remains in the provided sock object, whichmay allow use-after-free.Clear the sk pointer in the sock object on error.(CVE-2024-56602)

In the Linux kernel, the following vulnerability has been resolved:drm/dpmst: Fix MST sideband message body length checkFix the MST sideband message body length check, which must be at least 1byte accounting for the message body CRC (aka message data CRC) at theend of the message.This fixes a case where an MST branch device returns a header with acorrect header CRC (indicating a correctly received body length), withthe body length being incorrectly set to 0. This will later lead to amemory corruption in drmdpsidebandappendpayload() and the followingerrors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drmdpmsttopology.c:786:25 index -1 is out of range for type u8 [48] Call Trace: drmdpsidebandappendpayload+0x33d/0x350 [drmdisplayhelper] drmdpgetonesbmsg+0x3ce/0x5f0 [drmdisplayhelper] drmdpmsthpdirqhandleevent+0xc8/0x1580 [drmdisplayhelper] memcpy: detected field-spanning write (size 18446744073709551615) of single field &msg->msg[msg->curlen] at drivers/gpu/drm/display/drmdpmsttopology.c:791 (size 256) Call Trace: drmdpsidebandappendpayload+0x324/0x350 [drmdisplayhelper] drmdpgetonesbmsg+0x3ce/0x5f0 [drmdisplayhelper] drmdpmsthpdirqhandleevent+0xc8/0x1580 drmdisplay_helper

In the Linux kernel, the following vulnerability has been resolved:iio: adc: at91: call inputfreedevice() on allocated iiodevCurrent implementation of at91tsregister() calls inputfreedeivce()on st->tsinput, however, the err label can be reached before theallocated iiodev is stored to st->tsinput. Thus callinputfreedevice() on input instead of st->ts_input.(CVE-2024-57904)

In the Linux kernel, the following vulnerability has been resolved:iio: adc: ti-ads8688: fix information leak in triggered bufferThe buffer local array is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iioforeachactivechannel() to assign new values.Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.(CVE-2024-57906)

In the Linux kernel, the following vulnerability has been resolved:selinux: ignore unknown extended permissionsWhen evaluating extended permissions, ignore unknown permissions insteadof calling BUG(). This commit ensures that future permissions can beadded without interfering with older kernels.(CVE-2024-57931)

In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix potential NULL pointer dereference in atomctrlgetsmcsclkrangetableThe function atomctrlgetsmcsclkrangetable() does not check the returnvalue of smuatomgetdatatable(). If smuatomgetdatatable() fails toretrieve SMU_Info table, it returns NULL which is later dereferenced.Found by Linux Verification Center (linuxtesting.org) with SVACE.In practice this should never happen as this code only gets calledon polaris chips and the vbios data table will always be present onthose chips.(CVE-2024-58052)

In the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Fix link state exit during switch upstream function removalBefore 456d8aa37d0f ( PCI/ASPM: Disable ASPM on MFD function removal toavoid use-after-free ), we would free the ASPM link only after the lastfunction on the bus pertaining to the given link was removed.That was too late. If function 0 is removed before sibling function,link->downstream would point to free d memory after.After above change, we freed the ASPM parent link state upon any functionremoval on the bus pertaining to a given link.That is too early. If the link is to a PCIe switch with MFD on the upstreamport, then removing functions other than 0 first would free a link whichstill remains parent_link to the remaining downstream ports.The resulting GPFs are especially frequent during hot-unplug, becausepciehp removes devices on the link bus in reverse order.On that switch, function 0 is the virtual P2P bridge to the internal bus.Free exactly when function 0 is removed -- before the parent link isobsolete, but after all subordinate links are gone.kwilczynski: commit log

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

bpf: consider that tail calls invalidate packet pointers

Tail-called programs could execute any of the helpers that invalidate packet pointers. Hence, conservatively assume that each tail call invalidates packet pointers.

Making the change in bpfhelperchangespktdata() automatically makes use of checkcfg() logic that computes 'changespkt_data' effect for global sub-programs, such that the following program could be rejected:

int tail_call(struct __sk_buff *sk)
{
    bpf_tail_call_static(sk, &jmp_table, 0);
    return 0;
}

SEC("tc")
int not_safe(struct __sk_buff *sk)
{
    int *p = (void *)(long)sk->data;
    ... make p valid ...
    tail_call(sk);
    *p = 42; /* this is unsafe */
    ...
}

The tcbpf2bpf.c:subprogtc() needs change: mark it as a function that can invalidate packet pointers. Otherwise, it can't be freplaced with tailcallfreplace.c:entryfreplace() that does a tail call.(CVE-2024-58237)

In the Linux kernel, the following vulnerability has been resolved:filemap: avoid truncating 64-bit offset to 32 bitsOn 32-bit kernels, folioseekhole_data() was inadvertently truncating a64-bit value to 32 bits, leading to a possible infinite loop when writingto an xfs filesystem.(CVE-2025-21665)

In the Linux kernel, the following vulnerability has been resolved:partitions: mac: fix handling of bogus partition tableFix several issues in partition probing: - The bailout for a bad partoffset must use putdevsector(), since the preceding readpartsector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().(CVE-2025-21772)

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:

sctp: detect and prevent references to a freed transport in sendmsg

sctpsendmsg() re-uses associations and transports when possible by doing a lookup based on the socket endpoint and the message destination address, and then sctpsendmsgtoasoc() sets the selected transport in all the message chunks to be sent.

There's a possible race condition if another thread triggers the removal of that selected transport, for instance, by explicitly unbinding an address with setsockopt(SCTPSOCKOPTBINDXREM), after the chunks have been set up and before the message is sent. This can happen if the send buffer is full, during the period when the sender thread temporarily releases the socket lock in sctpwaitforsndbuf().

This causes the access to the transport data in sctpoutqselect_transport(), when the association outqueue is flushed, to result in a use-after-free read.

This change avoids this scenario by having sctptransportfree() signal the freeing of the transport, tagging it as "dead". In order to do this, the patch restores the "dead" bit in struct sctptransport, which was removed in commit 47faa1e4c50e ("sctp: remove the dead field of sctptransport").

Then, in the scenario where the sender thread has released the socket lock in sctpwaitfor_sndbuf(), the bit is checked again after re-acquiring the socket lock to detect the deletion. This is done while holding a reference to the transport to prevent it from being freed in the process.

If the transport was deleted while the socket lock was relinquished, sctpsendmsgto_asoc() will return -EAGAIN to let userspace retry the send.

The bug was found by a private syzbot instance (see the error report [1] and the C reproducer that triggers it [2]).(CVE-2025-23142)

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

netsched: hfsc: Fix a potential UAF in hfscdequeue() too

Similarly to the previous patch, we need to safe guard hfsc_dequeue() too. But for this one, we don't have a reliable reproducer.(CVE-2025-37823)

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

net_sched: drr: Fix double list add in class with netem as child qdisc

As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of drr, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption.

In addition to checking for qlen being zero, this patch checks whether the class was already added to the activelist (clis_active) before adding to the list to cover for the reentrant case.

[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37915)

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

netsched: Flush gsoskb list too during ->change()

Previously, when reducing a qdisc's limit via the ->change() operation, only the main skb queue was trimmed, potentially leaving packets in the gso_skb list. This could result in NULL pointer dereference when we only check sch->limit against sch->q.qlen.

This patch introduces a new helper, qdiscdequeueinternal(), which ensures both the gsoskb list and the main queue are properly flushed when trimming excess packets. All relevant qdiscs (codel, fq, fqcodel, fq_pie, hhf, pie) are updated to use this helper in their ->change() routines.(CVE-2025-37992)

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

nfsd: handle getclientlocked() failure in nfsd4setclientidconfirm()

Lei Lu recently reported that nfsd4setclientidconfirm() did not check the return value from getclientlocked(). a SETCLIENTID_CONFIRM could race with a confirmed client expiring and fail to get a reference. That could later lead to a UAF.

Fix this by getting a reference early in the case where there is an extant confirmed client. If that fails then treat it as if there were no confirmed client found at all.

In the case where the unconfirmed client is expiring, just fail and return the result from getclientlocked().(CVE-2025-38724)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)

In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg. Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40evcconfigqueuesmsg().(CVE-2025-39971)

In the Linux kernel, a buffer overflow vulnerability exists in the targetlugpmembersshow function in targetcoreconfigfs.c. The vulnerability arises from the usage of snprintf to write into the buffer "buf" without checking the return value length. When the total formatted string length exceeds LUGROUPNAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)