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

ksmbd: fix null pointer dereference in allocpreauthhash()

The Client send malformed smb2 negotiate request. ksmbd return error response. Subsequently, the client can send smb2 session setup even thought conn->preauthinfo is not allocated. This patch add KSMBDSESSNEEDSETUP status of connection to ignore session setup request if smb2 negotiate phase is not complete.

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

sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket

BUG: KASAN: slab-use-after-free in tcpwritetimerhandler+0x156/0x3e0 Read of size 1 at addr ffff888111f322cd by task swapper/0/0

CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 Call Trace: <IRQ> dumpstacklvl+0x68/0xa0 printaddressdescription.constprop.0+0x2c/0x3d0 printreport+0xb4/0x270 kasanreport+0xbd/0xf0 tcpwritetimerhandler+0x156/0x3e0 tcpwritetimer+0x66/0x170 calltimerfn+0xfb/0x1d0 runtimers+0x3f8/0x480 runtimersoftirq+0x9b/0x100 handlesoftirqs+0x153/0x390 irqexitrcu+0x103/0x120 irqexitrcu+0xe/0x20 sysvecapictimerinterrupt+0x76/0x90 </IRQ> <TASK> asmsysvecapictimerinterrupt+0x1a/0x20 RIP: 0010:defaultidle+0xf/0x20 Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242 RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590f RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835d R10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000 R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 defaultidlecall+0x6b/0xa0 cpuidleidlecall+0x1af/0x1f0 doidle+0xbc/0x130 cpustartupentry+0x33/0x40 restinit+0x11f/0x210 startkernel+0x39a/0x420 x8664startreservations+0x18/0x30 x8664startkernel+0x97/0xa0 commonstartup64+0x13e/0x141 </TASK>

Allocated by task 595: kasansavestack+0x24/0x50 kasansavetrack+0x14/0x30 kasanslaballoc+0x87/0x90 kmemcacheallocnoprof+0x12b/0x3f0 copynetns+0x94/0x380 createnewnamespaces+0x24c/0x500 unsharensproxynamespaces+0x75/0xf0 ksysunshare+0x24e/0x4f0 x64sysunshare+0x1f/0x30 dosyscall64+0x70/0x180 entrySYSCALL64afterhwframe+0x76/0x7e

Freed by task 100: kasansavestack+0x24/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 kasanslabfree+0x54/0x70 kmemcachefree+0x156/0x5d0 cleanupnet+0x5d3/0x670 processonework+0x776/0xa90 workerthread+0x2e2/0x560 kthread+0x1a8/0x1f0 retfromfork+0x34/0x60 retfromforkasm+0x1a/0x30

Reproduction script:

mkdir -p /mnt/nfsshare mkdir -p /mnt/nfs/netns1 mkfs.ext4 /dev/sdb mount /dev/sdb /mnt/nfsshare systemctl restart nfs-server chmod 777 /mnt/nfsshare exportfs -i -o rw,norootsquash :/mnt/nfsshare

ip netns add netns1 ip link add name veth1peer type veth peer veth1 ifconfig veth1peer 11.11.0.254 up ip link set veth1 netns netns1 ip netns exec netns1 ifconfig veth1 11.11.0.1

ip netns exec netns1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \ --tcp-flags FIN FIN -j DROP

(note: In my environment, a DESTROYCLIENTID operation is always sent immediately, breaking the nfs tcp connection.) ip netns exec netns1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \ 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns1

ip netns del netns1

The reason here is that the tcp socket in netns1 (nfs side) has been shutdown and closed (done in xsdestroy), but the FIN message (with ack) is discarded, and the nfsd side keeps sending retransmission messages. As a result, when the tcp sock in netns1 processes the received message, it sends the message (FIN message) in the sending queue, and the tcp timer is re-established. When the network namespace is deleted, the net structure accessed by tcp's timer handler function causes problems.

To fix this problem, let's hold netns refcnt for the tcp kernel socket as done in other modules. This is an ugly hack which can easily be backported to earlier kernels. A proper fix which cleans up the interfaces will follow, but may not be so easy to backport.

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:

binder: fix node UAF in binderaddfreezework()

In binderaddfreezework() we iterate over the proc->nodes with the proc->innerlock held. However, this lock is temporarily dropped in order to acquire the node->lock first (lock nesting order). This can race with bindernoderelease() and trigger a use-after-free:

================================================================== BUG: KASAN: slab-use-after-free in rawspinlock+0xe4/0x19c Write of size 4 at addr ffff53c04c29dd04 by task freeze/640

CPU: 5 UID: 0 PID: 640 Comm: freeze Not tainted 6.11.0-07343-ga727812a8d45 #17 Hardware name: linux,dummy-virt (DT) Call trace: rawspinlock+0xe4/0x19c binderaddfreezework+0x148/0x478 binderioctl+0x1e70/0x25ac arm64sysioctl+0x124/0x190

Allocated by task 637: kmalloccachenoprof+0x12c/0x27c bindernewnode+0x50/0x700 bindertransaction+0x35ac/0x6f74 binderthreadwrite+0xfb8/0x42a0 binderioctl+0x18f0/0x25ac arm64sysioctl+0x124/0x190

Freed by task 637: kfree+0xf0/0x330 binderthreadread+0x1e88/0x3a68 binderioctl+0x16d8/0x25ac arm64sysioctl+0x124/0x190 ==================================================================

Fix the race by taking a temporary reference on the node before releasing the proc->inner lock. This ensures the node remains alive while in use.

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

net: reenable NETIFFIPV6CSUM offload for BIG TCP packets

The blamed commit disabled hardware offoad of IPv6 packets with extension headers on devices that advertise NETIFFIPV6CSUM, based on the definition of that feature in skbuff.h:

- %NETIFFIPV6CSUM - Driver (device) is only able to checksum plain TCP or UDP packets over IPv6. These are specifically unencapsulated packets of the form IPv6|TCP or IPv6|UDP where the Next Header field in the IPv6 header is either TCP or UDP. IPv6 extension headers are not supported with this feature. This feature cannot be set in features for a device with NETIFFHWCSUM also set. This feature is being DEPRECATED (see below).

The change causes skbwarnbadoffload to fire for BIG TCP packets.

[ 496.310233] WARNING: CPU: 13 PID: 23472 at net/core/dev.c:3129 skbwarnbadoffload+0xc4/0xe0

[ 496.310297] ? skbwarnbadoffload+0xc4/0xe0 [ 496.310300] skbchecksumhelp+0x129/0x1f0 [ 496.310303] skbcsumhwoffloadhelp+0x150/0x1b0 [ 496.310306] validatexmitskb+0x159/0x270 [ 496.310309] validatexmitskblist+0x41/0x70 [ 496.310312] schdirectxmit+0x5c/0x250 [ 496.310317] qdiscrun+0x388/0x620

BIG TCP introduced an IPV6TLVJUMBO IPv6 extension header to communicate packet length, as this is an IPv6 jumbogram. But, 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.

For this specific case of extension headers that are not transmitted, return to the situation before the blamed commit and support hardware offload.

ipv6hashopoptjumbo() tests not only whether this header is present, but also that it is the only extension header before a terminal (L4) header.

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:

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).

dst: fix races in rt6uncachedlistdel() and rtdeluncachedlist()

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

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.