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:

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:

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 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 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:

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:

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:

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:

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.

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

iouring/net: inherit IORINGCQEFBUFMORE across bundle recv retries

When a bundle recv retries inside iorecvfinish(), the merge logic OR the saved cflags from the previous iteration with the cflags returned by the new iteration: cflags = req->cqe.flags | (cflags & CQEFMASK);

Bits listed in CQEFMASK are inherited from the new iteration, and all other bits (notably IORINGCQEFBUFFER and the buffer ID) come from the saved cflags. Before this change CQEFMASK covered only IORINGCQEFSOCKNONEMPTY and IORINGCQEFMORE.

When using provided buffer rings (IOUPBUFRINGINC) with incremental mode, and bundle recv, iokbufinccommit() can leave the head ring entry partially consumed, ioputkbufs() then sets IORINGCQEFBUFMORE on the returned cflags so userspace knows the buffer ID will be reused for subsequent completions.

Because IORINGCQEFBUFMORE was not in CQEFMASK, the merge above silently dropped it whenever the final retry iteration partially consumed the buffer, and the subsequent req->cqe.flags = cflags & ~CQEFMASK save would have left a stale IORINGCQEFBUFMORE in the carried-over cflags had one been present. Userspace would then wrongfully advance it ring head past an entry the kernel still uses.

Add IORINGCQEFBUFMORE to CQEFMASK so it is both inherited from the new iteration into the user-visible CQE and stripped from the saved cflags between iterations.

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

greybus: gb-beagleplay: bound bootloader receive buffering

cc1352bootloaderrx() appends each serdev chunk into the fixed rxbuffer before parsing bootloader packets. The helper can keep leftover bytes between callbacks and may receive multiple packets in one callback, so a single count value is not constrained by one packet length.

Check that the incoming chunk fits in the remaining receive buffer space before memcpy(). If it does not, drop the staged data and consume the bytes instead of overflowing rxbuffer.

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

of: unittest: fix use-after-free in ofunittestchangeset()

The variable 'parent' is assigned the value of 'nchangeset' earlier in the function, meaning both point to the same struct devicenode. The call to ofnodeput(nchangeset) can decrement the reference count to zero and free the node if there are no other holders. After that, the code still uses 'parent' to check for the presence of a property and to read a string property, leading to a use-after-free.

Fix this by moving the ofnodeput() call after the last access to 'parent', avoiding the UAF.

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

wifi: mac80211: use safe list iteration in radar detect work

The call to ieee80211dfscaccancel can cause the iterated chanctx to be freed and removed from the list. Guard against this to avoid a slab-use-after-free error.

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:

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:

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.

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:

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:

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:

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.