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

net: add proper RCU protection to /proc/net/ptype

Yin Fengwei reported an RCU stall in ptypeseqshow() and provided a patch.

Real issue is that ptypeseqnext() and ptypeseqshow() violate RCU rules.

ptypeseqshow() runs under rcureadlock(), and reads pt->dev to get device name without any barrier.

At the same time, concurrent writers can remove a packettype structure (which is correctly freed after an RCU grace period) and clear pt->dev without an RCU grace period.

Define ptypeiterstate to carry a dev pointer along seqnetprivate:

struct ptypeiterstate { struct seqnetprivate p; struct netdevice dev; // added in this patch };

We need to record the device pointer in ptypegetidx() and ptypeseqnext() so that ptypeseqshow() is safe against concurrent pt->dev changes.

We also need to add full RCU protection in ptypeseqnext(). (Missing READONCE() when reading list.next values)

Many thanks to Dong Chenchen for providing a repro.

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

RDMA/umad: Reject negative datalen in ibumadwrite

ibumadwrite computes datalen from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, datalen can become negative and reach ibcreatesendmad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in allocsendrmpplist().

Add an explicit check to reject negative datalen before creating the send buffer.

KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ibcreatesendmad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spraythread/102 [ 211.365867] ibcreatesendmad+0xa01/0x11b0 [ 211.365887] ibumadwrite+0x853/0x1c80

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

RDMA/siw: Fix potential NULL pointer dereference in header processing

If siwgethdr() returns -EINVAL before setrxfpducontext(), qp->rxfpdu can be NULL. The error path in siwtcprxdata() dereferences qp->rxfpdu->moreddpsegs without checking, which may lead to a NULL pointer deref. Only check moreddpsegs when rxfpdu is present.

KASAN splat: [ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7] [ 101.385869] RIP: 0010:siwtcprxdata+0x13ad/0x1e50

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

net/sched: clsu32: use skbheaderpointercareful()

skbheaderpointer() does not fully validate negative @offset values.

Use skbheaderpointercareful() instead.

GangMin Kim provided a report and a repro fooling u32classify():

BUG: KASAN: slab-out-of-bounds in u32classify+0x1180/0x11b0 net/sched/clsu32.c:221

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

scsi: core: Wake up the error handler when final completions race against each other

The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance.

First, there is an memory ordering issue within scsidechostbusy(). The write which clears SCMDSTATEINFLIGHT may be reordered with reads counting in scsihostbusy(). While the local CPU will see its own write, reordering can allow other CPUs in scsidechostbusy() or scsiehinchostfailed() to see a raised busy count, causing no CPU to see a host busy equal to the hostfailed count.

This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands.

Second, there is a general ordering issue with scsiehinchostfailed(). By counting busy commands before incrementing hostfailed, it can race with a final command in scsidechostbusy(), such that scsidechostbusy() does not see hostfailed incremented but scsiehinchostfailed() counts busy commands before SCMDSTATEINFLIGHT is cleared by scsidechostbusy(), resulting in neither waking the error handler task.

This needs the call to scsihostbusy() to be moved after hostfailed is incremented to close the race condition.

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:

scsi: xen: scsiback: Fix potential memory leak in scsibackremove()

Memory allocated for struct vscsiblkinfo in scsibackprobe() is not freed in scsibackremove() leading to potential memory leaks on remove, as well as in the scsibackprobe() error paths. Fix that by freeing it in scsibackremove().

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

net: hvnetvsc: reject RSS hash key programming without RX indirection table

RSS configuration requires a valid RX indirection table. When the device reports a single receive queue, rndisfilterdeviceadd() does not allocate an indirection table, accepting RSS hash key updates in this state leads to a hang.

Fix this by gating netvscsetrxfh() on ndc->rxtablesz and return -EOPNOTSUPP when the table is absent. This aligns setrxfh with the device capabilities and prevents incorrect behavior.

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

ipv6: Fix use-after-free in inet6addrdel().

syzbot reported use-after-free of inet6ifaddr in inet6addrdel(). [0]

The cited commit accidentally moved ipv6deladdr() for mngtmpaddr before reading its ifp->flags for temporary addresses in inet6addrdel().

Let's move ipv6deladdr() down to fix the UAF.

[0]: BUG: KASAN: slab-use-after-free in inet6addrdel.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117 Read of size 4 at addr ffff88807b89c86c by task syz.3.1618/9593

CPU: 0 UID: 0 PID: 9593 Comm: syz.3.1618 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xcd/0x630 mm/kasan/report.c:482 kasanreport+0xe0/0x110 mm/kasan/report.c:595 inet6addrdel.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117 addrconfdelifaddr+0x11e/0x190 net/ipv6/addrconf.c:3181 inet6ioctl+0x1e5/0x2b0 net/ipv6/afinet6.c:582 sockdoioctl+0x118/0x280 net/socket.c:1254 sockioctl+0x227/0x6b0 net/socket.c:1375 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:597 [inline] sesysioctl fs/ioctl.c:583 [inline] x64sysioctl+0x18e/0x210 fs/ioctl.c:583 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f164cf8f749 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:00007f164de64038 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f164d1e5fa0 RCX: 00007f164cf8f749 RDX: 0000200000000000 RSI: 0000000000008936 RDI: 0000000000000003 RBP: 00007f164d013f91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f164d1e6038 R14: 00007f164d1e5fa0 R15: 00007ffde15c8288 </TASK>

Allocated by task 9593: kasansavestack+0x33/0x60 mm/kasan/common.c:56 kasansavetrack+0x14/0x30 mm/kasan/common.c:77 poisonkmallocredzone mm/kasan/common.c:397 [inline] kasankmalloc+0xaa/0xb0 mm/kasan/common.c:414 kmallocnoprof include/linux/slab.h:957 [inline] kzallocnoprof include/linux/slab.h:1094 [inline] ipv6addaddr+0x4e3/0x2010 net/ipv6/addrconf.c:1120 inet6addradd+0x256/0x9b0 net/ipv6/addrconf.c:3050 addrconfaddifaddr+0x1fc/0x450 net/ipv6/addrconf.c:3160 inet6ioctl+0x103/0x2b0 net/ipv6/afinet6.c:580 sockdoioctl+0x118/0x280 net/socket.c:1254 sockioctl+0x227/0x6b0 net/socket.c:1375 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:597 [inline] sesysioctl fs/ioctl.c:583 [inline] x64sysioctl+0x18e/0x210 fs/ioctl.c:583 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

Freed by task 6099: kasansavestack+0x33/0x60 mm/kasan/common.c:56 kasansavetrack+0x14/0x30 mm/kasan/common.c:77 kasansavefreeinfo+0x3b/0x60 mm/kasan/generic.c:584 poisonslabobject mm/kasan/common.c:252 [inline] kasanslabfree+0x5f/0x80 mm/kasan/common.c:284 kasanslabfree include/linux/kasan.h:234 [inline] slabfreehook mm/slub.c:2540 [inline] slabfreefreelisthook mm/slub.c:2569 [inline] slabfreebulk mm/slub.c:6696 [inline] kmemcachefreebulk mm/slub.c:7383 [inline] kmemcachefreebulk+0x2bf/0x680 mm/slub.c:7362 kfreebulk include/linux/slab.h:830 [inline] kvfreercubulk+0x1b7/0x1e0 mm/slabcommon.c:1523 kvfreercudrainready mm/slabcommon.c:1728 [inline] kfreercumonitor+0x1d0/0x2f0 mm/slabcommon.c:1801 processonework+0x9ba/0x1b20 kernel/workqueue.c:3257 processscheduledworks kernel/workqu ---truncated---

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

nfsd: provide locking for v4endgrace

Writing to v4endgrace can race with server shutdown and result in memory being accessed after it was freed - reclaimstrhashtbl in particularly.

We cannot hold nfsdmutex across the nfsd4endgrace() call as that is held while clienttrackingop->init() is called and that can wait for an upcall to nfsdcltrack which can write to v4endgrace, resulting in a deadlock.

nfsd4endgrace() is also called by the landromat work queue and this doesn't require locking as server shutdown will stop the work and wait for it before freeing anything that nfsd4endgrace() might access.

However, we must be sure that writing to v4endgrace doesn't restart the work item after shutdown has already waited for it. For this we add a new flag protected with nn->clientlock. It is set only while it is safe to make client tracking calls, and v4endgrace only schedules work while the flag is set with the spinlock held.

So this patch adds a nfsdnet field "clienttrackingactive" which is set as described. Another field "graceendforced", is set when v4endgrace is written. After this is set, and providing clienttrackingactive is set, the laundromat is scheduled. This "graceendforced" field bypasses other checks for whether the grace period has finished.

This resolves a race which can result in use-after-free.

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

dmaengine: mmppdma: Fix race condition in mmppdmaresidue()

Add proper locking in mmppdmaresidue() to prevent use-after-free when accessing descriptor list and descriptor contents.

The race occurs when multiple threads call txstatus() while the tasklet on another CPU is freeing completed descriptors:

CPU 0 CPU 1 ----- ----- mmppdmatxstatus() mmppdmaresidue() -> NO LOCK held listforeachentry(sw, ..) DMA interrupt dmadotasklet() -> spinlock(&desclock) listmove(sw->node, ...) spinunlock(&desclock) | dmapoolfree(sw) <- FREED! -> access sw->desc <- UAF!

This issue can be reproduced when running dmatest on the same channel with multiple threads (threadsperchan > 1).

Fix by protecting the chainrunning list iteration and descriptor access with the chan->desclock spinlock.

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

dmaengine: athdmac: fix device leak on ofdmaxlate()

Make sure to drop the reference taken when looking up the DMA platform device during ofdmaxlate() when releasing channel resources.

Note that commit 3832b78b3ec2 ("dmaengine: athdmac: add missing putdevice() call in atdmaxlate()") fixed the leak in a couple of error paths but the reference is still leaking on successful allocation.

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

dmaengine: stm32: dmamux: fix device leak on route allocation

Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation.

Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.

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

crypto: seqiv - Do not use req->iv after cryptoaeadencrypt

As soon as cryptoaeadencrypt is called, the underlying request may be freed by an asynchronous completion. Thus dereferencing req->iv after it returns is invalid.

Instead of checking req->iv against info, create a new variable unalignedinfo and use it for that purpose instead.

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

mptcp: fallback earlier on simult connection

Syzkaller reports a simult-connect race leading to inconsistent fallback status:

WARNING: CPU: 3 PID: 33 at net/mptcp/subflow.c:1515 subflowdataready+0x40b/0x7c0 net/mptcp/subflow.c:1515 Modules linked in: CPU: 3 UID: 0 PID: 33 Comm: ksoftirqd/3 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:subflowdataready+0x40b/0x7c0 net/mptcp/subflow.c:1515 Code: 89 ee e8 78 61 3c f6 40 84 ed 75 21 e8 8e 66 3c f6 44 89 fe bf 07 00 00 00 e8 c1 61 3c f6 41 83 ff 07 74 09 e8 76 66 3c f6 90 <0f> 0b 90 e8 6d 66 3c f6 48 89 df e8 e5 ad ff ff 31 ff 89 c5 89 c6 RSP: 0018:ffffc900006cf338 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888031acd100 RCX: ffffffff8b7f2abf RDX: ffff88801e6ea440 RSI: ffffffff8b7f2aca RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000000000000004 R11: 0000000000002c10 R12: ffff88802ba69900 R13: 1ffff920000d9e67 R14: ffff888046f81800 R15: 0000000000000004 FS: 0000000000000000(0000) GS:ffff8880d69bc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000560fc0ca1670 CR3: 0000000032c3a000 CR4: 0000000000352ef0 Call Trace: <TASK> tcpdataqueue+0x13b0/0x4f90 net/ipv4/tcpinput.c:5197 tcprcvstateprocess+0xfdf/0x4ec0 net/ipv4/tcpinput.c:6922 tcpv6dorcv+0x492/0x1740 net/ipv6/tcpipv6.c:1672 tcpv6rcv+0x2976/0x41e0 net/ipv6/tcpipv6.c:1918 ip6protocoldeliverrcu+0x188/0x1520 net/ipv6/ip6input.c:438 ip6inputfinish+0x1e4/0x4b0 net/ipv6/ip6input.c:489 NFHOOK include/linux/netfilter.h:318 [inline] NFHOOK include/linux/netfilter.h:312 [inline] ip6input+0x105/0x2f0 net/ipv6/ip6input.c:500 dstinput include/net/dst.h:471 [inline] ip6rcvfinish net/ipv6/ip6input.c:79 [inline] NFHOOK include/linux/netfilter.h:318 [inline] NFHOOK include/linux/netfilter.h:312 [inline] ipv6rcv+0x264/0x650 net/ipv6/ip6input.c:311 netifreceiveskbonecore+0x12d/0x1e0 net/core/dev.c:5979 netifreceiveskb+0x1d/0x160 net/core/dev.c:6092 processbacklog+0x442/0x15e0 net/core/dev.c:6444 napipoll.constprop.0+0xba/0x550 net/core/dev.c:7494 napipoll net/core/dev.c:7557 [inline] netrxaction+0xa9f/0xfe0 net/core/dev.c:7684 handlesoftirqs+0x216/0x8e0 kernel/softirq.c:579 runksoftirqd kernel/softirq.c:968 [inline] runksoftirqd+0x3a/0x60 kernel/softirq.c:960 smpbootthreadfn+0x3f7/0xae0 kernel/smpboot.c:160 kthread+0x3c2/0x780 kernel/kthread.c:463 retfromfork+0x5d7/0x6f0 arch/x86/kernel/process.c:148 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK>

The TCP subflow can process the simult-connect syn-ack packet after transitioning to TCPFIN1 state, bypassing the MPTCP fallback check, as the skstatechange() callback is not invoked for -> FINWAIT1 transitions.

That will move the msk socket to an inconsistent status and the next incoming data will hit the reported splat.

Close the race moving the simult-fallback check at the earliest possible stage - that is at syn-ack generation time.

About the fixes tags: [2] was supposed to also fix this issue introduced by [3]. [1] is required as a dependence: it was not explicitly marked as a fix, but it is one and it has already been backported before [3]. In other words, this commit should be backported up to [3], including [2] and [1] if that's not already there.

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

net: nfc: fix deadlock between nfcunregisterdevice and rfkillfopwrite

A deadlock can occur between nfcunregisterdevice() and rfkillfopwrite() due to lock ordering inversion between devicelock and rfkillglobalmutex.

The problematic lock order is:

Thread A (rfkillfopwrite): rfkillfopwrite() mutexlock(&rfkillglobalmutex) rfkillsetblock() nfcrfkillsetblock() nfcdevdown() devicelock(&dev->dev) <- waits for devicelock

Thread B (nfcunregisterdevice): nfcunregisterdevice() devicelock(&dev->dev) rfkillunregister() mutexlock(&rfkillglobalmutex) <- waits for rfkillglobalmutex

This creates a classic ABBA deadlock scenario.

Fix this by moving rfkillunregister() and rfkilldestroy() outside the devicelock critical section. Store the rfkill pointer in a local variable before releasing the lock, then call rfkillunregister() after releasing devicelock.

This change is safe because rfkillfopwrite() holds rfkillglobalmutex while calling the rfkill callbacks, and rfkillunregister() also acquires rfkillglobalmutex before cleanup. Therefore, rfkillunregister() will wait for any ongoing callback to complete before proceeding, and devicedel() is only called after rfkillunregister() returns, preventing any use-after-free.

The similar lock ordering in nfcregisterdevice() (devicelock -> rfkillglobalmutex via rfkillregister) is safe because during registration the device is not yet in rfkilllist, so no concurrent rfkill operations can occur on this device.

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.

fsnotify: do not generate ACCESS/MODIFY events on child for special files

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

spi: fsl-cpm: Check length parity before switching to 16 bit mode

Commit fc96ec826bce ("spi: fsl-cpm: Use 16 bit mode for large transfers with even size") failed to make sure that the size is really even before switching to 16 bit mode. Until recently the problem went unnoticed because kernfs uses a pre-allocated bounce buffer of size PAGESIZE for reading EEPROM.

But commit 8ad6249c51d0 ("eeprom: at25: convert to spi-mem API") introduced an additional dynamically allocated bounce buffer whose size is exactly the size of the transfer, leading to a buffer overrun in the fsl-cpm driver when that size is odd.

Add the missing length parity verification and remain in 8 bit mode when the length is not even.

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

NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags

When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the "ro" flag.

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

ext4: refresh inline data size before write operations

The cached ei->iinlinesize can become stale between the initial size check and when ext4updateinlinedata()/ext4createinlinedata() use it. Although ext4getmaxinlinesize() reads the correct value at the time of the check, concurrent xattr operations can modify iinlinesize before ext4writelockxattr() is acquired.

This causes ext4updateinlinedata() and ext4createinlinedata() to work with stale capacity values, leading to a BUGON() crash in ext4writeinlinedata():

kernel BUG at fs/ext4/inline.c:1331! BUGON(pos + len > EXT4I(inode)->iinlinesize);

The race window: 1. ext4getmaxinlinesize() reads iinlinesize = 60 (correct) 2. Size check passes for 50-byte write 3. [Another thread adds xattr, iinlinesize changes to 40] 4. ext4writelockxattr() acquires lock 5. ext4updateinlinedata() uses stale iinlinesize = 60 6. Attempts to write 50 bytes but only 40 bytes actually available 7. BUGON() triggers

Fix this by recalculating iinlinesize via ext4findinlinedatanolock() immediately after acquiring xattrsem. This ensures ext4updateinlinedata() and ext4createinlinedata() work with current values that are protected from concurrent modifications.

This is similar to commit a54c4613dac1 ("ext4: fix race writing to an inlinedata file while its xattrs are changing") which fixed iinlineoff staleness. This patch addresses the related iinlinesize staleness issue.

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

iomap: adjust read range correctly for non-block-aligned positions

iomapadjustreadrange() assumes that the position and length passed in are block-aligned. This is not always the case however, as shown in the syzbot generated case for erofs. This causes too many bytes to be skipped for uptodate blocks, which results in returning the incorrect position and length to read in. If all the blocks are uptodate, this underflows length and returns a position beyond the folio.

Fix the calculation to also take into account the block offset when calculating how many bytes can be skipped for uptodate blocks.

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

OPP: add index check to assert to avoid buffer overflow in readfreq()

Pass the freq index to the assert function to make sure we do not read a freq out of the opp->rates[] table when called from the indexed variants: devpmoppfindfreqexactindexed() or devpmoppfindfreqceil/floorindexed().

Add a secondary parameter to the assert function, unused for assertsingleclk() then add assertclkindex() which will check for the clock index when called from the indexed() find functions.

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

libceph: replace overzealous BUGON in osdmapapplyincremental()

If the osdmap is (maliciously) corrupted such that the incremental osdmap epoch is different from what is expected, there is no need to BUG. Instead, just declare the incremental osdmap to be invalid.

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

perf/core: Fix refcount bug and potential UAF in perfmmap

Syzkaller reported a refcountt: addition on 0; use-after-free warning in perfmmap.

The issue is caused by a race condition between a failing mmap() setup and a concurrent mmap() on a dependent event (e.g., using output redirection).

In perfmmap(), the ringbuffer (rb) is allocated and assigned to event->rb with the mmapmutex held. The mutex is then released to perform maprange().

If maprange() fails, perfmmapclose() is called to clean up. However, since the mutex was dropped, another thread attaching to this event (via inherited events or output redirection) can acquire the mutex, observe the valid event->rb pointer, and attempt to increment its reference count. If the cleanup path has already dropped the reference count to zero, this results in a use-after-free or refcount saturation warning.

Fix this by extending the scope of mmapmutex to cover the maprange() call. This ensures that the ring buffer initialization and mapping (or cleanup on failure) happens atomically effectively, preventing other threads from accessing a half-initialized or dying ring buffer.

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

smb: client: split cachedfid bitfields to avoid shared-byte RMW races

isopen, haslease and onlist are stored in the same bitfield byte in struct cachedfid but are updated in different code paths that may run concurrently. Bitfield assignments generate byte read–modify–write operations (e.g. orb $mask, addr on x8664), so updating one flag can restore stale values of the others.

A possible interleaving is: CPU1: load old byte (haslease=1, onlist=1) CPU2: clear both flags (store 0) CPU1: RMW store (old | ISOPEN) -> reintroduces cleared bits

To avoid this class of races, convert these flags to separate bool fields.

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

ALSA: aloop: Fix racy access at PCM trigger

The PCM trigger callback of aloop driver tries to check the PCM state and stop the stream of the tied substream in the corresponding cable. Since both check and stop operations are performed outside the cable lock, this may result in UAF when a program attempts to trigger frequently while opening/closing the tied stream, as spotted by fuzzers.

For addressing the UAF, this patch changes two things: - It covers the most of code in loopbackcheckformat() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses. - In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF.

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

mptcp: fix race in mptcppmnlflushaddrsdoit()

syzbot and Eulgyu Kim reported crashes in mptcppmnlgetlocalid() and/or mptcppmnlisbackup()

Root cause is listspliceinit() in mptcppmnlflushaddrsdoit() which is not RCU ready.

listspliceinitrcu() can not be called here while holding pernet->lock spinlock.

Many thanks to Eulgyu Kim for providing a repro and testing our patches.

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:

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.