In the Linux kernel, the following vulnerability has been resolved:
net: gso: Forbid IPv6 TSO with extensions on devices with only IPV6CSUM
When performing Generic Segmentation Offload (GSO) on an IPv6 packet that contains extension headers, the kernel incorrectly requests checksum offload if the egress device only advertises NETIFFIPV6CSUM feature, which has a strict contract: it supports checksum offload only for plain TCP or UDP over IPv6 and explicitly does not support packets with extension headers. The current GSO logic violates this contract by failing to disable the feature for packets with extension headers, such as those used in GREoIPv6 tunnels.
This violation results in the device being asked to perform an operation it cannot support, leading to a skbwarnbadoffload warning and a collapse of network throughput. While device TSO/USO is correctly bypassed in favor of software GSO for these packets, the GSO stack must be explicitly told not to request checksum offload.
Mask NETIFFIPV6CSUM, NETIFFTSO6 and NETIFFGSOUDPL4 in gsofeaturescheck if the IPv6 header contains extension headers to compute checksum in software.
The exception is a BIG TCP extension, which, as stated in commit 68e068cabd2c6c53 ("net: reenable NETIFFIPV6CSUM offload for BIG TCP packets"): "The feature is only enabled on devices that support BIG TCP TSO. The header is only present for PFPACKET taps like tcpdump, and not transmitted by physical devices."
kernel log output (truncated): WARNING: CPU: 1 PID: 5273 at net/core/dev.c:3535 skbwarnbadoffload+0x81/0x140 ... Call Trace: <TASK> skbchecksumhelp+0x12a/0x1f0 validatexmitskb+0x1a3/0x2d0 validatexmitskblist+0x4f/0x80 schdirectxmit+0x1a2/0x380 devxmitskb+0x242/0x670 devqueuexmit+0x3fc/0x7f0 ip6finishoutput2+0x25e/0x5d0 ip6finishoutput+0x1fc/0x3f0 ip6tnlxmit+0x608/0xc00 [ip6tunnel] ip6gretunnelxmit+0x1c0/0x390 [ip6gre] devhardstartxmit+0x63/0x1c0 devqueuexmit+0x6d0/0x7f0 ip6finishoutput2+0x214/0x5d0 ip6finishoutput+0x1fc/0x3f0 ip6xmit+0x2ca/0x6f0 ip6finishoutput+0x1fc/0x3f0 ip6xmit+0x2ca/0x6f0 inet6cskxmit+0xeb/0x150 tcptransmitskb+0x555/0xa80 tcpwritexmit+0x32a/0xe90 tcpsendmsglocked+0x437/0x1110 tcpsendmsg+0x2f/0x50 ... skb linear: 00000000: e4 3d 1a 7d ec 30 e4 3d 1a 7e 5d 90 86 dd 60 0e skb linear: 00000010: 00 0a 1b 34 3c 40 20 11 00 00 00 00 00 00 00 00 skb linear: 00000020: 00 00 00 00 00 12 20 11 00 00 00 00 00 00 00 00 skb linear: 00000030: 00 00 00 00 00 11 2f 00 04 01 04 01 01 00 00 00 skb linear: 00000040: 86 dd 60 0e 00 0a 1b 00 06 40 20 23 00 00 00 00 skb linear: 00000050: 00 00 00 00 00 00 00 00 00 12 20 23 00 00 00 00 skb linear: 00000060: 00 00 00 00 00 00 00 00 00 11 bf 96 14 51 13 f9 skb linear: 00000070: ae 27 a0 a8 2b e3 80 18 00 40 5b 6f 00 00 01 01 skb linear: 00000080: 08 0a 42 d4 50 d5 4b 70 f8 1a
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix soft lockups in fib6selectpath under high next hop churn
Soft lockups have been observed on a cluster of Linux-based edge routers located in a highly dynamic environment. Using the bird service, these routers continuously update BGP-advertised routes due to frequently changing nexthop destinations, while also managing significant IPv6 traffic. The lockups occur during the traversal of the multipath circular linked-list in the fib6selectpath function, particularly while iterating through the siblings in the list. The issue typically arises when the nodes of the linked list are unexpectedly deleted concurrently on a different core—indicated by their 'next' and 'previous' elements pointing back to the node itself and their reference count dropping to zero. This results in an infinite loop, leading to a soft lockup that triggers a system panic via the watchdog timer.
Apply RCU primitives in the problematic code sections to resolve the issue. Where necessary, update the references to fib6siblings to annotate or use the RCU APIs.
Include a test script that reproduces the issue. The script periodically updates the routing table while generating a heavy load of outgoing IPv6 traffic through multiple iperf3 clients. It consistently induces infinite soft lockups within a couple of minutes.
Kernel log:
0 [ffffbd13003e8d30] machinekexec at ffffffff8ceaf3eb 1 [ffffbd13003e8d90] crashkexec at ffffffff8d0120e3 2 [ffffbd13003e8e58] panic at ffffffff8cef65d4 3 [ffffbd13003e8ed8] watchdogtimerfn at ffffffff8d05cb03 4 [ffffbd13003e8f08] hrtimerrunqueues at ffffffff8cfec62f 5 [ffffbd13003e8f70] hrtimerinterrupt at ffffffff8cfed756 6 [ffffbd13003e8fd0] sysvecapictimerinterrupt at ffffffff8cea01af 7 [ffffbd13003e8ff0] sysvecapictimerinterrupt at ffffffff8df1b83d -- <IRQ stack> -- 8 [ffffbd13003d3708] asmsysvecapictimerinterrupt at ffffffff8e000ecb [exception RIP: fib6selectpath+299] RIP: ffffffff8ddafe7b RSP: ffffbd13003d37b8 RFLAGS: 00000287 RAX: ffff975850b43600 RBX: ffff975850b40200 RCX: 0000000000000000 RDX: 000000003fffffff RSI: 0000000051d383e4 RDI: ffff975850b43618 RBP: ffffbd13003d3800 R8: 0000000000000000 R9: ffff975850b40200 R10: 0000000000000000 R11: 0000000000000000 R12: ffffbd13003d3830 R13: ffff975850b436a8 R14: ffff975850b43600 R15: 0000000000000007 ORIGRAX: ffffffffffffffff CS: 0010 SS: 0018 9 [ffffbd13003d3808] ip6polroute at ffffffff8ddb030c 10 [ffffbd13003d3888] ip6polrouteinput at ffffffff8ddb068c 11 [ffffbd13003d3898] fib6rulelookup at ffffffff8ddf02b5 12 [ffffbd13003d3928] ip6routeinput at ffffffff8ddb0f47 13 [ffffbd13003d3a18] ip6rcvfinishcore.constprop.0 at ffffffff8dd950d0 14 [ffffbd13003d3a30] ip6listrcvfinish.constprop.0 at ffffffff8dd96274 15 [ffffbd13003d3a98] ip6sublistrcv at ffffffff8dd96474 16 [ffffbd13003d3af8] ipv6listrcv at ffffffff8dd96615 17 [ffffbd13003d3b60] netifreceiveskblistcore at ffffffff8dc16fec 18 [ffffbd13003d3be0] netifreceiveskblistinternal at ffffffff8dc176b3 19 [ffffbd13003d3c50] napigroreceive at ffffffff8dc565b9 20 [ffffbd13003d3c80] icereceiveskb at ffffffffc087e4f5 [ice] 21 [ffffbd13003d3c90] icecleanrxirq at ffffffffc0881b80 [ice] 22 [ffffbd13003d3d20] icenapipoll at ffffffffc088232f [ice] 23 [ffffbd13003d3d80] napipoll at ffffffff8dc18000 24 [ffffbd13003d3db8] netrxaction at ffffffff8dc18581 25 [ffffbd13003d3e40] dosoftirq at ffffffff8df352e9 26 [ffffbd13003d3eb0] runksoftirqd at ffffffff8ceffe47 27 [ffffbd13003d3ec0] smpbootthreadfn at ffffffff8cf36a30 28 [ffffbd13003d3ee8] kthread at ffffffff8cf2b39f 29 [ffffbd13003d3f28] retfromfork at ffffffff8ce5fa64 30 [ffffbd13003d3f50] retfromforkasm at ffffffff8ce03cbb
In the Linux kernel, the following vulnerability has been resolved:
block: fix uaf for flush rq while iterating tags
blkmqclearflushrqmapping() is not called during scsi probe, by checking blkqueueinitdone(). However, QUEUEFLAGINITDONE is cleared in delgendisk by commit aec89dc5d421 ("block: keep qusagecounter in atomic mode after delgendisk"), hence for disk like scsi, following blkmqdestroyqueue() will not clear flush rq from tags->rqs[] as well, cause following uaf that is found by our syzkaller for v6.6:
================================================================== BUG: KASAN: slab-use-after-free in blkmqfindandgetreq+0x16e/0x1a0 block/blk-mq-tag.c:261 Read of size 4 at addr ffff88811c969c20 by task kworker/1:2H/224909
CPU: 1 PID: 224909 Comm: kworker/1:2H Not tainted 6.6.0-ga836a5060850 #32 Workqueue: kblockd blkmqtimeoutwork Call Trace:
dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x91/0xf0 lib/dumpstack.c:106 printaddressdescription.constprop.0+0x66/0x300 mm/kasan/report.c:364 printreport+0x3e/0x70 mm/kasan/report.c:475 kasanreport+0xb8/0xf0 mm/kasan/report.c:588 blkmqfindandgetreq+0x16e/0x1a0 block/blk-mq-tag.c:261 btiter block/blk-mq-tag.c:288 [inline] sbitmapforeachset include/linux/sbitmap.h:295 [inline] sbitmapforeachset include/linux/sbitmap.h:316 [inline] btforeach+0x455/0x790 block/blk-mq-tag.c:325 blkmqqueuetagbusyiter+0x320/0x740 block/blk-mq-tag.c:534 blkmqtimeoutwork+0x1a3/0x7b0 block/blk-mq.c:1673 processonework+0x7c4/0x1450 kernel/workqueue.c:2631 processscheduledworks kernel/workqueue.c:2704 [inline] workerthread+0x804/0xe40 kernel/workqueue.c:2785 kthread+0x346/0x450 kernel/kthread.c:388 retfromfork+0x4d/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1b/0x30 arch/x86/entry/entry64.S:293
Allocated by task 942: kasansavestack+0x22/0x50 mm/kasan/common.c:45 kasansettrack+0x25/0x30 mm/kasan/common.c:52 kasankmalloc mm/kasan/common.c:374 [inline] kasankmalloc mm/kasan/common.c:383 [inline] kasankmalloc+0xaa/0xb0 mm/kasan/common.c:380 kasankmalloc include/linux/kasan.h:198 [inline] dokmallocnode mm/slabcommon.c:1007 [inline] kmallocnode+0x69/0x170 mm/slabcommon.c:1014 kmallocnode include/linux/slab.h:620 [inline] kzallocnode include/linux/slab.h:732 [inline] blkallocflushqueue+0x144/0x2f0 block/blk-flush.c:499 blkmqallochctx+0x601/0x940 block/blk-mq.c:3788 blkmqallocandinithctx+0x27f/0x330 block/blk-mq.c:4261 blkmqreallochwctxs+0x488/0x5e0 block/blk-mq.c:4294 blkmqinitallocatedqueue+0x188/0x860 block/blk-mq.c:4350 blkmqinitqueuedata block/blk-mq.c:4166 [inline] blkmqinitqueue+0x8d/0x100 block/blk-mq.c:4176 scsiallocsdev+0x843/0xd50 drivers/scsi/scsiscan.c:335 scsiprobeandaddlun+0x77c/0xde0 drivers/scsi/scsiscan.c:1189 scsiscantarget+0x1fc/0x5a0 drivers/scsi/scsiscan.c:1727 scsiscanchannel drivers/scsi/scsiscan.c:1815 [inline] scsiscanchannel+0x14b/0x1e0 drivers/scsi/scsiscan.c:1791 scsiscanhostselected+0x2fe/0x400 drivers/scsi/scsiscan.c:1844 scsiscan+0x3a0/0x3f0 drivers/scsi/scsisysfs.c:151 storescan+0x2a/0x60 drivers/scsi/scsisysfs.c:191 devattrstore+0x5c/0x90 drivers/base/core.c:2388 sysfskfwrite+0x11c/0x170 fs/sysfs/file.c:136 kernfsfopwriteiter+0x3fc/0x610 fs/kernfs/file.c:338 callwriteiter include/linux/fs.h:2083 [inline] newsyncwrite+0x1b4/0x2d0 fs/readwrite.c:493 vfswrite+0x76c/0xb00 fs/readwrite.c:586 ksyswrite+0x127/0x250 fs/readwrite.c:639 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x70/0x120 arch/x86/entry/common.c:81 entrySYSCALL64afterhwframe+0x78/0xe2
Freed by task 244687: kasansavestack+0x22/0x50 mm/kasan/common.c:45 kasansettrack+0x25/0x30 mm/kasan/common.c:52 kasansavefreeinfo+0x2b/0x50 mm/kasan/generic.c:522 kasanslabfree mm/kasan/common.c:236 [inline] kasanslabfree+0x12a/0x1b0 mm/kasan/common.c:244 kasanslabfree include/linux/kasan.h:164 [in ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
HID: hid-goodix-spi: validate report size to prevent stack buffer overflow
goodixhidsetrawreport() builds a protocol frame in a 128-byte stack buffer (tmpbuf), writing an 11-12 byte header followed by the caller-supplied report data. The HID core caps report size at HIDMAXBUFFERSIZE (16384) by default, while the driver does not set hidlldriver.maxbuffersize and performs no bounds checking before copying the payload:
memcpy(tmpbuf + txlen, buf, len);
A hidraw SETREPORT ioctl with a report larger than ~116 bytes overflows the stack buffer.
Add a size check after constructing the header, rejecting reports that would exceed the buffer capacity.
Discovered by Atuin - Automated Vulnerability Discovery Engine.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: handle unreadable frags
sashiko reports: When an skb with unreadable fragments (such as from devmem TCP, where skbfragsreadable(skb) returns false) is processed by the u32 module, skbcopybits() will safely return a negative error code [..]
xtu32: bail out with hotdrop in this case. gatherfrags: return -1, just as if we had no fragment header. nfnetlinkqueue: restrict to the linear part. nfnetlinklog: restrict to the linear part.
v2: - skbzerocopy helpers don't copy readable flag, i.e. nfnetlinkqueue is broken too xtu32 shouldn't return true if hotdrop was set.
In the Linux kernel, the following vulnerability has been resolved:
mm/swap: add condresched() in swapreclaimfullclusters to prevent softlockup
We hit a real softlockup in an internal stress test environment. The workload was LTP memory/swap stress on a large arm64 machine, with 320 CPUs, about 1TB memory and an 8.6GB swap device. The system was under heavy load and the swap device had a large number of full clusters. The softlockup was triggered during a stress test after about 3 days.
So, add periodic condresched() calls during large fullclusters reclaim operations to prevent softlockup issues.
Detailed call trace as follow:
PID: 3817773 TASK: ffff0883bb28b780 CPU: 48 COMMAND: "kworker/48:7" #0 [ffff800080183d10] crashkexec at ffffa4c1361e5de4 #1 [ffff800080183d90] panic at ffffa4c1360d5e9c #2 [ffff800080183e20] watchdogtimerfn at ffffa4c136231fa8 ... #16 [ffff8000c4ad3cb0] swapcachedelfolio at ffffa4c1363e1614 #17 [ffff8000c4ad3ce0] trytoreclaimswap at ffffa4c1363e4bfc #18 [ffff8000c4ad3d40] swapreclaimfullclusters at ffffa4c1363e5474 #19 [ffff8000c4ad3da0] swapreclaimwork at ffffa4c1363e550c #20 [ffff8000c4ad3dc0] processonework at ffffa4c136102edc #21 [ffff8000c4ad3e10] workerthread at ffffa4c136103398 #22 [ffff8000c4ad3e70] kthread at ffffa4c13610d95c
In the Linux kernel, the following vulnerability has been resolved:
mm: swapcgroup: fix NULL deref in lookupswapcgroupid on swapless host
lookupswapcgroupid() passes swapcgroupctrl[type].map to swapcgroupidlookup() without checking that the type was ever registered via swapcgroupswapon(). On a swapless host every ctrl->map is NULL, so swapcgroupidlookup() dereferences NULL + a scaled swpoffset().
Since commit bea67dcc5eea ("mm: attempt to batch free swap entries for zappterange()"), zappterange() -> swapptebatch() calls lookupswapcgroupid() on any non-present, non-none PTE that decodes as a real swap entry, without first validating it against swapinfo[]. A single PTE corrupted into a type-0 swap entry takes the host down at process exit.
We hit this in production on a swapless 6.12.58 host: ~1s of "getswapdevice: Bad swap file entry 3f800204222bb" (doswappage() being correctly defensive about the same entry) followed by
BUG: unable to handle page fault for address: 000003f800204220 RIP: 0010:lookupswapcgroupid+0x2b/0x60 Call Trace: swapptebatch+0xbf/0x230 zappterange+0x4c8/0x780 unmappagerange+0x190/0x3e0 exitmmap+0xd9/0x3c0 doexit+0x20c/0x4b0
syzbot has reported the identical stack.
The source of the PTE corruption is a separate bug; this change makes the teardown path as robust as the fault path already is. Every other caller of lookupswapcgroupid() is downstream of a getswapdevice() that has already validated the entry, so the new branch is cold.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Validate BTF repeated field counts before expansion
btfparsestructmetas() walks user-supplied BTF during BPFBTFLOAD, and btfrepeatfields() expands repeatable fields from array elements into the fixed BTFFIELDSMAX scratch array used by btfparsefields().
The remaining-capacity check performs the expanded field count calculation in u32. A malformed BTF can wrap that calculation, causing the check to pass even when the expanded field count exceeds the scratch array capacity. The following memcpy() can then write past the end of the array.
Use checked addition and multiplication before copying repeated fields and reject impossible counts.
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.
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix netfsreadfolio() to wait on writeback
Fix netfsreadfolio() to wait for an ongoing writeback to complete so that it can trust the dirty flag and whatever is attached to folio->private (folio->private may get cleaned up by the collector before it clears the writeback flag).
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix folio->private handling in netfsperformwrite()
Under some circumstances, netfsperformwrite() doesn't correctly manipulate folio->private between NULL, NETFSFOLIOCOPYTOCACHE, pointing to a group and pointing to a netfsfolio struct, leading to potential multiple attachments of private data with associated folio ref leaks and also leaks of netfsfolio structs or netfsgroup refs.
Fix this by consolidating the place at which a folio is marked uptodate in one place and having that look at what's attached to folio->private and decide how to clean it up and then set the new group. Also, the content shouldn't be flushed if group is NULL, even if a group is specified in the netfsgroup parameter, as that would be the case for a new folio. A filesystem should always specify netfsgroup or never specify netfsgroup.
The Sashiko auto-review tool noted that it was theoretically possible that the fpos >= ctx->zeropoint section might leak if it modified a streaming write folio. This is unlikely, but with a network filesystem, third party changes can happen. It also pointed out that netfssetgroup() would leak if called multiple times on the same folio from the "whole folio modify section".
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix early put of sink folio in netfsreadgaps()
Fix netfsreadgaps() to release the sink page it uses after waiting for the request to complete. The way the sink page is used is that an ITERBVEC-class iterator is created that has the gaps from the target folio at either end, but has the sink page tiled over the middle so that a single read op can fill in both gaps.
The bug was found by KASAN detecting a UAF on the generic/075 xfstest in the cifsd kernel thread that handles reception of data from the TCP socket:
BUG: KASAN: use-after-free in copytoiter+0x48a/0xa20 Write of size 885 at addr ffff888107f92000 by task cifsd/1285 CPU: 2 UID: 0 PID: 1285 Comm: cifsd Not tainted 7.0.0 #6 PREEMPT(lazy) Call Trace: dumpstacklvl+0x5d/0x80 printreport+0x17f/0x4f1 kasanreport+0x100/0x1e0 kasancheckrange+0x10f/0x1e0 asanmemcpy+0x3c/0x60 copytoiter+0x48a/0xa20 skbdatagramiter+0x2c9/0x430 skbcopydatagramiter+0x6e/0x160 tcprecvmsglocked+0xce0/0x1130 tcprecvmsg+0xeb/0x300 inetrecvmsg+0xcf/0x3a0 sockrecvmsg+0xea/0x100 cifsreadvfromsocket+0x3a6/0x4d0 [cifs] cifsreaditerfromsocket+0xdd/0x130 [cifs] cifsreadvreceive+0xaad/0xb10 [cifs] cifsdemultiplexthread+0x1148/0x1740 [cifs] kthread+0x1cf/0x210
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix streaming write being overwritten
In order to avoid reading whilst writing, netfslib will allow "streaming writes" in which dirty data is stored directly into folios without reading them first. Such folios are marked dirty but may not be marked uptodate. If a folio is entirely written by a streaming write, uptodate will be set, otherwise it will have a netfsfolio struct attached to ->private recording the dirty region.
In the event that a partially written streaming write page is to be overwritten entirely by a single write(), netfsperformwrite() will try to copy over it, but doesn't discard the netfsfolio if it succeeds; further, it doesn't correctly handle a partial copy that overwrites some of the dirty data.
Fix this by the following:
(1) If the folio is successfully overwritten, free the netfsfolio struct before marking the page uptodate.
(2) If the copy to the folio partially fails, but short of the dirty data, just ignore the copy.
(3) If the copy partially fails and overwrites some of the dirty data, accept the copy, update the netfsfolio struct to record the new data. If the folio is now filled, free the netfsfolio and set uptodate, otherwise return a partial write.
Found with:
fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \ /xfstest.test/junk --replay-ops=junk.fsxops
using the following as junk.fsxops:
truncate 0x0 0 0x927c0 write 0x63fb8 0x53c8 0 copyrange 0xb704 0x19b9 0x24429 0x79380 write 0x2402b 0x144a2 0x90660 write 0x204d5 0x140a0 0x927c0 copyrange 0x1f72c 0x137d0 0x7a906 0x927c0 read 0x00000 0x20000 0x9157c read 0x20000 0x20000 0x9157c read 0x40000 0x20000 0x9157c read 0x60000 0x20000 0x9157c read 0x7e1a0 0xcfb9 0x9157c
on cifs with the default cache option.
It shows folio 0x24 misbehaving if the FMODEREAD check is commented out in netfsperformwrite():
if (//(file->fmode & FMODEREAD) || netfsiscacheenabled(ctx)) {
and no fscache. This was initially found with the generic/522 xfstest.
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Fix out of bounds reads when finding clock sources
The current USB-audio driver code doesn't check bLength of each descriptor at traversing for clock descriptors. That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads.
For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal. When the descriptor length is shorter than expected, it's skipped in the loop.
For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check.
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices
A bogus device can provide a bNumConfigurations value that exceeds the initial value used in usbgetconfiguration for allocating dev->config.
This can lead to out-of-bounds accesses later, e.g. in usbdestroyconfiguration.
In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Skip parsing frames of type UVCVSUNDEFINED in uvcparseformat
This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvcparsestreaming.
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix potential UAF in netfsunlockabandonedreadpages()
netfsunlockabandonedreadpages(rreq) accesses the index of the folios it is wanting to unlock and compares that to rreq->nounlockfolio so that it doesn't unlock a folio being read for netfsperformwrite() or netfswritebegin().
However, given that netfsunlockabandonedreadpages() is called after NETFSRREQINPROGRESS is cleared, the one folio that it's not allowed to dereference is the one specified by ->nounlockfolio as ownership immediately reverts to the caller.
Fix this by storing the folio pointer instead and using that rather than the index. Also fix netfsunlockreadfolio() where the same applies.
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Ensure vendor's exit handler runs before fastpath userspace exits
Move the handling of fastpath userspace exits into vendor code to ensure KVM runs vendor specific operations that need to run before userspace gains control of the vCPU. E.g. for VMX (and soon to be for SVM as well), KVM needs to flush the PML buffer prior to exiting to userspace, otherwise any memory written by the final KVMRUN might never be flagged as dirty.
Note, waiting to snapshot CR0 and CR3 until svmhandleexit() is flawed in general, as that risks consuming stale state in a fastpath handler. That will be addressed in a future change.
In the Linux kernel, the following vulnerability has been resolved:
spi: ep93xx: fix error pointer deref after DMA setup failure
The driver falls back to PIO mode if DMA setup fails during probe.
Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer on later probe errors or driver unbind.
This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.
In the Linux kernel, the following vulnerability has been resolved:
schedext: Avoid UAF in scxrootenableworkfn() init failure path
In scxrootenableworkfn(), puttaskstruct(p) is called before scxerror() dereferences p->comm and p->pid. If the iterator's reference is the last drop, the task is freed synchronously and the deref becomes a UAF.
Move puttaskstruct() past scxerror().
In the Linux kernel, the following vulnerability has been resolved:
block: recompute nrintegritysegments in blkinsertclonedrequest
blkinsertclonedrequest() already recomputes nrphyssegments against the bottom queue, because "the queue settings related to segment counting may differ from the original queue." The exact same reasoning applies to integrity segments: a stacked driver's underlying queue can have tighter virtboundarymask, segboundarymask, or maxsegmentsize than the top queue, in which case blkrqcountintegritysg() against the bottom queue produces a different count than the cached rq->nrintegritysegments inherited from the source request by blkrqprepclone().
When the cached count is lower than the bottom queue's actual count, blkrqmapintegritysg() trips
BUGON(segments > rq->nrintegritysegments);
on dispatch. The same families of stacked setups that motivated the existing nrphyssegments recompute -- dm-multipath fanning out to nvme-rdma in particular -- can produce this.
Mirror the nrphyssegments handling: when the request carries integrity, recompute nrintegritysegments against the bottom queue and reject the request if it exceeds the bottom queue's maxintegritysegments. blkrqcountintegritysg() and queuemaxintegritysegments() are both already available via <linux/blk-integrity.h>, which blk-mq.c includes.
This closes a latent gap in the stacking contract and brings the integrity-segment accounting in line with the existing phys-segment accounting.
In the Linux kernel, the following vulnerability has been resolved:
mm: swap: fix potential buffer overflow in setupclusters()
In setupswapmap(), we only ensure badpages are in range (0, lastpage]. As maxpages might be < lastpage, setupclusters() will encounter a buffer overflow when a badpage is >= maxpages.
Only call incclusterinfopage() for badpage which is < maxpages to fix the issue.
In the Linux kernel, the following vulnerability has been resolved:
fsnotify: Fix ordering of iput() and watchedobjects decrement
Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watchedobjects count elevated, so iput() must happen before the watchedobjects decrement. This can lead to a UAF of something like sb->sfsinfo in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECKDATACORRUPTION() block in genericshutdownsuper().
Also, ensure that fsnotifyputsbwatchedobjects() doesn't call fsnotifysbwatchedobjects() on a superblock that may have already been freed, which would cause a UAF read of sb->sfsnotifyinfo.
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Fix error cleanup in xeexecqueuecreateioctl()
Two error handling issues exist in xeexecqueuecreateioctl():
1. When xehwenginegroupaddexecqueue() fails, the error path jumps to putexecqueue which skips xeexecqueuekill(). If the VM is in preempt fence mode, xevmaddcomputeexecqueue() has already added the queue to the VM's compute exec queue list. Skipping the kill leaves the queue on that list, leading to a dangling pointer after the queue is freed.
2. When xaalloc() fails after xehwenginegroupaddexecqueue() has succeeded, the error path does not call xehwenginegroupdelexecqueue() to remove the queue from the hw engine group list. The queue is then freed while still linked into the hw engine group, causing a use-after-free.
Fix both by: - Changing the xehwenginegroupaddexecqueue() failure path to jump to killexecqueue so that xeexecqueuekill() properly removes the queue from the VM's compute list. - Adding a delhwenginegroup label before killexecqueue for the xaalloc() failure path, which removes the queue from the hw engine group before proceeding with the rest of the cleanup.
(cherry picked from commit 37c831f401746a45d510b312b0ed7a77b1e06ec8)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: fncm: validate minimum blocklen in ncmunwrapntb()
The blocklen read from the host-supplied NTB header is checked against ntbmax but has no lower bound. When blocklen is smaller than opts->ndpsize, the bounds check of: ndpindex > (blocklen - opts->ndpsize) will underflow producing a huge unsigned value that ndpindex can never exceed, defeating the check entirely.
The same underflow occurs in the datagram index checks against blocklen - opts->dpesize. With those checks neutered, a malicious USB host can choose ndpindex and datagram offsets that point past the actual transfer, and the skbputdata() copies adjacent kernel memory into the network skb.
Fix this by rejecting block lengths that cannot hold at least the NTB header plus one NDP. This will make blocklen - opts->ndpsize and blocklen - opts->dpesize both well-defined.
Commit 8d2b1a1ec9f5 ("CDC-NCM: avoid overflow in sanity checking") fixed a related class of issues on the host side of NCM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation
walks1() and kvmwalknesteds2() expect to be called while holding kvm->srcu to guard against memslot changes. While this is generally the case, kvmats12() and kvmfinds1desclevel() call into the respective walkers without taking kvm->srcu.
Fix by acquiring kvm->srcu prior to the table walk in both instances.
In the Linux kernel, the following vulnerability has been resolved:
In the Linux kernel, the following vulnerability has been resolved:
ALSA: timer: Forcibly close timer instances at closing
When sndtimer object is freed via sndtimerfree() and still pending sndtimerinstance objects are assigned to the timer object, it tries to unlink all instances and just set NULL to each ti->timer, then releases the resources immediately. The problem is, however, when there are slave timer instances that are associated with a master instance linked to this timer: namely, those slave instances still point to the freed timer object although the master instance is unlinked, which may lead to user-after-free. The bug can be easily triggered particularly when a new userspace-driven timers (CONFIGSNDUTIMER) is involved, since it can create and delete the timer object via a simple file open/close, while the other applications may keep accessing to that timer.
This patch is an attempt to paper over the problem above: now instead of just unlinking, call sndtimercloselocked forcibly for each pending timer instance, so that all assigned slave timer instances are properly detached, too. Since sndtimerclose() might be called later by the driver that created that instance, the check of SNDRVTIMERIFLGDEAD is added at the beginning, too.
In the Linux kernel, the following vulnerability has been resolved:
ALSA: timer: Fix UAF at sndtimeruserparams()
At releasing a timer object, e.g. when a userspace timer (CONFIGSNDUTIMER) gets closed and sndtimerfree() is called, it tries to detach the timer instances and release the resources. However, it's still possible that other in-flight tasks are holding the timer instance where the to-be-deleted timer object is associated, and this may lead to racy accesses.
Fortunately, most of ioctls dealing with the timer instance list already have the protection with registermutex, and this also avoids such races. But, SNDRVTIMERIOCTLPARAMS isn't protected, hence the concurrent ioctl may lead to use-after-free.
This patch just adds the guard with registermutex to protect sndtimeruserparams() for covering the code path as a quick workaround. It's no hot-path but rather a rarely issued ioctl, so the performance penalty doesn't matter.