In the Linux kernel, the following vulnerability has been resolved:
signal: clear JOBCTLPENDINGMASK for caller in zapotherthreads()
When a multi-threaded process receives a stop signal (e.g., SIGSTOP), dosignalstop() sets JOBCTLSTOPPENDING and JOBCTLSTOPCONSUME on all threads and sets signal->groupstopcount to the number of threads. If one of the threads concurrently calls execve(), dethread() invokes zapotherthreads() to kill all other threads. zapotherthreads() aborts the pending group stop by resetting signal->groupstopcount to 0 and clears the JOBCTLPENDINGMASK for all other threads. However, it fails to clear the job control flags for the calling thread.
When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTLSTOPPENDING flag, it calls dosignalstop(), which invokes taskparticipategroupstop(). Since JOBCTLSTOPCONSUME is still set, it attempts to decrement the already-zero signal->groupstopcount, triggering a warning:
sig->groupstopcount == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 taskparticipategroupstop+0x215/0x2d0 Call Trace: <TASK> dosignalstop+0x3be/0x5c0 kernel/signal.c:2619 getsignal+0xa8c/0x1330 kernel/signal.c:2884 archdosignalorrestart+0xbc/0x840 arch/x86/kernel/signal.c:337 exittousermodeloop+0x8c/0x4d0 kernel/entry/common.c:98 dosyscall64+0x33e/0xf80 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>
Fix this race condition by clearing the JOBCTLPENDINGMASK for the calling thread in zapotherthreads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zapprocess() and completesignal(), which correctly clear these flags for all threads including the current one.
In the Linux kernel, the following vulnerability has been resolved:
xfrm: policy: fix use-after-free on inexact bin in xfrmpolicybyselctx()
Fix the race by pruning the bin while still holding xfrmpolicylock, before dropping it. Use xfrmpolicyinexactprunebin() directly since the lock is already held. The wrapper xfrmpolicyinexactprunebin() becomes unused and is removed.
Race:
CPU0 (XFRMMSGDELPOLICY) CPU1 (XFRMMSGNEWSPDINFO) ========================== ========================== xfrmpolicybyselctx(): spinlockbh(xfrmpolicylock) bin = xfrmpolicyinexactlookup() xfrmpolicyunlink(pol) spinunlockbh(xfrmpolicylock) xfrmpolicykill(ret) // wide window, lock not held xfrmhashrebuild(): spinlockbh(xfrmpolicylock) xfrmpolicyinexactflush(): kfreercu(bin) // bin freed spinunlockbh(xfrmpolicylock) xfrmpolicyinexactprunebin(bin) // UAF: bin is freed
In the Linux kernel, the following vulnerability has been resolved:
netfilter: synproxy: add mutex to guard hook reference counting
As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other.
Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: mcast: Fix use-after-free when processing MLD queries
When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskbmaypull() calls, leading to a use-after-free [1].
Fix by copying the multicast group address when the packet is initially parsed.
[1] BUG: KASAN: slab-use-after-free in mldquerywork (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118
Workqueue: mld mldquerywork Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:94 lib/dumpstack.c:120) printaddressdescription.constprop.0 (mm/kasan/report.c:378) printreport (mm/kasan/report.c:482) kasanreport (mm/kasan/report.c:595) mldquerywork (net/ipv6/mcast.c:1512) mldquerywork (net/ipv6/mcast.c:1563) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245) </TASK>
[...]
Freed by task 118: kasansavestack (mm/kasan/common.c:57) kasansavetrack (mm/kasan/common.c:78) kasansavefreeinfo (mm/kasan/generic.c:584) kasanslabfree (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskbexpandhead (net/core/skbuff.c:2335) pskbpulltail (net/core/skbuff.c:2878 (discriminator 4)) mldquerywork (net/ipv6/mcast.c:1495 (discriminator 1)) mldquerywork (net/ipv6/mcast.c:1563) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245)
In the Linux kernel, the following vulnerability has been resolved:
ipv4: restrict IPOPTSSRR and IPOPTLSRR options
This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAPNETRAW capability.
This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information.
While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths.
RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrackirc: fix possible out-of-bounds read
When parsing fails after we've matched the command string we should bail out instead of trying to match a different command.
This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftfib: fix stale stack leak via the OIFNAME register
For NFTFIBRESULTOIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTNLOCAL and oif-mismatch paths nftfib{4,6}eval() only writes one register via "dest = 0". The remaining three registers are left as whatever was on the stack in nftdochain()'s struct nftregs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace.
The NFTAFIBFPRESENT existence check has the same shape: it is only meaningful for NFTFIBRESULTOIF, yet it was accepted for any result type while the eval stores a single byte via nftregstore8(), leaving the rest of the declared span stale.
Fix both:
- replace the bare "dest = 0" in the eval with nftfibstoreresult(), which strscpypad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and
- restrict NFTAFIBFPRESENT to NFTFIBRESULTOIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xtables: avoid leaking percpu counter pointers
The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot.
On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by xtables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace.
Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftexthdr: fix register tracking for FPRESENT flag
nftexthdrinit() passes user-controlled priv->len to nftparseregisterstore(), which marks that many bytes in the register bitmap as initialized. However, when NFTEXTHDRFPRESENT is set, the eval paths write only 1 byte (nftregstore8) or 4 bytes (dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nftregs.
Bail out if userspace requests too much data when FPRESENT is set.
In the Linux kernel, the following vulnerability has been resolved:
net: guard timestamp cmsgs to real error queue skbs
skbiserrqueue() treats PACKETOUTGOING as the sole marker for an skb from skerrorqueue. That assumption is not true for AFPACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkttype == PACKETOUTGOING, but their skb->cb is owned by AFPACKET instead of struct sockexterrskb.
If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AFPACKET control-buffer state as sockexterrskb::optstats. With SORXQOVFL enabled, the packet drop counter overlaps optstats. An odd drop count makes the path emit SCMTIMESTAMPINGOPTSTATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents.
Keep skbiserrqueue() local to net/socket.c, but make it verify that the PACKETOUTGOING marker is paired with the sockrmemfree destructor installed by sockqueueerrskb(). AFPACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate skerrorqueue entries keep the PACKETOUTGOING marker and sockrmemfree ownership.
In the Linux kernel, the following vulnerability has been resolved:
tcp: restrict SOATTACHFILTER to priv users
This patch restricts the use of SOATTACHFILTER (cBPF) on TCP sockets to users with CAPNETADMIN capability.
This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftct: fix missing expect put in obj eval
nftctexpectobjeval() allocates an expectation and may call nfctexpectrelated(), but never drops its local reference.
Add nfctexpectput(exp) before return to balance allocation.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfqueue: hold bridge skb->dev while queued
brpassframeup() rewrites skb->dev from the ingress port to the bridge master before queueing bridge LOCALIN packets. NFQUEUE only holds references on state.in/out and bridge physdevs, so a queued bridge packet can retain a freed bridge master in skb->dev until reinjection.
When the verdict is reinjected later, brnetifreceiveskb() re-enters the receive path with skb->dev still pointing at the freed bridge master, triggering a use-after-free.
Store skb->dev in the queue entry, hold a reference on it for the queue lifetime, and use the saved device when dropping queued packets during NETDEVDOWN handling.
In the Linux kernel, the following vulnerability has been resolved:
ipc/shm: serialize orphan cleanup with shmnattch updates
shmdestroyorphaned() walks the shm idr under shmids(ns).rwsem, but that does not serialize all fields tested by shmmaydestroy(). In particular, shmnattch is updated while holding shmperm.lock, and attach paths can do that without holding the rwsem.
Do not decide that an orphaned segment is unused before taking the object lock. Move the shmmaydestroy() check under shmperm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nflog: validate MAC header was set before dumping it
The fallback path of dumpmacheader() guards the MAC header access only with "skb->macheader != skb->networkheader", without checking skbmacheaderwasset(). When the MAC header is unset, macheader is 0xffff, so the test passes and skbmacheader(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hardheaderlen bytes out of bounds into the kernel log.
This is reachable via the netdev logger: nflogunknownpacket() calls dumpmacheader() unconditionally, and an skb sent through AFPACKET with PACKETQDISCBYPASS reaches the egress hook with macheader still unset (devqueuexmit(), which would reset it, is bypassed).
Add the skbmacheaderwasset() check the ARPHRDETHER path already uses, and replace the open-coded MAC header length test with skbmacheaderlen(). Only skbs with an unset MAC header are affected; valid ones are dumped as before.
BUG: KASAN: slab-out-of-bounds in dumpmacheader (net/netfilter/nflogsyslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasanreport (mm/kasan/report.c:595) dumpmacheader (net/netfilter/nflogsyslog.c:831) nflognetdevpacket (net/netfilter/nflogsyslog.c:938 net/netfilter/nflogsyslog.c:963) nflogpacket (net/netfilter/nflog.c:260) nftlogeval (net/netfilter/nftlog.c:60) nftdochain (net/netfilter/nftablescore.c:285) nftdochainnetdev (net/netfilter/nftchainfilter.c:307) nfhookslow (net/netfilter/core.c:619) nfhookdirectegress (net/packet/afpacket.c:257) packetxmit (net/packet/afpacket.c:280) packetsendmsg (net/packet/afpacket.c:3114) syssendto (net/socket.c:2265)
In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: fix missing zerocopy reference in pskbcarve helpers
pskbcarveinsideheader() and pskbcarveinsidenonlinear() both copy the old skbsharedinfo header into a new buffer via memcpy(), which includes the destructorarg pointer (uarg) for MSGZEROCOPY skbs. Neither function calls netzcopyget() for the new shinfo, creating an unaccounted holder: every skbsharedinfo with destructorarg set will call skbzcopyclear() once when freed, but the corresponding netzcopyget() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubufinfomsgzc while TX skbs still hold live destructorarg pointers.
KASAN reports use-after-free on a freed ubufinfomsgzc:
BUG: KASAN: slab-use-after-free in skbreleasedata+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220
Call Trace: skbreleasedata+0x77b/0x810 kfreeskblistreason+0x13e/0x610 skbreleasedata+0x4cd/0x810 skskbreasondrop+0xf3/0x340 skbqueuepurgereason+0x282/0x440 rdstcpincfree+0x1e/0x30 rdsrecvmsg+0x354/0x1780 sysrecvmsg+0xdf/0x180
Allocated by task 219: msgzerocopyrealloc+0x157/0x7b0 tcpsendmsglocked+0x2892/0x3ba0
Freed by task 219: iprecverror+0x74a/0xb10 tcprecvmsg+0x475/0x530
The skb consuming the late access still referenced the same uarg via shinfo->destructorarg copied by pskbcarveinsidenonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration.
The fix follows the pattern of pskbexpandhead() which has the same memcpy/cloned structure. For pskbcarveinsideheader(), netzcopyget() is placed after skborphanfrags() succeeds, so the orphan error path needs no cleanup. For pskbcarveinsidenonlinear(), netzcopyget() is placed after all failure points and just before skbreleasedata(), so no error path needs cleanup at all -- matching pskbexpandhead() more closely and avoiding the need for a balancing netzcopyput().
In the Linux kernel, the following vulnerability has been resolved:
net: gro: don't merge zcopy skbs
skbgroreceive() can currently copy frags between the source and GRO skb, without checking the zerocopy status, and in particular the SKBFLMANAGEDFRAGREFS flag.
When SKBFLMANAGEDFRAGREFS is set, the skb doesn't hold a reference on the pages in shinfo->frags. Appending those frags to another skb's frags without fixing up the page refcount can lead to UAF.
When either the last skb in the GRO chain (the one we would append frags to) or the source skb is zerocopy, don't merge the skbs.
Fragnesia is a universal Linux local privilege escalation exploit, discovered by William Bowling with the V12 team. Fragnesia is a member of the Dirty Frag vulnerability class. This is a separate bug in the ESP/XFRM from dirtyfrag which has received its own patch. However, it is in the same surface and the mitigation is the same as for dirtyfrag.
It abuses a logic bug in the Linux XFRM ESP-in-TCP subsystem to achieve arbitrary byte writes into the kernel page cache of read-only files, without requiring any race condition.
The technique extends the page-cache write bug class that includes Dirty Pipe: when a TCP socket transitions to espintcp ULP mode after data has already been spliced from a file into the receive queue, the kernel processes the queued file pages as ESP ciphertext. The AES-GCM keystream byte at counter block position 2, byte 0 is XORed directly into the cached file page. By selecting the IV nonce to produce a desired keystream byte, any target byte in the file can be set to any value — one byte per trigger invocation.
The exploit builds a 256-entry lookup table mapping each possible keystream byte to its corresponding nonce, then iterates over a payload, firing the splice/ULP race for each byte that needs changing. It writes a small position-independent ELF stub (setresuid/setresgid/execve /bin/sh) over the first 192 bytes of /usr/bin/su in the page cache, then calls execve("/usr/bin/su") to obtain a root shell. The page cache modification is not backed to disk; the on-disk binary is untouched.
exit: prevent preemption of oopsing TASKDEAD task
In the Linux kernel, the following vulnerability has been resolved:
In the Linux kernel, the following vulnerability has been resolved:
x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache
Make sure resources are not improperly shared in the op cache and cause instruction corruption this way.
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix missing locking around retry adding new subreqs
Fix netfsretryreadsubrequests() and netfsretrywritestream() to take the appropriate lock when adding extra subrequests into stream->subrequests.
In the Linux kernel, the following vulnerability has been resolved:
ipc: limit nextid allocation to the valid ID range
The checkpoint/restore sysctl path can request the next SysV IPC id through ids->nextid. ipcidralloc() currently forwards that request to idralloc() with an open-ended upper bound.
If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipcmni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object.
The bug is in ipcidralloc() in the checkpoint/restore path.
1. ids->nextid is passed to:
idralloc(&ids->ipcsidr, new, ipcidtoidx(nextid), 0, ...)
2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idralloc() can spill past ipcmni and allocate an entry beyond the valid IPC id range.
3. The new object id is still encoded with the narrower SysV IPC index width:
new->id = (new->seq << ipcmniseqshift()) + idx
4. Later removal goes through ipcrmid(), which uses:
ipcidtoidx(ipcp->id)
That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index.
5. For shared memory, shmdestroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer.
6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory.
Prevent this by bounding the requested allocation to ipcmni so the checkpoint/restore path fails once the valid range is exhausted.
In the Linux kernel, the following vulnerability has been resolved:
In the Linux kernel, the following vulnerability has been resolved:
riscv: Fix register corruption from uninitialized cregs on error
compatriscvgprset() calls cregstoregs() unconditionally, even when userregsetcopyin() fails. Since cregs is an uninitialized stack variable, a copyin failure causes uninitialized stack data to be written into the target task's ptregs, corrupting its register state and potentially leaking kernel stack contents.
compatrestoresigcontext() has the same issue: it calls cregstoregs() even when copyfromuser() fails, leading to the same corruption of the signal-returning task's register state on error.
Only call cregstoregs() when the user copy succeeds.
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (pmbus/adm1266) include PEC byte in pmbusblockxfer read buffer
adm1266pmbusblockxfer() sets up the read transaction with
.buf = data->readbuf, .len = ADM1266PMBUSBLOCKMAX + 2,
but readbuf in struct adm1266data is declared as
u8 readbuf[ADM1266PMBUSBLOCKMAX + 1];
For a max-length block response (length byte = 255 + up to 1 PEC byte), the i2c controller is told to write 257 bytes into a 256-byte buffer, putting one byte past the end of readbuf. The same response also makes the subsequent PEC compare
if (crc != msgs[1].buf[msgs[1].buf[0] + 1])
read a byte beyond the array.
Bump the readbuf declaration to ADM1266PMBUSBLOCKMAX + 2 so the buffer can hold the length byte, up to 255 payload bytes, and the PEC byte the i2cmsg length already accounts for.
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (pmbus/adm1266) reject implausible blackbox recordcount
adm1266nvmemreadblackbox() loops over a recordcount that comes straight from byte 3 of the BLACKBOXINFO response. The destination buffer is data->devmem, sized for the nvmem cell's declared 2048 bytes (ADM1266BLACKBOXMAXRECORDS ADM1266BLACKBOXSIZE = 32 64). A device that reports a recordcount greater than 32 -- whether due to firmware bugs, bus corruption, or a non-responsive slave returning 0xff -- would walk readbuff past the end of the devmem allocation on the trailing iterations.
Cap recordcount at ADM1266BLACKBOXMAXRECORDS (introduced here) before entering the loop and return -EIO on any larger value, so a malformed BLACKBOXINFO response cannot drive the loop out of bounds.
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix netfsinvalidatefolio() to clear dirty bit if all changes gone
If a streaming write is made, this will leave the relevant modified folio in a not-uptodate, but dirty state with a netfsfolio struct hung off of folio->private indicating the dirty range. Subsequently truncating the file such that the dirty data in the folio is removed, but the first part of the folio theoretically remains will cause the netfsfolio struct to be discarded... but will leave the dirty flag set.
If the folio is then read via mmap(), netfsreadfolio() will see that the page is dirty and jump to netfsreadgaps() to fill in the missing bits. netfsreadgaps(), however, expects there to be a netfsfolio struct present and can oops because truncate removed it.
Fix this by calling foliocanceldirty() in netfsinvalidatefolio() in the event that all the dirty data in the folio is erased (as nfs does).
Also add some tracepoints to log modifications to a dirty page.
This can be reproduced with something like:
dd if=/dev/zero of=/xfstest.test/foo bs=1M count=1 umount /xfstest.test mount /xfstest.test xfsio -c "w 0xbbbf 0xf96c" \ -c "truncate 0xbbbf" \ -c "mmap -r 0xb000 0x11000" \ -c "mr 0xb000 0x11000" \ /xfstest.test/foo
with fscaching disabled (otherwise streaming writes are suppressed) and a change to netfsperformwrite() to disallow streaming writes if the fd is open ORDWR:
if (//(file->fmode & FMODEREAD) || <--- comment this out netfsiscacheenabled(ctx)) {
It should be reproducible even without this change, but if prevents the above trivial xfsio command from reproducing it.
Note that the initial dd is important: the file must start out sufficiently large that the zero-point logic doesn't just clear the gaps because it knows there's nothing in the file to read yet. Unmounting and mounting is needed to clear the pagecache (there are other ways to do that that may also work).
This was initially reproduced with the generic/522 xfstest on some patches that remove the FMODEREAD restriction.
In the Linux kernel, the following vulnerability has been resolved:
netfs: fix VMBUGONFOLIO() issue in netfswritebegin() call
The multiple runs of generic/013 test-case is capable to reproduce a kernel BUG at mm/filemap.c:1504 with probability of 30%.
while true; do sudo ./check generic/013 done
[ 9849.452376] page: refcount:3 mapcount:0 mapping:00000000e58ff252 index:0x10781 pfn:0x1c322 [ 9849.452412] memcg:ffff8881a1915800 [ 9849.452417] aops:cephaops ino:1000058db9e dentry name(?):"f9XXXXXX" [ 9849.452432] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff) [ 9849.452441] raw: 0017ffffc0000000 0000000000000000 dead000000000122 ffff88816110d248 [ 9849.452445] raw: 0000000000010781 0000000000000000 00000003ffffffff ffff8881a1915800 [ 9849.452447] page dumped because: VMBUGONFOLIO(!foliotestlocked(folio)) [ 9849.452474] ------------[ cut here ]------------ [ 9849.452476] kernel BUG at mm/filemap.c:1504! [ 9849.478635] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI [ 9849.481772] CPU: 2 UID: 0 PID: 84223 Comm: fsstress Not tainted 7.0.0-rc1+ #18 PREEMPT(full) [ 9849.482881] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-9.fc43 06/1 0/2025 [ 9849.484539] RIP: 0010:foliounlock+0x85/0xa0 [ 9849.485076] Code: 89 df 31 f6 e8 1c f3 ff ff 48 8b 5d f8 c9 31 c0 31 d2 31 f6 31 ff c3 cc cc cc cc 48 c7 c6 80 6c d9 a7 48 89 df e8 4b b3 10 00 <0f> 0b 48 89 df e8 21 e6 2c 00 eb 9d 0f 1f 40 00 66 66 2e 0f 1f 84 [ 9849.493818] RSP: 0018:ffff8881bb8076b0 EFLAGS: 00010246 [ 9849.495740] RAX: 0000000000000000 RBX: ffffea00070c8980 RCX: 0000000000000000 [ 9849.498678] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 9849.500559] RBP: ffff8881bb8076b8 R08: 0000000000000000 R09: 0000000000000000 [ 9849.501097] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000010782000 [ 9849.502108] R13: ffff8881935de738 R14: ffff88816110d010 R15: 0000000000001000 [ 9849.502516] FS: 00007e36cbe94740(0000) GS:ffff88824a899000(0000) knlGS:0000000000000000 [ 9849.502996] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9849.503810] CR2: 000000c0002b0000 CR3: 000000011bbf6004 CR4: 0000000000772ef0 [ 9849.504459] PKRU: 55555554 [ 9849.504626] Call Trace: [ 9849.505242] <TASK> [ 9849.505379] netfswritebegin+0x7c8/0x10a0 [ 9849.505877] ? kasancheckread+0x11/0x20 [ 9849.506384] ? pfxnetfswritebegin+0x10/0x10 [ 9849.507178] cephwritebegin+0x8c/0x1c0 [ 9849.507934] genericperformwrite+0x391/0x8f0 [ 9849.508503] ? pfxgenericperformwrite+0x10/0x10 [ 9849.509062] ? fileupdatetimeflags+0x19a/0x4b0 [ 9849.509581] ? cephgetcaps+0x63/0xf0 [ 9849.510259] ? cephgetcaps+0x63/0xf0 [ 9849.510530] cephwriteiter+0xe79/0x1ae0 [ 9849.511282] ? pfxcephwriteiter+0x10/0x10 [ 9849.511839] ? lockacquire+0x1ad/0x310 [ 9849.512334] ? ksyswrite+0xf9/0x230 [ 9849.512582] ? lockisheldtype+0xaa/0x140 [ 9849.513128] vfswrite+0x512/0x1110 [ 9849.513634] ? fgetfiles+0x33/0x350 [ 9849.513893] ? pfxvfswrite+0x10/0x10 [ 9849.514143] ? mutexlocknested+0x1b/0x30 [ 9849.514394] ksyswrite+0xf9/0x230 [ 9849.514621] ? pfxksyswrite+0x10/0x10 [ 9849.514887] ? dosyscall64+0x25e/0x1520 [ 9849.515122] ? kasancheckread+0x11/0x20 [ 9849.515366] ? tracehardirqsonprepare+0x178/0x1c0 [ 9849.515655] x64syswrite+0x72/0xd0 [ 9849.515885] ? tracehardirqson+0x24/0x1c0 [ 9849.516130] x64syscall+0x22f/0x2390 [ 9849.516341] dosyscall64+0x12b/0x1520 [ 9849.516545] ? dosyscall64+0x27c/0x1520 [ 9849.516783] ? dosyscall64+0x27c/0x1520 [ 9849.517003] ? lockrelease+0x318/0x480 [ 9849.517220] ? x64sysiogetevents+0x143/0x2d0 [ 9849.517479] ? percpurefputmany.constprop.0+0x8f/0x210 [ 9849.517779] ? entrySYSCALL64afterhwframe+0x76/0x7e [ 9849.518073] ? dosyscall64+0x25e/0x1520 [ 9849.518291] ? kasancheckread+0x11/0x20 [ 9849.518519] ? tracehardirqsonprepare+0x178/0x1c0 [ 9849.518799] ? dosyscall64+0x27c/0x1520 [ 9 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix netfsreadtopagecache() to pause on subreq failure
Fix netfsreadtopagecache() so that it pauses the generation of new subrequests if an already-issued subrequest fails.