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

bnxten: Fix receive ring space parameters when XDP is active

The MTU setting at the time an XDP multi-buffer is attached determines whether the aggregation ring will be used and the rxskbfunc handler. This is done in bnxtsetrxskbmode().

If the MTU is later changed, the aggregation ring setting may need to be changed and it may become out-of-sync with the settings initially done in bnxtsetrxskbmode(). This may result in random memory corruption and crashes as the HW may DMA data larger than the allocated buffer size, such as:

BUG: kernel NULL pointer dereference, address: 00000000000003c0 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 17 PID: 0 Comm: swapper/17 Kdump: loaded Tainted: G S OE 6.1.0-226bf9805506 #1 Hardware name: Wiwynn Delta Lake PVT BZA.02601.0150/Delta Lake-Class1, BIOS F0E3A12 08/26/2021 RIP: 0010:bnxtrxpkt+0xe97/0x1ae0 [bnxten] Code: 8b 95 70 ff ff ff 4c 8b 9d 48 ff ff ff 66 41 89 87 b4 00 00 00 e9 0b f7 ff ff 0f b7 43 0a 49 8b 95 a8 04 00 00 25 ff 0f 00 00 <0f> b7 14 42 48 c1 e2 06 49 03 95 a0 04 00 00 0f b6 42 33f RSP: 0018:ffffa19f40cc0d18 EFLAGS: 00010202 RAX: 00000000000001e0 RBX: ffff8e2c805c6100 RCX: 00000000000007ff RDX: 0000000000000000 RSI: ffff8e2c271ab990 RDI: ffff8e2c84f12380 RBP: ffffa19f40cc0e48 R08: 000000000001000d R09: 974ea2fcddfa4cbf R10: 0000000000000000 R11: ffffa19f40cc0ff8 R12: ffff8e2c94b58980 R13: ffff8e2c952d6600 R14: 0000000000000016 R15: ffff8e2c271ab990 FS: 0000000000000000(0000) GS:ffff8e3b3f840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000003c0 CR3: 0000000e8580a004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> bnxtpollwork+0x1c2/0x3e0 [bnxten]

To address the issue, we now call bnxtsetrxskbmode() within bnxtchangemtu() to properly set the AGG rings configuration and update rxskbfunc based on the new MTU value. Additionally, BNXTFLAGNOAGGRINGS is cleared at the beginning of bnxtsetrxskbmode() to make sure it gets set or cleared based on the current MTU.

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

ksmbd: fix use-after-free and NULL deref in smbgrantoplock()

smbgrantoplock() has two issues in the oplock publication sequence:

1) opinfo is linked into ci->moplist (via opinfoadd) before addleasegloballist() is called. If addleasegloballist() fails (kmalloc returns NULL), the error path frees the opinfo via freeopinfo() while it is still linked in ci->moplist. Concurrent moplist readers (opinfogetlist, or direct iteration in smbbreakalllevIIoplock) dereference the freed node.

2) opinfo->ofp is assigned after addleasegloballist() publishes the opinfo on the global lease list. A concurrent findsameleasekey() can walk the lease list and dereference opinfo->ofp->fci while ofp is still NULL.

Fix by restructuring the publication sequence to eliminate post-publish failure:

- Set opinfo->ofp before any list publication (fixes NULL deref). - Preallocate leasetable via allocleasetable() before opinfoadd() so addleasegloballist() becomes infallible after publication. - Keep the original moplist publication order (opinfoadd before lease list) so concurrent opens via sameclienthaslease() and opinfogetlist() still see the in-flight grant. - Use opinfoput() instead of freeopinfo() on errout so that the RCU-deferred free path is used.

This also requires splitting addleasegloballist() to take a preallocated leasetable and changing its return type from int to void, since it can no longer fail.

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

dlm: validate length in dlmsearchrsbtree

The len parameter in dlmdumprsbname() is not validated and comes from network messages. When it exceeds DLMRESNAMEMAXLEN, it can cause out-of-bounds write in dlmsearchrsbtree().

Add length validation to prevent potential buffer overflow.

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

net/mlx5e: RX, Fix XDP multi-buf frag counting for striding RQ

XDP multi-buf programs can modify the layout of the XDP buffer when the program calls bpfxdppulldata() or bpfxdpadjusttail(). The referenced commit in the fixes tag corrected the assumption in the mlx5 driver that the XDP buffer layout doesn't change during a program execution. However, this fix introduced another issue: the dropped fragments still need to be counted on the driver side to avoid page fragment reference counting issues.

The issue was discovered by the drivers/net/xdp.py selftest, more specifically the testxdpnativetxmb: - The mlx5 driver allocates a pagepool page and initializes it with a frag counter of 64 (pprefcount=64) and the internal frag counter to 0. - The test sends one packet with no payload. - On RX (mlx5eskbfromcqempwrqnonlinear()), mlx5 configures the XDP buffer with the packet data starting in the first fragment which is the page mentioned above. - The XDP program runs and calls bpfxdppulldata() which moves the header into the linear part of the XDP buffer. As the packet doesn't contain more data, the program drops the tail fragment since it no longer contains any payload (pprefcount=63). - mlx5 device skips counting this fragment. Internal frag counter remains 0. - mlx5 releases all 64 fragments of the page but page pprefcount is 63 => negative reference counting error.

Resulting splat during the test:

WARNING: CPU: 0 PID: 188225 at ./include/net/pagepool/helpers.h:297 mlx5epagereleasefragmented.isra.0+0xbd/0xe0 [mlx5core] Modules linked in: [...] CPU: 0 UID: 0 PID: 188225 Comm: ip Not tainted 6.18.0-rc7forupstreammindebug202512081144 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5epagereleasefragmented.isra.0+0xbd/0xe0 [mlx5core] [...] Call Trace: <TASK> mlx5efreerxmpwqe+0x20a/0x250 [mlx5core] mlx5edeallocrxmpwqe+0x37/0xb0 [mlx5core] mlx5efreerxdescs+0x11a/0x170 [mlx5core] mlx5ecloserq+0x78/0xa0 [mlx5core] mlx5eclosequeues+0x46/0x2a0 [mlx5core] mlx5eclosechannel+0x24/0x90 [mlx5core] mlx5eclosechannels+0x5d/0xf0 [mlx5core] mlx5esafeswitchparams+0x2ec/0x380 [mlx5core] mlx5echangemtu+0x11d/0x490 [mlx5core] mlx5echangenicmtu+0x19/0x30 [mlx5core] netifsetmtuext+0xfc/0x240 dosetlink.isra.0+0x226/0x1100 rtnlnewlink+0x7a9/0xba0 rtnetlinkrcvmsg+0x220/0x3c0 netlinkrcvskb+0x4b/0xf0 netlinkunicast+0x255/0x380 netlinksendmsg+0x1f3/0x420 socksendmsg+0x38/0x60 syssendmsg+0x1e8/0x240 syssendmsg+0x7c/0xb0 [...] syssendmsg+0x5f/0xb0 dosyscall64+0x55/0xc70

The problem applies for XDPPASS as well which is handled in a different code path in the driver.

This patch fixes the issue by doing page frag counting on all the original XDP buffer fragments for all relevant XDP actions (XDPTX , XDPREDIRECT and XDPPASS). This is basically reverting to the original counting before the commit in the fixes tag.

As fragpage is still pointing to the original tail, the nrfrags parameter to xdpupdateskbfragsinfo() needs to be calculated in a different way to reflect the new nrfrags.

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

smb: client: validate dacloffset before building DACL pointers

parsesecdesc(), buildsecdesc(), and the chown path in idmodetocifsacl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor.

On 32-bit builds a malicious server can return dacloffset near U32MAX, wrap the derived DACL pointer below endofacl, and then slip past the later pointer-based bounds checks. buildsecdesc() and idmodetocifsacl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths.

Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.

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

virt/coco/sev-guest: Double-buffer messages

The encryption algorithms read and write directly to shared unencrypted memory, which may leak information as well as permit the host to tamper with the message integrity. Instead, copy whole messages in or out as needed before doing any computation on them.

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

RDMA/rxe: Validate pad and ICRC before payloadsize() in rxercv

rxercv() currently checks only that the incoming packet is at least headersize(pkt) bytes long before payloadsize() is used.

However, payloadsize() subtracts both the attacker-controlled BTH pad field and RXEICRCSIZE from pkt->paylen:

payloadsize = pkt->paylen - offset[RXEPAYLOAD] - bthpad(pkt) - RXEICRCSIZE

This means a short packet can still make payloadsize() underflow even if it includes enough bytes for the fixed headers. Simply requiring headersize(pkt) + RXEICRCSIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payloadsize() negative and pass an underflowed value to later receive-path users.

Fix this by validating pkt->paylen against the full minimum length required by payloadsize(): headersize(pkt) + bthpad(pkt) + RXEICRCSIZE.

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

wifi: ath11k: update channel list in reg notifier instead reg worker

Currently when ath11k gets a new channel list, it will be processed according to the following steps: 1. update new channel list to cfg80211 and queue regwork. 2. cfg80211 handles new channel list during regwork. 3. update cfg80211's handled channel list to firmware by ath11kregupdatechanlist().

But ath11k will immediately execute step 3 after regwork is just queued. Since step 2 is asynchronous, cfg80211 may not have completed handling the new channel list, which may leading to an out-of-bounds write error: BUG: KASAN: slab-out-of-bounds in ath11kregupdatechanlist Call Trace: ath11kregupdatechanlist+0xbfe/0xfe0 [ath11k] kfree+0x109/0x3a0 ath11kregdupdate+0x1cf/0x350 [ath11k] ath11kregdupdatework+0x14/0x20 [ath11k] processonework+0xe35/0x14c0

Should ensure step 2 is completely done before executing step 3. Thus Wen raised patch[1]. When flag NL80211REGDOMSETBYDRIVER is set, cfg80211 will notify ath11k after step 2 is done.

So enable the flag NL80211REGDOMSETBYDRIVER then cfg80211 will notify ath11k after step 2 is done. At this time, there will be no KASAN bug during the execution of the step 3.

[1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quicwgong@quicinc.com/

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPLV1V2SILICONZLITE-3

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

Bluetooth: L2CAP: Fix use-after-free in l2capunregisteruser

After commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hcichandel"), l2capconndel() uses conn->lock to protect access to conn->users. However, l2capregisteruser() and l2capunregisteruser() don't use conn->lock, creating a race condition where these functions can access conn->users and conn->hchan concurrently with l2capconndel().

This can lead to use-after-free and list corruption bugs, as reported by syzbot.

Fix this by changing l2capregisteruser() and l2capunregisteruser() to use conn->lock instead of hcidevlock(), ensuring consistent locking for the l2capconn structure.

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

KVM: arm64: Fix the descriptor address in kvmatswapdesc()

Using "(u64 user )hva + offset" to get the virtual addresses of S1/S2 descriptors looks really wrong, if offset is not zero. What we want to get for swapping is hva + offset, not hva + offset8. ;-)

Fix it.

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

smb: client: validate the whole DACL before rewriting it in cifsacl

buildsecdesc() and idmodetocifsacl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor.

The original fix only checked that the struct smbacl header fits before reading daclptr->size or daclptr->numaces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->numaces with no structural validation of the incoming DACL body.

A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replacesidsandcopyaces() or setchmoddacl() past the validated extent while they compare or copy attacker-controlled ACEs.

Factor the DACL structural checks into validatedacl(), extend them to validate each ACE against the DACL bounds, and use the shared validator before the chmod/chown rebuild paths. parsedacl() reuses the same validator so the read-side parser and write-side rewrite paths agree on what constitutes a well-formed incoming DACL.

batman-adv: stop caching unowned originator pointers in BAT IV

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

iommu/riscv: Add IOTINVAL after updating DDT/PDT entries

Add riscviommuiodiriotinval() to perform required TLB and context cache invalidations after updating DDT or PDT entries, as mandated by the RISC-V IOMMU specification (Section 6.3.1 and 6.3.2).

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

net: airoha: Fix use-after-free in metadata dst teardown

airohametadatadstfree() runs metadatadstfree() which frees the metadatadst with kfree() immediately, bypassing the RCU grace period. In the RX path, skbdstsetnoref() sets a non-refcounted pointer from the skb to the metadatadst. This function requires RCU read-side protection and the dst must remain valid until all RCU readers complete. Since metadatadstfree() calls kfree() directly, an use-after-free can occur if any skb still holds a noref pointer to the dst when the driver tears it down. Replace metadatadstfree() with dstrelease() which properly goes through the refcount path: when the refcount drops to zero, it schedules the actual free via callrcuhurry(), ensuring all RCU readers have completed before the memory is freed.

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

net/mlx5: Fix slab-out-of-bounds in mlx5querynicvportmaclist

mlx5querynicvportmaclist() sizes its firmware command buffer using the PF's logmaxcurrentuc/mclist capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer:

BUG: KASAN: slab-out-of-bounds in mlx5querynicvportmaclist+0x453/0x4c0 [mlx5core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385

CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5eswwq eswvportchangehandler [mlx5core] Call Trace: <TASK> dumpstacklvl+0x69/0xa0 printreport+0x176/0x4e4 kasanreport+0xc8/0x100 mlx5querynicvportmaclist+0x453/0x4c0 [mlx5core] eswupdatevportaddrlist+0x2e3/0xda0 [mlx5core] eswvportchangehandlelocked+0xa1f/0x1060 [mlx5core] eswvportchangehandler+0x6a/0x90 [mlx5core] processonework+0x87f/0x15e0 workerthread+0x62b/0x1020 kthread+0x375/0x490 retfromfork+0x4dc/0x810 retfromforkasm+0x11/0x20 </TASK>

Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.

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

ksmbd: Don't log keys in SMB3 signing and encryption key generation

When KSMBDDEBUGAUTH logging is enabled, generatesmb3signingkey() and generatesmb3encryptionkey() log the session, signing, encryption, and decryption key bytes. Remove the logs to avoid exposing credentials.

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

NFSD: NFSv4 file creation neglects setting ACL

An NFSv4 client that sets an ACL with a named principal during file creation retrieves the ACL afterwards, and finds that it is only a default ACL (based on the mode bits) and not the ACL that was requested during file creation. This violates RFC 8881 section 6.4.1.3: "the ACL attribute is set as given".

The issue occurs in nfsdcreatesetattr(), which calls nfsdattrsvalid() to determine whether to call nfsdsetattr(). However, nfsdattrsvalid() checks only for iattr changes and security labels, but not POSIX ACLs. When only an ACL is present, the function returns false, nfsdsetattr() is skipped, and the POSIX ACL is never applied to the inode.

Subsequently, when the client retrieves the ACL, the server finds no POSIX ACL on the inode and returns one generated from the file's mode bits rather than returning the originally-specified ACL.

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

LoongArch: Set hugetlb mmap base address aligned with pmd size

With ltp test case "testcases/bin/hugefork02", there is a dmesg error report message such as:

kernel BUG at mm/hugetlb.c:5550! Oops - BUG[#1]: CPU: 0 UID: 0 PID: 1517 Comm: hugefork02 Not tainted 6.14.0-rc2+ #241 Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 pc 90000000004eaf1c ra 9000000000485538 tp 900000010edbc000 sp 900000010edbf940 a0 900000010edbfb00 a1 9000000108d20280 a2 00007fffe9474000 a3 00007ffff3474000 a4 0000000000000000 a5 0000000000000003 a6 00000000003cadd3 a7 0000000000000000 t0 0000000001ffffff t1 0000000001474000 t2 900000010ecd7900 t3 00007fffe9474000 t4 00007fffe9474000 t5 0000000000000040 t6 900000010edbfb00 t7 0000000000000001 t8 0000000000000005 u0 90000000004849d0 s9 900000010edbfa00 s0 9000000108d20280 s1 00007fffe9474000 s2 0000000002000000 s3 9000000108d20280 s4 9000000002b38b10 s5 900000010edbfb00 s6 00007ffff3474000 s7 0000000000000406 s8 900000010edbfa08 ra: 9000000000485538 unmapvmas+0x130/0x218 ERA: 90000000004eaf1c unmaphugepagerange+0x6f4/0x7d0 PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) Process hugefork02 (pid: 1517, threadinfo=00000000a670eaf4, task=000000007a95fc64) Call Trace: [<90000000004eaf1c>] unmaphugepagerange+0x6f4/0x7d0 [<9000000000485534>] unmapvmas+0x12c/0x218 [<9000000000494068>] exitmmap+0xe0/0x308 [<900000000025fdc4>] mmput+0x74/0x180 [<900000000026a284>] doexit+0x294/0x898 [<900000000026aa30>] dogroupexit+0x30/0x98 [<900000000027bed4>] getsignal+0x83c/0x868 [<90000000002457b4>] archdosignalorrestart+0x54/0xfa0 [<90000000015795e8>] irqentryexittousermode+0xb8/0x138 [<90000000002572d0>] tlbdopagefault1+0x114/0x1b4

The problem is that base address allocated from hugetlbfs is not aligned with pmd size. Here add a checking for hugetlbfs and align base address with pmd size. After this patch the test case "testcases/bin/hugefork02" passes to run.

This is similar to the commit 7f24cbc9c4d42db8a3c8484d1 ("mm/mmap: teach genericgetunmappedarea{topdown} to handle hugetlb mappings").

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

spi: spi-qpic-snand: reallocate BAM transactions

Using the mtdnandbiterrs module for testing the driver occasionally results in weird things like below.

1. swiotlb mapping fails with the following message:

[ 85.926216] qcomsnand 79b0000.spi: swiotlb buffer is full (sz: 4294967294 bytes), total 512 (slots), used 0 (slots) [ 85.932937] qcomsnand 79b0000.spi: failure in mapping desc [ 87.999314] qcomsnand 79b0000.spi: failure to write raw page [ 87.999352] mtdnandbiterrs: error: writeoob failed (-110)

Rebooting the board after this causes a panic due to a NULL pointer dereference.

2. If the swiotlb mapping does not fail, rebooting the board may result in a different panic due to a bad spinlock magic:

[ 256.104459] BUG: spinlock bad magic on CPU#3, procd/2241 [ 256.104488] Unable to handle kernel paging request at virtual address ffffffff0000049b ...

Investigating the issue revealed that these symptoms are results of memory corruption which is caused by out of bounds access within the driver.

The driver uses a dynamically allocated structure for BAM transactions, which structure must have enough space for all possible variations of different flash operations initiated by the driver. The required space heavily depends on the actual number of 'codewords' which is calculated from the pagesize of the actual NAND chip.

Although the qcomnandcalloc() function allocates memory for the BAM transactions during probe, but since the actual number of 'codewords' is not yet know the allocation is done for one 'codeword' only.

Because of this, whenever the driver does a flash operation, and the number of the required transactions exceeds the size of the allocated arrays the driver accesses memory out of the allocated range.

To avoid this, change the code to free the initially allocated BAM transactions memory, and allocate a new one once the actual number of 'codewords' required for a given NAND chip is known.

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

opentreeattr: do not allow id-mapping changes without OPENTREECLONE

As described in commit 7a54947e727b ('Merge patch series "fs: allow changing idmappings"'), opentreeattr(2) was necessary in order to allow for a detached mount to be created and have its idmappings changed without the risk of any racing threads operating on it. For this reason, mountsetattr(2) still does not allow for id-mappings to be changed.

However, there was a bug in commit 2462651ffa76 ("fs: allow changing idmappings") which allowed users to bypass this restriction by calling opentreeattr(2) without OPENTREECLONE.

canidmapmount() prevented this bug from allowing an attached mountpoint's id-mapping from being modified (thanks to an isanonns() check), but this still allows for detached (but visible) mounts to have their be id-mapping changed. This risks the same UAF and locking issues as described in the merge commit, and was likely unintentional.

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

skbuff: skbsegment, Call zero copy functions before using skbuff frags

Commit bf5c25d60861 ("skbuff: in skbsegment, call zerocopy functions once per nskb") added the call to zero copy functions in skbsegment(). The change introduced a bug in skbsegment() because skborphanfrags() may possibly change the number of fragments or allocate new fragments altogether leaving nrfrags and frag to point to the old values. This can cause a panic with stacktrace like the one below.

[ 193.894380] BUG: kernel NULL pointer dereference, address: 00000000000000bc [ 193.895273] CPU: 13 PID: 18164 Comm: vh-net-17428 Kdump: loaded Tainted: G O 5.15.123+ #26 [ 193.903919] RIP: 0010:skbsegment+0xb0e/0x12f0 [ 194.021892] Call Trace: [ 194.027422] <TASK> [ 194.072861] tcpgsosegment+0x107/0x540 [ 194.082031] inetgsosegment+0x15c/0x3d0 [ 194.090783] skbmacgsosegment+0x9f/0x110 [ 194.095016] skbgsosegment+0xc1/0x190 [ 194.103131] netemenqueue+0x290/0xb10 [schnetem] [ 194.107071] devqdiscenqueue+0x16/0x70 [ 194.110884] devqueuexmit+0x63b/0xb30 [ 194.121670] bondstartxmit+0x159/0x380 [bonding] [ 194.128506] devhardstartxmit+0xc3/0x1e0 [ 194.131787] devqueuexmit+0x8a0/0xb30 [ 194.138225] macvlanstartxmit+0x4f/0x100 [macvlan] [ 194.141477] devhardstartxmit+0xc3/0x1e0 [ 194.144622] schdirectxmit+0xe3/0x280 [ 194.147748] devqueuexmit+0x54a/0xb30 [ 194.154131] tapgetuser+0x2a8/0x9c0 [tap] [ 194.157358] tapsendmsg+0x52/0x8e0 [tap] [ 194.167049] handletxzerocopy+0x14e/0x4c0 [vhostnet] [ 194.173631] handletx+0xcd/0xe0 [vhostnet] [ 194.176959] vhostworker+0x76/0xb0 [vhost] [ 194.183667] kthread+0x118/0x140 [ 194.190358] retfromfork+0x1f/0x30 [ 194.193670] </TASK>

In this case calling skborphanfrags() updated nrfrags leaving nrfrags local variable in skbsegment() stale. This resulted in the code hitting i >= nrfrags prematurely and trying to move to next fragskb using listskb pointer, which was NULL, and caused kernel panic. Move the call to zero copy functions before using frags and nrfrags.

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

netfilter: nftsetrbtree: fix null deref on element insertion

There is no guarantee that rbprev() will not return NULL in nftrbtreegcelem():

general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] nftaddsetelem+0x14b0/0x2990 nftablesnewsetelem+0x528/0xb30

Furthermore, there is a possible use-after-free while iterating, 'node' can be free'd so we need to cache the next value to use.

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

xfrm: Update ipcompscratches with NULL when freed

Currently if ipcompallocscratches() fails to allocate memory ipcompscratches holds obsolete address. So when we try to free the percpu scratches using ipcompfreescratches() it tries to vfree non existent vm area. Described below:

static void percpu ipcompallocscratches(void) { ... scratches = allocpercpu(void ); if (!scratches) return NULL; ipcompscratches does not know about this allocation failure. Therefore holding the old obsolete address. ... }

So when we free,

static void ipcompfreescratches(void) { ... scratches = ipcompscratches; Assigning obsolete address from ipcompscratches

if (!scratches) return;

foreachpossiblecpu(i) vfree(percpuptr(scratches, i)); Trying to free non existent page, causing warning: trying to vfree existent vm area. ... }

Fix this breakage by updating ipcompscrtches with NULL when scratches is freed

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

tipc: Fix use-after-free in tipcmonreinitself().

syzbot reported use-after-free of tipcnet(net)->monitors[] in tipcmonreinitself(). [0]

The array is protected by RTNL, but tipcmonreinitself() iterates over it without RTNL.

tipcmonreinitself() is called from tipcnetfinalize(), which is always under RTNL except for tipcnetfinalizework().

Let's hold RTNL in tipcnetfinalizework().

[0]: BUG: KASAN: slab-use-after-free in rawspinlockirqsave include/linux/spinlockapismp.h:110 [inline] BUG: KASAN: slab-use-after-free in rawspinlockirqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989

CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Workqueue: events tipcnetfinalizework Call Trace: <TASK> dumpstacklvl+0x189/0x250 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xca/0x240 mm/kasan/report.c:482 kasanreport+0x118/0x150 mm/kasan/report.c:595 kasancheckbyte+0x2a/0x40 mm/kasan/common.c:568 kasancheckbyte include/linux/kasan.h:399 [inline] lockacquire+0x8d/0x360 kernel/locking/lockdep.c:5842 rawspinlockirqsave include/linux/spinlockapismp.h:110 [inline] rawspinlockirqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 rtlockslowlock kernel/locking/rtmutex.c:1894 [inline] rwbasertmutexlockstate kernel/locking/spinlockrt.c:160 [inline] rwbasewritelock+0xd3/0x7e0 kernel/locking/rwbasert.c:244 rtwritelock+0x76/0x110 kernel/locking/spinlockrt.c:243 writelockbh include/linux/rwlockrt.h:99 [inline] tipcmonreinitself+0x79/0x430 net/tipc/monitor.c:718 tipcnetfinalize+0x115/0x190 net/tipc/net.c:140 processonework kernel/workqueue.c:3236 [inline] processscheduledworks+0xade/0x17b0 kernel/workqueue.c:3319 workerthread+0x8a0/0xda0 kernel/workqueue.c:3400 kthread+0x70e/0x8a0 kernel/kthread.c:463 retfromfork+0x439/0x7d0 arch/x86/kernel/process.c:148 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK>

Allocated by task 6089: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3e/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:388 [inline] kasankmalloc+0x93/0xb0 mm/kasan/common.c:405 kasankmalloc include/linux/kasan.h:260 [inline] kmalloccachenoprof+0x1a8/0x320 mm/slub.c:4407 kmallocnoprof include/linux/slab.h:905 [inline] kzallocnoprof include/linux/slab.h:1039 [inline] tipcmoncreate+0xc3/0x4d0 net/tipc/monitor.c:657 tipcenablebearer net/tipc/bearer.c:357 [inline] tipcnlbearerenable+0xe16/0x13f0 net/tipc/bearer.c:1047 tipcnlcompatdoit net/tipc/netlinkcompat.c:371 [inline] tipcnlcompatdoit+0x3bc/0x5f0 net/tipc/netlinkcompat.c:393 tipcnlcompathandle net/tipc/netlinkcompat.c:-1 [inline] tipcnlcompatrecv+0x83c/0xbe0 net/tipc/netlinkcompat.c:1321 genlfamilyrcvmsgdoit+0x215/0x300 net/netlink/genetlink.c:1115 genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0x60e/0x790 net/netlink/genetlink.c:1210 netlinkrcvskb+0x208/0x470 net/netlink/afnetlink.c:2552 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1320 [inline] netlinkunicast+0x846/0xa10 net/netlink/afnetlink.c:1346 netlinksendmsg+0x805/0xb30 net/netlink/afnetlink.c:1896 socksendmsgnosec net/socket.c:714 [inline] socksendmsg+0x21c/0x270 net/socket.c:729 syssendmsg+0x508/0x820 net/socket.c:2614 syssendmsg+0x21f/0x2a0 net/socket.c:2668 syssendmsg net/socket.c:2700 [inline] dosyssendmsg net/socket.c:2705 [inline] sesyssendmsg net/socket.c:2703 [inline] x64syssendmsg+0x1a1/0x260 net/socket.c:2703 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xfa/0x3b0 arch/ ---truncated---

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

rustbinder: fix race condition on deathlist

Rust Binder contains the following unsafe operation:

// SAFETY: A NodeDeath is never inserted into the death list // of any node other than its owner, so it is either in this // death list or in no death list. unsafe { nodeinner.deathlist.remove(self) };

This operation is unsafe because when touching the prev/next pointers of a list element, we have to ensure that no other thread is also touching them in parallel. If the node is present in the list that remove is called on, then that is fine because we have exclusive access to that list. If the node is not in any list, then it's also ok. But if it's present in a different list that may be accessed in parallel, then that may be a data race on the prev/next pointers.

And unfortunately that is exactly what is happening here. In Node::release, we:

1. Take the lock. 2. Move all items to a local list on the stack. 3. Drop the lock. 4. Iterate the local list on the stack.

Combined with threads using the unsafe remove method on the original list, this leads to memory corruption of the prev/next pointers. This leads to crashes like this one:

Unable to handle kernel paging request at virtual address 000bb9841bcac70e Mem abort info: ESR = 0x0000000096000044 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [000bb9841bcac70e] address between user and kernel address ranges Internal error: Oops: 0000000096000044 [#1] PREEMPT SMP google-cdd 538c004.gcdd: context saved(CPU:1) item - logkevents is disabled Modules linked in: ... rustbinder CPU: 1 UID: 0 PID: 2092 Comm: kworker/1:178 Tainted: G S W OE 6.12.52-android16-5-g98debd5df505-4k #1 f94a6367396c5488d635708e43ee0c888d230b0b Tainted: [S]=CPUOUTOFSPEC, [W]=WARN, [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: MUSTANG PVT 1.0 based on LGA (DT) Workqueue: events RNvXs6NtCsdfZWD8DztAw6kernel9workqueueINtNtNtB74sync3arc3ArcNtNtCs8QPsHWIn21X16rustbindermain7process7ProcessEINtB515WorkItemPointerKy0E3runB13 [rustbinder] pstate: 23400005 (nzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : RNvXs3NtCs8QPsHWIn21X16rustbindermain7processNtB57ProcessNtNtCsdfZWD8DztAw6kernel9workqueue8WorkItem3run+0x450/0x11f8 [rustbinder] lr : RNvXs3NtCs8QPsHWIn21X16rustbindermain7processNtB57ProcessNtNtCsdfZWD8DztAw6kernel9workqueue8WorkItem3run+0x464/0x11f8 [rustbinder] sp : ffffffc09b433ac0 x29: ffffffc09b433d30 x28: ffffff8821690000 x27: ffffffd40cbaa448 x26: ffffff8821690000 x25: 00000000ffffffff x24: ffffff88d0376578 x23: 0000000000000001 x22: ffffffc09b433c78 x21: ffffff88e8f9bf40 x20: ffffff88e8f9bf40 x19: ffffff882692b000 x18: ffffffd40f10bf00 x17: 00000000c006287d x16: 00000000c006287d x15: 00000000000003b0 x14: 0000000000000100 x13: 000000201cb79ae0 x12: fffffffffffffff0 x11: 0000000000000000 x10: 0000000000000001 x9 : 0000000000000000 x8 : b80bb9841bcac706 x7 : 0000000000000001 x6 : fffffffebee63f30 x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000004c31 x1 : ffffff88216900c0 x0 : ffffff88e8f9bf00 Call trace: RNvXs3NtCs8QPsHWIn21X16rustbindermain7processNtB57ProcessNtNtCsdfZWD8DztAw6kernel9workqueue8WorkItem3run+0x450/0x11f8 [rustbinder bbc172b53665bbc815363b22e97e3f7e3fe971fc] processscheduledworks+0x1c4/0x45c workerthread+0x32c/0x3e8 kthread+0x11c/0x1c8 retfromfork+0x10/0x20 Code: 94218d85 b4000155 a94026a8 d10102a0 (f9000509) ---[ end trace 0000000000000000 ]---

Thus, modify Node::release to pop items directly off the original list.

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

mm/pagealloc: prevent pcp corruption with SMP=n

The kernel test robot has reported:

BUG: spinlock trylock failure on UP on CPU#0, kcompactd0/28 lock: 0xffff888807e35ef0, .magic: dead4ead, .owner: kcompactd0/28, .ownercpu: 0 CPU: 0 UID: 0 PID: 28 Comm: kcompactd0 Not tainted 6.18.0-rc5-00127-ga06157804399 #1 PREEMPT 8cc09ef94dcec767faa911515ce9e609c45db470 Call Trace: <IRQ> dumpstack (lib/dumpstack.c:95) dumpstacklvl (lib/dumpstack.c:123) dumpstack (lib/dumpstack.c:130) spindump (kernel/locking/spinlockdebug.c:71) dorawspintrylock (kernel/locking/spinlockdebug.c:?) rawspintrylock (include/linux/spinlockapismp.h:89 kernel/locking/spinlock.c:138) freefrozenpages (mm/pagealloc.c:2973) freepages (mm/pagealloc.c:5295) freepages (mm/pagealloc.c:5334) tlbremovetablercu (include/linux/mm.h:? include/linux/mm.h:3122 include/asm-generic/tlb.h:220 mm/mmugather.c:227 mm/mmugather.c:290) ? cfitlbremovetablercu (mm/mmugather.c:289) ? rcucore (kernel/rcu/tree.c:?) rcucore (include/linux/rcupdate.h:341 kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861) rcucoresi (kernel/rcu/tree.c:2879) handlesoftirqs (arch/x86/include/asm/jumplabel.h:36 include/trace/events/irq.h:142 kernel/softirq.c:623) irqexitrcu (arch/x86/include/asm/jumplabel.h:36 kernel/softirq.c:725) irqexitrcu (kernel/softirq.c:741) sysvecapictimerinterrupt (arch/x86/kernel/apic/apic.c:1052) </IRQ> <TASK> RIP: 0010:rawspinunlockirqrestore (arch/x86/include/asm/preempt.h:95 include/linux/spinlockapismp.h:152 kernel/locking/spinlock.c:194) freepcppagesbulk (mm/pagealloc.c:1494) drainpageszone (include/linux/spinlock.h:391 mm/pagealloc.c:2632) drainallpages (mm/pagealloc.c:2731) drainallpages (mm/pagealloc.c:2747) kcompactd (mm/compaction.c:3115) kthread (kernel/kthread.c:465) ? cfikcompactd (mm/compaction.c:3166) ? cfikthread (kernel/kthread.c:412) retfromfork (arch/x86/kernel/process.c:164) ? cfikthread (kernel/kthread.c:412) retfromforkasm (arch/x86/entry/entry64.S:255) </TASK>

Matthew has analyzed the report and identified that in drainpagezone() we are in a section protected by spinlock(&pcp->lock) and then get an interrupt that attempts spintrylock() on the same lock. The code is designed to work this way without disabling IRQs and occasionally fail the trylock with a fallback. However, the SMP=n spinlock implementation assumes spintrylock() will always succeed, and thus it's normally a no-op. Here the enabled lock debugging catches the problem, but otherwise it could cause a corruption of the pcp structure.

The problem has been introduced by commit 574907741599 ("mm/pagealloc: leave IRQs enabled for per-cpu page allocations"). The pcp locking scheme recognizes the need for disabling IRQs to prevent nesting spintrylock() sections on SMP=n, but the need to prevent the nesting in spinlock() has not been recognized. Fix it by introducing local wrappers that change the spinlock() to spinlockiqsave() with SMP=n and use them in all places that do spinlock(&pcp->lock).

[vbabka@suse.cz: add pcp prefix to the spinlockirqsave wrappers, per Steven]

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

nvdimm/bus: Fix potential use after free in asynchronous initialization

Dingisoul with KASAN reports a use after free if deviceadd() fails in ndasyncdeviceregister().

Commit b6eae0f61db2 ("libnvdimm: Hold reference on parent while scheduling async init") correctly added a reference on the parent device to be held until asynchronous initialization was complete. However, if deviceadd() results in an allocation failure the ref count of the device drops to 0 prior to the parent pointer being accessed. Thus resulting in use after free.

The bug bot AI correctly identified the fix. Save a reference to the parent pointer to be used to drop the parent reference regardless of the outcome of deviceadd().

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

drm/amd/display: Do not skip unrelated mode changes in DSC validation

Starting with commit 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check"), amdgpu resets the CRTC state modechanged flag to false when recomputing the DSC configuration results in no timing change for a particular stream.

However, this is incorrect in scenarios where a change in MST/DSC configuration happens in the same KMS commit as another (unrelated) mode change. For example, the integrated panel of a laptop may be configured differently (e.g., HDR enabled/disabled) depending on whether external screens are attached. In this case, plugging in external DP-MST screens may result in the modechanged flag being dropped incorrectly for the integrated panel if its DSC configuration did not change during precomputation in prevalidatedsc().

At this point, however, dmupdatecrtcstate() has already created new streams for CRTCs with DSC-independent mode changes. In turn, amdgpudmcommitstreams() will never release the old stream, resulting in a memory leak. amdgpudmatomiccommittail() will never acquire a reference to the new stream either, which manifests as a use-after-free when the stream gets disabled later on:

BUG: KASAN: use-after-free in dcstreamrelease+0x25/0x90 [amdgpu] Write of size 4 at addr ffff88813d836524 by task kworker/9:9/29977

Workqueue: events drmmodermfbworkfn Call Trace: <TASK> dumpstacklvl+0x6e/0xa0 printaddressdescription.constprop.0+0x88/0x320 ? dcstreamrelease+0x25/0x90 [amdgpu] printreport+0xfc/0x1ff ? srsoaliasreturnthunk+0x5/0xfbef5 ? virtaddrvalid+0x225/0x4e0 ? dcstreamrelease+0x25/0x90 [amdgpu] kasanreport+0xe1/0x180 ? dcstreamrelease+0x25/0x90 [amdgpu] kasancheckrange+0x125/0x200 dcstreamrelease+0x25/0x90 [amdgpu] dcstatedestruct+0x14d/0x5c0 [amdgpu] dcstaterelease.part.0+0x4e/0x130 [amdgpu] dmatomicdestroystate+0x3f/0x70 [amdgpu] drmatomicstatedefaultclear+0x8ee/0xf30 ? drmmodeobjectput.part.0+0xb1/0x130 drmatomicstatefree+0x15c/0x2d0 atomicremovefb+0x67e/0x980

Since there is no reliable way of figuring out whether a CRTC has unrelated mode changes pending at the time of DSC validation, remember the value of the modechanged flag from before the point where a CRTC was marked as potentially affected by a change in DSC configuration. Reset the modechanged flag to this earlier value instead in prevalidatedsc().

(cherry picked from commit cc7c7121ae082b7b82891baa7280f1ff2608f22b)

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

crypto: caam - fix DMA corruption on long hmac keys

When a key longer than block size is supplied, it is copied and then hashed into the real key. The memory allocated for the copy needs to be rounded to DMA cache alignment, as otherwise the hashed key may corrupt neighbouring memory.

The rounding was performed, but never actually used for the allocation. Fix this by replacing kmemdup with kmalloc for a larger buffer, followed by memcpy.

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

serial: caif: fix use-after-free in caifserial ldiscclose()

There is a use-after-free bug in caifserial where handletx() may access ser->tty after the tty has been freed.

The race condition occurs between ldiscclose() and packet transmission:

CPU 0 (close) CPU 1 (xmit) ------------- ------------ ldiscclose() ttykrefput(ser->tty) [tty may be freed here] <-- race window --> caifxmit() handletx() tty = ser->tty // dangling ptr tty->ops->write() // UAF! schedulework() serrelease() unregisternetdevice()

The root cause is that ttykrefput() is called in ldiscclose() while the network device is still active and can receive packets.

Since ser and tty have a 1:1 binding relationship with consistent lifecycles (ser is allocated in ldiscopen and freed in serrelease via unregisternetdevice, and each ser binds exactly one tty), we can safely defer the tty reference release to serrelease() where the network device is unregistered.

Fix this by moving ttykrefput() from ldiscclose() to serrelease(), after unregisternetdevice(). This ensures the tty reference is held as long as the network device exists, preventing the UAF.

Note: We save ser->tty before unregisternetdevice() because ser is embedded in netdev's private data and will be freed along with netdev (needsfreenetdev = true).

How to reproduce: Add mdelay(500) at the beginning of ldiscclose() to widen the race window, then run the reproducer program [1].

Note: There is a separate deadloop issue in handletx() when using PORTUNKNOWN serial ports (e.g., /dev/ttyS3 in QEMU without proper serial backend). This deadloop exists even without this patch, and is likely caused by inconsistency between uartwriteroom() and uartwrite() in serial core. It has been addressed in a separate patch [2].

KASAN report:

================================================================== BUG: KASAN: slab-use-after-free in handletx+0x5d1/0x620 Read of size 1 at addr ffff8881131e1490 by task caifuaftrigge/9929

Call Trace: <TASK> dumpstacklvl+0x10e/0x1f0 printreport+0xd0/0x630 kasanreport+0xe4/0x120 handletx+0x5d1/0x620 devhardstartxmit+0x9d/0x6c0 devqueuexmit+0x6e2/0x4410 packetxmit+0x243/0x360 packetsendmsg+0x26cf/0x5500 syssendto+0x4a3/0x520 x64syssendto+0xe0/0x1c0 dosyscall64+0xc9/0xf80 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f615df2c0d7

Allocated by task 9930:

Freed by task 64:

Last potentially related work creation:

The buggy address belongs to the object at ffff8881131e1000 which belongs to the cache kmalloc-cg-2k of size 2048 The buggy address is located 1168 bytes inside of freed 2048-byte region [ffff8881131e1000, ffff8881131e1800)

The buggy address belongs to the physical page: pageowner tracks the page as allocated page last free pid 9778 tgid 9778 stack trace:

Memory state around the buggy address: ffff8881131e1380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881131e1500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [1]: https://gist.github.com/mrpre/f683f244544f7b11e7fa87df9e6c2eeb [2]: https://lore.kernel.org/linux-serial/20260204074327.226165-1-jiayuan.chen@linux.dev/T/#u