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

btrfs: fix chunk map leak in btrfsmapblock() after btrfschunkmapnumcopies()

Fix a chunk map leak in btrfsmapblock(): if we return early with -EINVAL, we're not freeing the chunk map that we've just looked up.

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

nsfs: tighten permission checks for ns iteration ioctls

Even privileged services should not necessarily be able to see other privileged service's namespaces so they can't leak information to each other. Use mayseeallnamespaces() helper that centralizes this policy until the nstree adapts.

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

ALSA: 6fire: fix use-after-free on disconnect

In usb6firechipabort(), the chip struct is allocated as the card's private data (via sndcardnew with sizeof(struct sfirechip)). When sndcardfreewhenclosed() is called and no file handles are open, the card and embedded chip are freed synchronously. The subsequent chip->card = NULL write then hits freed slab memory.

Call trace: usb6firechipabort sound/usb/6fire/chip.c:59 [inline] usb6firechipdisconnect+0x348/0x358 sound/usb/6fire/chip.c:182 usbunbindinterface+0x1a8/0x88c drivers/usb/core/driver.c:458 ... hubevent+0x1a04/0x4518 drivers/usb/core/hub.c:5953

Fix by moving the card lifecycle out of usb6firechipabort() and into usb6firechipdisconnect(). The card pointer is saved in a local before any teardown, sndcarddisconnect() is called first to prevent new opens, URBs are aborted while chip is still valid, and sndcardfreewhenclosed() is called last so chip is never accessed after the card may be freed.

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

mm: filemap: fix nrpages calculation overflow in filemapmappages()

When running stress-ng on my Arm64 machine with v7.0-rc3 kernel, I encountered some very strange crash issues showing up as "Bad page state":

" [ 734.496287] BUG: Bad page state in process stress-ng-env pfn:415735fb [ 734.496427] page: refcount:0 mapcount:1 mapping:0000000000000000 index:0x4cf316 pfn:0x415735fb [ 734.496434] flags: 0x57fffe000000800(owner2|node=1|zone=2|lastcpupid=0x3ffff) [ 734.496439] raw: 057fffe000000800 0000000000000000 dead000000000122 0000000000000000 [ 734.496440] raw: 00000000004cf316 0000000000000000 0000000000000000 0000000000000000 [ 734.496442] page dumped because: nonzero mapcount "

After analyzing this page’s state, it is hard to understand why the mapcount is not 0 while the refcount is 0, since this page is not where the issue first occurred. By enabling the CONFIGDEBUGVM config, I can reproduce the crash as well and captured the first warning where the issue appears:

" [ 734.469226] page: refcount:33 mapcount:0 mapping:00000000bef2d187 index:0x81a0 pfn:0x415735c0 [ 734.469304] head: order:5 mapcount:0 entiremapcount:0 nrpagesmapped:0 pincount:0 [ 734.469315] memcg:ffff000807a8ec00 [ 734.469320] aops:ext4daaops ino:100b6f dentry name(?):"stress-ng-mmaptorture-9397-0-2736200540" [ 734.469335] flags: 0x57fffe400000069(locked|uptodate|lru|head|node=1|zone=2|lastcpupid=0x3ffff) ...... [ 734.469364] page dumped because: VMWARNONFOLIO((Generic((page + nrpages - 1), const struct page : (const struct folio )compoundhead(page + nrpages - 1), struct page : (struct folio )compoundhead(page + nrpages - 1))) != folio) [ 734.469390] ------------[ cut here ]------------ [ 734.469393] WARNING: ./include/linux/rmap.h:351 at folioaddfilermapptes+0x3b8/0x468, CPU#90: stress-ng-mlock/9430 [ 734.469551] folioaddfilermapptes+0x3b8/0x468 (P) [ 734.469555] setpterange+0xd8/0x2f8 [ 734.469566] filemapmapfoliorange+0x190/0x400 [ 734.469579] filemapmappages+0x348/0x638 [ 734.469583] dofaultaround+0x140/0x198 ...... [ 734.469640] el0t64sync+0x184/0x188 "

The code that triggers the warning is: "VMWARNONFOLIO(pagefolio(page + nrpages - 1) != folio, folio)", which indicates that setpterange() tried to map beyond the large folio’s size.

By adding more debug information, I found that 'nrpages' had overflowed in filemapmappages(), causing setpterange() to establish mappings for a range exceeding the folio size, potentially corrupting fields of pages that do not belong to this folio (e.g., page->mapcount).

After above analysis, I think the possible race is as follows:

CPU 0 CPU 1 filemapmappages() ext4setattr() //get and lock folio with old inode->isize nextuptodatefolio()

....... //shrink the inode->isize isizewrite(inode, attr->iasize);

//calculate the endpgoff with the new inode->isize fileend = DIVROUNDUP(isizeread(mapping->host), PAGESIZE) - 1; endpgoff = min(endpgoff, fileend);

...... //nrpages can be overflowed, cause xas.xaindex > endpgoff end = folionextindex(folio) - 1; nrpages = min(end, endpgoff) - xas.xaindex + 1;

...... //map large folio filemapmapfoliorange() ...... //truncate folios truncatepagecache(inode, inode->isize);

To fix this issue, move the 'endpgoff' calculation before nextuptodatefolio(), so the retrieved folio stays consistent with the file end to avoid ---truncated---

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

bcache: fix cacheddev.sbbio use-after-free and crash

In our production environment, we have received multiple crash reports regarding libceph, which have caught our attention:

[6888366.280350] Call Trace: [6888366.280452] blkupdaterequest+0x14e/0x370 [6888366.280561] blkmqendrequest+0x1a/0x130 [6888366.280671] rbdimghandlerequest+0x1a0/0x1b0 [rbd] [6888366.280792] rbdobjhandlerequest+0x32/0x40 [rbd] [6888366.280903] completerequest+0x22/0x70 [libceph] [6888366.281032] osddispatch+0x15e/0xb40 [libceph] [6888366.281164] ? inetrecvmsg+0x5b/0xd0 [6888366.281272] ? cephtcprecvmsg+0x6f/0xa0 [libceph] [6888366.281405] cephconprocessmessage+0x79/0x140 [libceph] [6888366.281534] cephconv1tryread+0x5d7/0xf30 [libceph] [6888366.281661] cephconworkfn+0x329/0x680 [libceph]

After analyzing the coredump file, we found that the address of dc->sbbio has been freed. We know that cacheddev is only freed when it is stopped.

Since sbbio is a part of struct cacheddev, rather than an alloc every time. If the device is stopped while writing to the superblock, the released address will be accessed at endio.

This patch hopes to wait for sbwrite to complete in cacheddevfree.

It should be noted that we analyzed the cause of the problem, then tell all details to the QWEN and adopted the modifications it made.

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

media: em28xx: fix use-after-free in em28xxv4l2open()

em28xxv4l2open() reads dev->v4l2 without holding dev->lock, creating a race with em28xxv4l2init()'s error path and em28xxv4l2fini(), both of which free the em28xxv4l2 struct and set dev->v4l2 to NULL under dev->lock.

This race leads to two issues: - use-after-free in v4l2fhinit() when accessing vdev->ctrlhandler, since the videodevice is embedded in the freed em28xxv4l2 struct. - NULL pointer dereference in em28xxresolutionset() when accessing v4l2->norm, since dev->v4l2 has been set to NULL.

Fix this by moving the mutexlock() before the dev->v4l2 read and adding a NULL check for dev->v4l2 under the lock.

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

schedext: Remove redundant cssput() in scxcgroupinit()

The iterator cssforeachdescendantpre() walks the cgroup hierarchy under cgrouplock(). It does not increment the reference counts on yielded css structs.

According to the cgroup documentation, cssput() should only be used to release a reference obtained via cssget() or csstrygetonline(). Since the iterator does not use either of these to acquire a reference, calling cssput() in the error path of scxcgroupinit() causes a refcount underflow.

Remove the unbalanced cssput() to prevent a potential Use-After-Free (UAF) vulnerability.

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

schedext: Fix stale direct dispatch state in ddspdsqid

@p->scx.ddspdsqid can be left set (non-SCXDSQINVALID) triggering a spurious warning in markdirectdispatch() when the next wakeup's ops.selectcpu() calls scxbpfdsqinsert(), such as:

WARNING: kernel/sched/ext.c:1273 at scxdsqinsertcommit+0xcd/0x140

The root cause is that ddspdsqid was only cleared in dispatchenqueue(), which is not reached in all paths that consume or cancel a direct dispatch verdict.

Fix it by clearing it at the right places:

- directdispatch(): cache the direct dispatch state in local variables and clear it before dispatchenqueue() on the synchronous path. For the deferred path, the direct dispatch state must remain set until processddspdeferredlocals() consumes them.

- processddspdeferredlocals(): cache the dispatch state in local variables and clear it before calling dispatchtolocaldsq(), which may migrate the task to another rq.

- doenqueuetask(): clear the dispatch state on the enqueue path (local/global/bypass fallbacks), where the direct dispatch verdict is ignored.

- dequeuetaskscx(): clear the dispatch state after dispatchdequeue() to handle both the deferred dispatch cancellation and the holdingcpu race, covering all cases where a pending direct dispatch is cancelled.

- scxdisabletask(): clear the direct dispatch state when transitioning a task out of the current scheduler. Waking tasks may have had the direct dispatch state set by the outgoing scheduler's ops.selectcpu() and then been queued on a wakelist via ttwuqueuewakelist(), when SCXOPSALLOWQUEUEDWAKEUP is set. Such tasks are not on the runqueue and are not iterated by scxbypass(), so their direct dispatch state won't be cleared. Without this clear, any subsequent SCX scheduler that tries to direct dispatch the task will trigger the WARNONONCE() in markdirectdispatch().

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

mm/pagewalk: fix race between concurrent split and refault

The splitting of a PUD entry in walkpudrange() can race with a concurrent thread refaulting the PUD leaf entry causing it to try walking a PMD range that has disappeared.

An example and reproduction of this is to try reading numamaps of a process while VFIO-PCI is setting up DMA (specifically the vfiopinpagesremote call) on a large BAR for that process.

This will trigger a kernel BUG: vfio-pci 0000:03:00.0: enabling device (0000 -> 0002) BUG: unable to handle page fault for address: ffffa23980000000 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI ... RIP: 0010:walkpgdrange+0x3b5/0x7a0 Code: 8d 43 ff 48 89 44 24 28 4d 89 ce 4d 8d a7 00 00 20 00 48 8b 4c 24 28 49 81 e4 00 00 e0 ff 49 8d 44 24 ff 48 39 c8 4c 0f 43 e3 <49> f7 06 9f ff ff ff 75 3b 48 8b 44 24 20 48 8b 40 28 48 85 c0 74 RSP: 0018:ffffac23e1ecf808 EFLAGS: 00010287 RAX: 00007f44c01fffff RBX: 00007f4500000000 RCX: 00007f44ffffffff RDX: 0000000000000000 RSI: 000ffffffffff000 RDI: ffffffff93378fe0 RBP: ffffac23e1ecf918 R08: 0000000000000004 R09: ffffa23980000000 R10: 0000000000000020 R11: 0000000000000004 R12: 00007f44c0200000 R13: 00007f44c0000000 R14: ffffa23980000000 R15: 00007f44c0000000 FS: 00007fe884739580(0000) GS:ffff9b7d7a9c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa23980000000 CR3: 000000c0650e2005 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> walkpagerange+0x195/0x1b0 walkpagevma+0x62/0xc0 shownumamap+0x12b/0x3b0 seqreaditer+0x297/0x440 seqread+0x11d/0x140 vfsread+0xc2/0x340 ksysread+0x5f/0xe0 dosyscall64+0x68/0x130 ? getpagefromfreelist+0x5c2/0x17e0 ? masstoreprealloc+0x17e/0x360 ? vmasetpageprot+0x4c/0xa0 ? allocpagesnoprof+0x14e/0x2d0 ? modmemcglruvecstate+0x8d/0x140 ? lruvecstatmodfolio+0x76/0xb0 ? foliomodstat+0x26/0x80 ? doanonymouspage+0x705/0x900 ? handlemmfault+0xa8d/0x1000 ? countmemcgevents+0x53/0xf0 ? handlemmfault+0xa5/0x360 ? douseraddrfault+0x342/0x640 ? archexittousermodeprepare.constprop.0+0x16/0xa0 ? irqentryexittousermode+0x24/0x100 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7fe88464f47e Code: c0 e9 b6 fe ff ff 50 48 8d 3d be 07 0b 00 e8 69 01 02 00 66 0f 1f 84 00 00 00 00 00 64 8b 04 25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d 00 f0 ff ff 77 5a c3 66 0f 1f 84 00 00 00 00 00 48 83 ec 28 RSP: 002b:00007ffe6cd9a9b8 EFLAGS: 00000246 ORIGRAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007fe88464f47e RDX: 0000000000020000 RSI: 00007fe884543000 RDI: 0000000000000003 RBP: 00007fe884543000 R08: 00007fe884542010 R09: 0000000000000000 R10: fffffffffffffbc5 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 </TASK>

Fix this by validating the PUD entry in walkpmdrange() using a stable snapshot (pudpget()). If the PUD is not present or is a leaf, retry the walk via ACTIONAGAIN instead of descending further. This mirrors the retry logic in walkpterange(), which lets walkpmdrange() retry if the PTE is not being got by pteoffsetmaplock().

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

netfs: Fix read abandonment during retry

Under certain circumstances, all the remaining subrequests from a read request will get abandoned during retry. The abandonment process expects the 'subreq' variable to be set to the place to start abandonment from, but it doesn't always have a useful value (it will be uninitialised on the first pass through the loop and it may point to a deleted subrequest on later passes).

Fix the first jump to "abandon:" to set subreq to the start of the first subrequest expected to need retry (which, in this abandonment case, turned out unexpectedly to no longer have NEEDRETRY set).

Also clear the subreq pointer after discarding superfluous retryable subrequests to cause an oops if we do try to access it.

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:

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:

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:

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:

usb: gadget: renesasusb3: validate endpoint index in standard request handlers

The GETSTATUS and SET/CLEARFEATURE handlers extract the endpoint number from the host-supplied wIndex without any sort of validation. Fix this up by validating the number of endpoints actually match up with the number the device has before attempting to dereference a pointer based on this math.

This is just like what was done in commit ee0d382feb44 ("usb: gadget: aspeedudc: validate endpoint index for ast udc") for the aspeed driver.

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

media: mediatek: vcodec: fix use-after-free in encoder release path

The fopsvcodecrelease() function frees the context structure (ctx) without first cancelling any pending or running work in ctx->encodework. This creates a race window where the workqueue handler (mtkvencworker) may still be accessing the context memory after it has been freed.

Race condition:

CPU 0 (release path) CPU 1 (workqueue) --------------------- ------------------ fopsvcodecrelease() v4l2m2mctxrelease() v4l2m2mcanceljob() // waits for m2m job "done" mtkvencworker() v4l2m2mjobfinish() // m2m job "done" // BUT worker still running! // post-jobfinish access: other ctx dereferences // UAF if ctx already freed // returns (job "done") kfree(ctx) // ctx freed

Root cause: The v4l2m2mctxrelease() only waits for the m2m job lifecycle (via TRANSRUNNING flag), not the workqueue lifecycle. After v4l2m2mjobfinish() is called, the m2m framework considers the job complete and v4l2m2mctxrelease() returns, but the worker function continues executing and may still access ctx.

The work is queued during encode operations via: queuework(ctx->dev->encodeworkqueue, &ctx->encodework) The worker function accesses ctx->m2mctx, ctx->dev, and other ctx fields even after calling v4l2m2mjobfinish().

This vulnerability was confirmed with KASAN by running an instrumented test module that widens the post-jobfinish race window. KASAN detected:

BUG: KASAN: slab-use-after-free in mtkvencworker+0x159/0x180 Read of size 4 at addr ffff88800326e000 by task kworker/u8:0/12

Workqueue: mtkvcodecencwq mtkvencworker

Allocated by task 47: kasankmalloc+0x7f/0x90 fopsvcodecopen+0x85/0x1a0

Freed by task 47: kasanslabfree+0x43/0x70 kfree+0xee/0x3a0 fopsvcodecrelease+0xb7/0x190

Fix this by calling cancelworksync(&ctx->encodework) before kfree(ctx). This ensures the workqueue handler is both cancelled (if pending) and synchronized (waits for any running handler to complete) before the context is freed.

Placement rationale: The fix is placed after v4l2ctrlhandlerfree() and before listdelinit(&ctx->list). At this point, all m2m operations are done (v4l2m2mctxrelease() has returned), and we need to ensure the workqueue is synchronized before removing ctx from the list and freeing it.

Note: The open error path does NOT need cancelworksync() because INITWORK() only initializes the work structure - it does not schedule it. Work is only scheduled later during devicerun() operations.

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

net: lan966x: fix use-after-free and leak in lan966xfdmareload()

When lan966xfdmareload() fails to allocate new RX buffers, the restore path restarts DMA using old descriptors whose pages were already freed via lan966xfdmarxfreepages(). Since pagepoolputfullpage() can release pages back to the buddy allocator, the hardware may DMA into memory now owned by other kernel subsystems.

Additionally, on the restore path, the newly created page pool (if allocation partially succeeded) is overwritten without being destroyed, leaking it.

Fix both issues by deferring the release of old pages until after the new allocation succeeds. Save the old page array before the allocation so old pages can be freed on the success path. On the failure path, the old descriptors, pages and page pool are all still valid, making the restore safe. Also ensure the restore path re-enables NAPI and wakes the netdev, matching the success path.

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

ring-buffer: Fix possible dereference of uninitialized pointer

There is a pointer headpage in rbmetavalidateevents() which is not initialized at the beginning of a function. This pointer can be dereferenced if there is a failure during reader page validation. In this case the control is passed to "invalid" label where the pointer is dereferenced in a loop.

To fix the issue initialize orighead and headpage before calling rbvalidatebuffer.

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

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

xfrm: fix refcount leak in xfrmmigratepolicyfind

syzkaller reported a memory leak in xfrmpolicyalloc:

BUG: memory leak unreferenced object 0xffff888114d79000 (size 1024): comm "syz.1.17", pid 931 ... xfrmpolicyalloc+0xb3/0x4b0 net/xfrm/xfrmpolicy.c:432

The root cause is a double call to xfrmpolholdrcu() in xfrmmigratepolicyfind(). The lookup function already returns a policy with held reference, making the second call redundant.

Remove the redundant xfrmpolholdrcu() call to fix the refcount imbalance and prevent the memory leak.

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

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

tracing: ring-buffer: Fix to check event length before using

Check the event length before adding it for accessing next index in rbreaddatabuffer(). Since this function is used for validating possibly broken ring buffers, the length of the event could be broken. In that case, the new event (e + len) can point a wrong address. To avoid invalid memory access at boot, check whether the length of each event is in the possible range before using it.

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

iio: accel: adxl380: Avoid reading more entries than present in FIFO

The interrupt handler reads FIFO entries in batches of N samples, where N is the number of scan elements that have been enabled. However, the sensor fills the FIFO one sample at a time, even when more than one channel is enabled. Therefore,the number of entries reported by the FIFO status registers may not be a multiple of N; if this number is not a multiple, the number of entries read from the FIFO may exceed the number of entries actually present.

To fix the above issue, round down the number of FIFO entries read from the status registers so that it is always a multiple of N.

drm/amd/display: Fix dsc eDP issue

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

schedext: Fix SCXKICKWAIT deadlock by deferring wait to balance callback

SCXKICKWAIT busy-waits in kickcpusirqworkfn() using smpcondloadacquire() until the target CPU's kicksync advances. Because the irqwork runs in hardirq context, the waiting CPU cannot reschedule and its own kicksync never advances. If multiple CPUs form a wait cycle, all CPUs deadlock.

Replace the busy-wait in kickcpusirqworkfn() with reschedcurr() to force the CPU through dopicktaskscx(), which queues a balance callback to perform the wait. The balance callback drops the rq lock and enables IRQs following the schedcorebalance() pattern, so the CPU can process IPIs while waiting. The local CPU's kicksync is advanced on entry to dopicktaskscx() and continuously during the wait, ensuring any CPU that starts waiting for us sees the advancement and cannot form cyclic dependencies.

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

drm/amd/display: Fix NULL pointer dereference in dcn401inithw()

dcn401inithw() assumes that updatebwboundingbox() is valid when entering the update path. However, the existing condition:

((!fams2enable && updatebwboundingbox) || freqchanged)

does not guarantee this, as the freqchanged branch can evaluate to true independently of the callback pointer.

This can result in calling updatebwboundingbox() when it is NULL.

Fix this by separating the update condition from the pointer checks and ensuring the callback, dc->clkmgr, and bwparams are validated before use.

Fixes the below: ../dc/hwss/dcn401/dcn401hwseq.c:367 dcn401inithw() error: we previously assumed 'dc->respool->funcs->updatebwboundingbox' could be null (see line 362)

(cherry picked from commit 86117c5ab42f21562fedb0a64bffea3ee5fcd477)

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

iio: proximity: hx9023s: Protect against division by zero in setsampfreq

Avoid division by zero when sampling frequency is unspecified.

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

schedext: Fix starvation of scxenable() under fair-class saturation

During scxenable(), the READY -> ENABLED task switching loop changes the calling thread's schedclass from fair to ext. Since fair has higher priority than ext, saturating fair-class workloads can indefinitely starve the enable thread, hanging the system. This was introduced when the enable path switched from preemptdisable() to scxbypass() which doesn't protect against fair-class starvation. Note that the original preemptdisable() protection wasn't complete either - in partial switch modes, the calling thread could still be starved after preemptenable() as it may have been switched to ext class.

Fix it by offloading the enable body to a dedicated system-wide RT (SCHEDFIFO) kthread which cannot be starved by either fair or ext class tasks. scxenable() lazily creates the kthread on first use and passes the ops pointer through a struct scxenablecmd containing the kthreadwork, then synchronously waits for completion.

The workfn runs on a different kthread from sch->helper (which runs disablework), so it can safely flush disablework on the error path without deadlock.

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

drm/amdkfd: Unreserve bo if queue update failed

Error handling path should unreserve bo then return failed.

(cherry picked from commit c24afed7de9ecce341825d8ab55a43a254348b33)

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

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

pppasync: drop the errored frame instead of resetting its headroom

pppreceivenonmpframe() prepends a two-byte direction tag before running the pass/active BPF filters:

(be16 )skbpush(skb, 2) = htons(PPPFILTERINBOUNDTAG);

Nothing on the receive path guarantees those two bytes of headroom. The frame-error path in pppasync's processinputpacket() resets a reused skb's headroom to zero while claiming to restore it to a freshly allocated state - but a fresh skb from devallocskb() carries NETSKBPAD:

err: if (skb) { / make skb appear as freshly allocated / skbtrim(skb, 0); skbreserve(skb, - skbheadroom(skb)); }

ap->rpkt still points at that skb, so the next frame is reassembled into it with no headroom at all. A peer that sends a bad-FCS frame followed by one beginning ff 03 then leaves a single byte of headroom by the time the filter tag is pushed, which lands one byte below skb->head:

skbuff: skbunderpanic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev:<NULL> kernel BUG at net/core/skbuff.c:214! RIP: 0010:skbpanic+0x13e/0x230 Call Trace: skbpush+0xbd/0x100 pppreceivenonmpframe+0x48a/0x1d10 pppinput+0x4e9/0x2f80 pppasyncprocess+0x2a/0xe0 taskletactioncommon+0x20f/0x8a0 handlesoftirqs+0x18e/0x590 Kernel panic - not syncing: Fatal exception in interrupt

Zeroing the headroom violates the NETSKBPAD guarantee that devallocskb() gives the rest of the receive path. Besides the filter panic above, when CCP compression is enabled pppdecompressframe() hands skb->data - 2 to ->decompress()/->incomp(), which then reads out of bounds before skb->head for the same reason.

Rather than restore the headroom, drop the errored frame - as pppsynctty already does on its error path - and clear ap->rpkt so the next frame is reassembled into a fresh skb with proper headroom. This is simpler and fixes both the filter under-panic and the CCP out-of-bounds read.

The original V1 of this patch made room in pppreceivenonmpframe() with skbcowhead(); Eric pointed out that fixing the root cause in the transport is the right approach.

Found by fuzzing the PPP receive path with a mutating peer on a pty; it is an interesting (remote) DoS: root configures PPP, the peer supplies two crashing frames. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a second, and returns cleanly with this applied.