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

nvmet-tcp: add bounds checks in nvmettcpbuildpduiovec

nvmettcpbuildpduiovec() could walk past cmd->req.sg when a PDU length or offset exceeds sgcnt and then use bogus sg->length/offset values, leading to copytoiter() GPF/KASAN. Guard sgidx, remaining entries, and sg->length/offset before building the bvec.

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

svcrdma: bound check rqpages index in inline path

svcrdmacopyinlinerange indexed rqstp->rqpages[rccurpage] without verifying rccurpage stays within the allocated page array. Add guards before the first use and after advancing to a new page.

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

scsi: target: iscsi: Fix use-after-free in iscsitdecconnusagecount()

In iscsitdecconnusagecount(), the function calls complete() while holding the conn->connusagelock. As soon as complete() is invoked, the waiter (such as iscsitcloseconnection()) may wake up and proceed to free the iscsitconn structure.

If the waiter frees the memory before the current thread reaches spinunlockbh(), it results in a KASAN slab-use-after-free as the function attempts to release a lock within the already-freed connection structure.

Fix this by releasing the spinlock before calling complete().

e1000: fix OOB in e1000tbishouldaccept()

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

net: stmmac: fix the crash issue for zero copy XDPTX action

There is a crash issue when running zero copy XDPTX action, the crash log is shown below.

[ 216.122464] Unable to handle kernel paging request at virtual address fffeffff80000000 [ 216.187524] Internal error: Oops: 0000000096000144 [#1] SMP [ 216.301694] Call trace: [ 216.304130] dcachecleanpoc+0x20/0x38 (P) [ 216.308308] dmasyncsinglefordevice+0x1bc/0x1e0 [ 216.313351] stmmacxdpxmitxdpf+0x354/0x400 [ 216.317701] stmmacxdprunprog+0x164/0x368 [ 216.322139] stmmacnapipollrxtx+0xba8/0xf00 [ 216.326576] napipoll+0x40/0x218 [ 216.408054] Kernel panic - not syncing: Oops: Fatal exception in interrupt

For XDPTX action, the xdpbuff is converted to xdpframe by xdpconvertbufftoframe(). The memory type of the resulting xdpframe depends on the memory type of the xdpbuff. For page pool based xdpbuff it produces xdpframe with memory type MEMTYPEPAGEPOOL. For zero copy XSK pool based xdpbuff it produces xdpframe with memory type MEMTYPEPAGEORDER0. However, stmmacxdpxmitback() does not check the memory type and always uses the page pool type, this leads to invalid mappings and causes the crash. Therefore, check the xdpbuff memory type in stmmacxdpxmitback() to fix this issue.

btrfs: always detect conflicting inodes when logging inode refs

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

net: hns3: add VLAN id validation before using

Currently, the VLAN id may be used without validation when receive a VLAN configuration mailbox from VF. The length of vlandelfailbmap is BITSTOLONGS(VLANNVID). It may cause out-of-bounds memory access once the VLAN id is bigger than or equal to VLANNVID.

Therefore, VLAN id needs to be checked to ensure it is within the range of VLANNVID.

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

SUNRPC: svcauthgss: avoid NULL deref on zero length gsstoken in gssreadproxyverf

A zero length gsstoken results in pages == 0 and intoken->pages[0] is NULL. The code unconditionally evaluates pageaddress(intoken->pages[0]) for the initial memcpy, which can dereference NULL even when the copy length is 0. Guard the first memcpy so it only runs when length > 0.

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

nvme-tcp: fix NULL pointer dereferences in nvmettcpbuildpduiovec

Commit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length") added ttag bounds checking and dataoffset validation in nvmettcphandleh2cdatapdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2CDATA PDUs.

The nvmettcpbuildpduiovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2CDATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command.

Attack vectors that trigger NULL pointer dereferences: 1. H2CDATA PDU sent before CONNECT → both pointers NULL 2. H2CDATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2CDATA PDU for uninitialized command slot → both pointers NULL

The fix validates both cmd->req.sg and cmd->iov before calling nvmettcpbuildpduiovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated

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

gue: Fix skb memleak with inner IP protocol 0.

syzbot reported skb memleak below. [0]

The repro generated a GUE packet with its inner protocol 0.

gueudprecv() returns -guehdr->protoctype for "resubmit" in ipprotocoldeliverrcu(), but this only works with non-zero protocol number.

Let's drop such packets.

Note that 0 is a valid number (IPv6 Hop-by-Hop Option).

I think it is not practical to encap HOPOPT in GUE, so once someone starts to complain, we could pass down a resubmit flag pointer to distinguish two zeros from the upper layer:

no error resubmit HOPOPT

[0] BUG: memory leak unreferenced object 0xffff888109695a00 (size 240): comm "syz.0.17", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleakallocrecursive include/linux/kmemleak.h:44 [inline] slabpostallochook mm/slub.c:4958 [inline] slaballocnode mm/slub.c:5263 [inline] kmemcacheallocnoprof+0x3b4/0x590 mm/slub.c:5270 buildskb+0x23/0x60 net/core/skbuff.c:474 buildskb+0x20/0x190 net/core/skbuff.c:490 tunbuildskb drivers/net/tun.c:1541 [inline] tunbuildskb+0x4a1/0xa40 drivers/net/tun.c:1636 tungetuser+0xc12/0x2030 drivers/net/tun.c:1770 tunchrwriteiter+0x71/0x120 drivers/net/tun.c:1999 newsyncwrite fs/readwrite.c:593 [inline] vfswrite+0x45d/0x710 fs/readwrite.c:686 ksyswrite+0xa7/0x170 fs/readwrite.c:738 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xa4/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

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

net/sched: Enforce that teql can only be used as root qdisc

Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint.

Although not important, I will describe the scenario that unearthed this issue for the curious.

GangMin Kim <km.kim1503@gmail.com> managed to concot a scenario as follows:

ROOT qdisc 1:0 (QFQ) ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s └── class 1:2 (weight=1, lmax=1514) teql

GangMin sends a packet which is enqueued to 1:1 (netem). Any invocation of dequeue by QFQ from this class will not return a packet until after 6.4s. In the meantime, a second packet is sent and it lands on 1:2. teql's enqueue will return success and this will activate class 1:2. Main issue is that teql only updates the parent visible qlen (sch->q.qlen) at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql's peek always returns NULL), dequeue will never be called and thus the qlen will remain as 0. With that in mind, when GangMin updates 1:2's lmax value, the qfqchangeclass calls qfqdeactrmfromagg. Since the child qdisc's qlen was not incremented, qfq fails to deactivate the class, but still frees its pointers from the aggregate. So when the first packet is rescheduled after 6.4 seconds (netem's delay), a dangling pointer is accessed causing GangMin's causing a UAF.

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

rxrpc: Fix recvmsg() unconditional requeue

If rxrpcrecvmsg() fails because MSGDONTWAIT was specified but the call at the front of the recvmsg queue already has its mutex locked, it requeues the call - whether or not the call is already queued. The call may be on the queue because MSGPEEK was also passed and so the call was not dequeued or because the I/O thread requeued it.

The unconditional requeue may then corrupt the recvmsg queue, leading to things like UAFs or refcount underruns.

Fix this by only requeuing the call if it isn't already on the queue - and moving it to the front if it is already queued. If we don't queue it, we have to put the ref we obtained by dequeuing it.

Also, MSGPEEK doesn't dequeue the call so shouldn't call rxrpcnotifysocket() for the call if we didn't use up all the data on the queue, so fix that also.

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

ice: fix devlink reload call trace

Commit 4da71a77fc3b ("ice: read internal temperature sensor") introduced internal temperature sensor reading via HWMON. icehwmoninit() was added to iceinitfeature() and icehwmonexit() was added to iceremove(). As a result if devlink reload is used to reinit the device and then the driver is removed, a call trace can occur.

BUG: unable to handle page fault for address: ffffffffc0fd4b5d Call Trace: string+0x48/0xe0 vsnprintf+0x1f9/0x650 sprintf+0x62/0x80 nameshow+0x1f/0x30 devattrshow+0x19/0x60

The call trace repeats approximately every 10 minutes when system monitoring tools (e.g., sadc) attempt to read the orphaned hwmon sysfs attributes that reference freed module memory.

The sequence is: 1. Driver load, icehwmoninit() gets called from iceinitfeature() 2. Devlink reload down, flow does not call iceremove() 3. Devlink reload up, icehwmoninit() gets called from iceinitfeature() resulting in a second instance 4. Driver unload, icehwmonexit() called from iceremove() leaving the first hwmon instance orphaned with dangling pointer

Fix this by moving icehwmonexit() from iceremove() to icedeinitfeatures() to ensure proper cleanup symmetry with icehwmoninit().

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

bpf, testrun: Subtract size of xdpframe from allowed metadata size

The xdpframe structure takes up part of the XDP frame headroom, limiting the size of the metadata. However, in bpftestrun, we don't take this into account, which makes it possible for userspace to supply a metadata size that is too large (taking up the entire headroom).

If userspace supplies such a large metadata size in live packet mode, the xdpupdateframefrombuff() call in xdptestruninitpage() call will fail, after which packet transmission proceeds with an uninitialised frame structure, leading to the usual Bad Stuff.

The commit in the Fixes tag fixed a related bug where the second check in xdpupdateframefrombuff() could fail, but did not add any additional constraints on the metadata size. Complete the fix by adding an additional check on the metadata size. Reorder the checks slightly to make the logic clearer and add a comment.

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

scsi: target: iscsi: Fix use-after-free in iscsitdecsessionusagecount()

In iscsitdecsessionusagecount(), the function calls complete() while holding the sess->sessionusagelock. Similar to the connection usage count logic, the waiter signaled by complete() (e.g., in the session release path) may wake up and free the iscsitsession structure immediately.

This creates a race condition where the current thread may attempt to execute spinunlockbh() on a session structure that has already been deallocated, resulting in a KASAN slab-use-after-free.

To resolve this, release the sessionusagelock before calling complete() to ensure all dereferences of the sess pointer are finished before the waiter is allowed to proceed with deallocation.

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

libceph: make decodepool() more resilient against corrupted osdmaps

If the osdmap is (maliciously) corrupted such that the encoded length of cephpgpool envelope is less than what is expected for a particular encoding version, out-of-bounds reads may ensue because the only bounds check that is there is based on that length value.

This patch adds explicit bounds checks for each field that is decoded or skipped.

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

nvmet: fix race in nvmetbiodone() leading to NULL pointer dereference

There is a race condition in nvmetbiodone() that can cause a NULL pointer dereference in blkcgroupbiostart():

1. nvmetbiodone() is called when a bio completes 2. nvmetreqcomplete() is called, which invokes req->ops->queueresponse(req) 3. The queueresponse callback can re-queue and re-submit the same request 4. The re-submission reuses the same inlinebio from nvmetreq 5. Meanwhile, nvmetreqbioput() (called after nvmetreqcomplete) invokes biouninit() for inlinebio, which sets bio->biblkg to NULL 6. The re-submitted bio enters submitbionoacctnocheck() 7. blkcgroupbiostart() dereferences bio->biblkg, causing a crash:

BUG: kernel NULL pointer dereference, address: 0000000000000028 #PF: supervisor read access in kernel mode RIP: 0010:blkcgroupbiostart+0x10/0xd0 Call Trace: submitbionoacctnocheck+0x44/0x250 nvmetbdevexecuterw+0x254/0x370 [nvmet] processonework+0x193/0x3c0 workerthread+0x281/0x3a0

Fix this by reordering nvmetbiodone() to call nvmetreqbioput() BEFORE nvmetreqcomplete(). This ensures the bio is cleaned up before the request can be re-submitted, preventing the race condition.

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

net: rose: fix invalid array index in rosekillbydevice()

rosekillbydevice() collects sockets into a local array[] and then iterates over them to disconnect sockets bound to a device being brought down.

The loop mistakenly indexes array[cnt] instead of array[i]. For cnt < ARRAYSIZE(array), this reads an uninitialized entry; for cnt == ARRAYSIZE(array), it is an out-of-bounds read. Either case can lead to an invalid socket pointer dereference and also leaks references taken via sockhold().

Fix the index to use i.

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

iommu/mediatek: fix use-after-free on probe deferral

The driver is dropping the references taken to the larb devices during probe after successful lookup as well as on errors. This can potentially lead to a use-after-free in case a larb device has not yet been bound to its driver so that the iommu driver probe defers.

Fix this by keeping the references as expected while the iommu driver is bound.

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

scsi: aic94xx: fix use-after-free in device removal path

The asdpciremove() function fails to synchronize with pending tasklets before freeing the asdha structure, leading to a potential use-after-free vulnerability.

When a device removal is triggered (via hot-unplug or module unload), race condition can occur.

The fix adds taskletkill() before freeing the asdha structure, ensuring all scheduled tasklets complete before cleanup proceeds.

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

RDMA/bnxtre: Fix OOB write in bnxtrecopyerrstats()

Commit ef56081d1864 ("RDMA/bnxtre: RoCE related hardware counters update") added three new counters and placed them after BNXTREOUTOFSEQERR.

BNXTREOUTOFSEQERR acts as a boundary marker for allocating hardware statistics with different numcounters values on chipgenp5p7 devices.

As a result, BNXTRENUMSTDCOUNTERS are used when allocating hwstats, which leads to an out-of-bounds write in bnxtrecopyerrstats().

The counters BNXTREREQCQEERROR, BNXTRERESPCQEERROR, and BNXTRERESPREMOTEACCESSERRS are applicable to generic hardware, not only p5/p7 devices.

Fix this by moving these counters before BNXTREOUTOFSEQERR so they are included in the generic counter set.

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

drm/xe/oa: Fix potential UAF in xeoaaddconfigioctl()

In xeoaaddconfigioctl(), we accessed oaconfig->id after dropping metricslock. Since this lock protects the lifetime of oaconfig, an attacker could guess the id and call xeoaremoveconfigioctl() with perfect timing, freeing oaconfig before we dereference it, leading to a potential use-after-free.

Fix this by caching the id in a local variable while holding the lock.

v2: (Matt A) - Dropped mutexunlock(&oa->metricslock) ordering change from xeoaremoveconfigioctl()

(cherry picked from commit 28aeaed130e8e587fd1b73b6d66ca41ccc5a1a31)

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

wifi: rtlwifi: 8192cu: fix tid out of range in rtl92cutxfilldesc()

TID getting from ieee80211gettid() might be out of range of array size of staentry->tids[], so check TID is less than MAXTIDCOUNT. Othwerwise, UBSAN warn:

UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:514:30 index 10 is out of range for type 'rtltiddata [9]'

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

mm/slub: reset KASAN tag in deferfree() before accessing freed memory

When CONFIGSLUBTINY is enabled, kfreenolock() calls kasanslabfree() before deferfree(). On ARM64 with MTE (Memory Tagging Extension), kasanslabfree() poisons the memory and changes the tag from the original (e.g., 0xf3) to a poison tag (0xfe).

When deferfree() then tries to write to the freed object to build the deferred free list via llistadd(), the pointer still has the old tag, causing a tag mismatch and triggering a KASAN use-after-free report:

BUG: KASAN: slab-use-after-free in deferfree+0x3c/0xbc mm/slub.c:6537 Write at addr f3f000000854f020 by task kworker/u8:6/983 Pointer tag: [f3], memory tag: [fe]

Fix this by calling kasanresettag() before accessing the freed memory. This is safe because deferfree() is part of the allocator itself and is expected to manipulate freed memory for bookkeeping purposes.

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

iommufd/selftest: Check for overflow in IOMMUTESTOPADDRESERVED

syzkaller found it could overflow math in the test infrastructure and cause a WARNON by corrupting the reserved interval tree. This only effects test kernels with CONFIGIOMMUFDTEST.

Validate the user input length in the test ioctl.

clk: samsung: exynos-clkout: Assign .num before accessing .hws

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

octeontx2-pf: fix "UBSAN: shift-out-of-bounds error"

This patch ensures that the RX ring size (rxpending) is not set below the permitted length. This avoids UBSAN shift-out-of-bounds errors when users passes small or zero ring sizes via ethtool -G.

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

ext4: fix string copying in parseapplysbmountoptions()

strscpypad() can't be used to copy a non-NUL-term string into a NUL-term string of possibly bigger size. Commit 0efc5990bca5 ("string.h: Introduce memtostr() and memtostrpad()") provides additional information in that regard. So if this happens, the following warning is observed:

strnlen: detected buffer overflow: 65 byte read of buffer size 64 WARNING: CPU: 0 PID: 28655 at lib/stringhelpers.c:1032 fortifyreport+0x96/0xc0 lib/stringhelpers.c:1032 Modules linked in: CPU: 0 UID: 0 PID: 28655 Comm: syz-executor.3 Not tainted 6.12.54-syzkaller-00144-g5f0270f1ba00 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:fortifyreport+0x96/0xc0 lib/stringhelpers.c:1032 Call Trace: <TASK> fortifypanic+0x1f/0x30 lib/stringhelpers.c:1039 strnlen include/linux/fortify-string.h:235 [inline] sizedstrscpy include/linux/fortify-string.h:309 [inline] parseapplysbmountoptions fs/ext4/super.c:2504 [inline] ext4fillsuper fs/ext4/super.c:5261 [inline] ext4fillsuper+0x3c35/0xad00 fs/ext4/super.c:5706 gettreebdevflags+0x387/0x620 fs/super.c:1636 vfsgettree+0x93/0x380 fs/super.c:1814 donewmount fs/namespace.c:3553 [inline] pathmount+0x6ae/0x1f70 fs/namespace.c:3880 domount fs/namespace.c:3893 [inline] dosysmount fs/namespace.c:4103 [inline] sesysmount fs/namespace.c:4080 [inline] x64sysmount+0x280/0x300 fs/namespace.c:4080 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x64/0x140 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x76/0x7e

Since userspace is expected to provide smountopts field to be at most 63 characters long with the ending byte being NUL-term, use a 64-byte buffer which matches the size of smountopts, so that strscpypad() does its job properly. Return with error if the user still managed to provide a non-NUL-term string here.

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

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

mm/damon/core: remove callcontrol in inactive contexts

If damoncall() is executed against a DAMON context that is not running, the function returns error while keeping the damoncallcontrol object linked to the context's callcontrols list. Let's suppose the object is deallocated after the damoncall(), and yet another damoncall() is executed against the same context. The function tries to add the new damoncallcontrol object to the callcontrols list, which still has the pointer to the previous damoncallcontrol object, which is deallocated. As a result, use-after-free happens.

This can actually be triggered using the DAMON sysfs interface. It is not easily exploitable since it requires the sysfs write permission and making a definitely weird file writes, though. Please refer to the report for more details about the issue reproduction steps.

Fix the issue by making two changes. Firstly, move the final kdamondcall() for cancelling all existing damoncall() requests from terminating DAMON context to be done before the ctx->kdamond reset. This makes any code that sees NULL ctx->kdamond can safely assume the context may not access damoncall() requests anymore. Secondly, let damoncall() to cleanup the damoncallcontrol objects that were added to the already-terminated DAMON context, before returning the error.

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

net: octeonepvf: fix freeirq devid mismatch in IRQ rollback

octepvfrequestirqs() requests MSI-X queue IRQs with devid set to ioqvector. If requestirq() fails part-way, the rollback loop calls freeirq() with devid set to 'oct', which does not match the original devid and may leave the irqaction registered.

This can keep IRQ handlers alive while ioqvector is later freed during unwind/teardown, leading to a use-after-free or crash when an interrupt fires.

Fix the error path to free IRQs with the same ioqvector devid used during requestirq().