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:

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:

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:

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:

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.

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:

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

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

hwmon: (pt5161l) Fix bugs in pt5161lreadblockdata()

Fix two bugs in pt5161lreadblockdata():

1. Buffer overrun: The local buffer rbuf is declared as u8 rbuf[24], but i2csmbusreadblockdata() can return up to I2CSMBUSBLOCKMAX (32) bytes. The i2c-core copies the data into the caller's buffer before the return value can be checked, so the post-read length validation does not prevent a stack overrun if a device returns more than 24 bytes. Resize the buffer to I2CSMBUSBLOCKMAX.

2. Unexpected positive return on length mismatch: When all three retries are exhausted because the device returns data with an unexpected length, i2csmbusreadblockdata() returns a positive byte count. The function returns this directly, and callers treat any non-negative return as success, processing stale or incomplete buffer contents. Return -EIO when retries are exhausted with a positive return value, preserving the negative error code on I2C failure.

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

RDMA/hns: Fix unlocked call to hnsroceqpremove()

Sashiko points out that hnsroceqpremove() requires the caller to hold locks. The error flow in hnsrocecreateqpcommon() doesn't hold those locks for the error unwind so it risks corrupting memory.

Grab the same locks the other two callers use.

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

RDMA/mlx5: Fix error path fall-through in mlx5ibdevressrqinit()

mlx5ibdevressrqinit() allocates two SRQs, s0 and s1. When ibcreatesrq() fails for s1, the error branch destroys s0 but falls through and unconditionally assigns the freed s0 and the ERRPTR s1 to devr->s0 and devr->s1.

This leads to several problems: the lock-free fast path checks "if (devr->s1) return 0;" and treats the ERRPTR as already initialised; users in mlx5ibcreateqp() dereference the freed SRQ or ERRPTR via tomsrq(devr->s0)->msrq.srqn; and mlx5ibdevrescleanup() dereferences the ERRPTR and double-frees s0 on teardown.

Fix by adding the same goto unlock in the s1 failure path.

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

nfc: hci: shdlc: Stop timers and work before freeing context

llcshdlcdeinit() purges SHDLC skb queues and frees the llcshdlc structure while its timers and state machine work may still be active.

Timer callbacks can schedule smwork, and smwork accesses SHDLC state and the skb queues. If teardown happens in parallel with a queued/running work item, it can lead to UAF and other shutdown races.

Stop all SHDLC timers and cancel smwork synchronously before purging the queues and freeing the context.

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

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

can: j1939: fix errant WARNONONCE in j1939sessiondeactivate

The conclusion "j1939sessiondeactivate() should be called with a session ref-count of at least 2" is incorrect. In some concurrent scenarios, j1939sessiondeactivate can be called with the session ref-count less than 2. But there is not any problem because it will check the session active state before session putting in j1939sessiondeactivatelocked().

Here is the concurrent scenario of the problem reported by syzbot and my reproduction log.

cpu0 cpu1 j1939xtprxeoma j1939xtprxabortone j1939sessiongetbyaddr [kref == 2] j1939sessiongetbyaddr [kref == 3] j1939sessiondeactivate [kref == 2] j1939sessionput [kref == 1] j1939sessioncompleted j1939sessiondeactivate WARNONONCE(kref < 2)

===================================================== WARNING: CPU: 1 PID: 21 at net/can/j1939/transport.c:1088 j1939sessiondeactivate+0x5f/0x70 CPU: 1 PID: 21 Comm: ksoftirqd/1 Not tainted 5.14.0-rc7+ #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014 RIP: 0010:j1939sessiondeactivate+0x5f/0x70 Call Trace: j1939sessiondeactivateactivatenext+0x11/0x28 j1939xtprxeoma+0x12a/0x180 j1939tprecv+0x4a2/0x510 j1939canrecv+0x226/0x380 canrcvfilter+0xf8/0x220 canreceive+0x102/0x220 ? processbacklog+0xf0/0x2c0 canrcv+0x53/0xf0 netifreceiveskbonecore+0x67/0x90 ? processbacklog+0x97/0x2c0 netifreceiveskb+0x22/0x80

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

udplite: Fix NULL pointer dereference in skmemraiseallocated().

syzbot reported [0] a null-ptr-deref in skgetrmem0() while using IPPROTOUDPLITE (0x88):

14:25:52 executing program 1: r0 = socket$inet6(0xa, 0x80002, 0x88)

We had a similar report [1] for probably skmemoryallocatedadd() in skmemraiseallocated(), and commit c915fe13cbaa ("udplite: fix NULL pointer dereference") fixed it by setting .memoryallocated for udpliteprot and udplitev6prot.

To fix the variant, we need to set either .sysctlwmemoffset or .sysctlrmem.

Now UDP and UDPLITE share the same value for .memoryallocated, so we use the same .sysctlwmemoffset for UDP and UDPLITE.

[0]: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 6829 Comm: syz-executor.1 Not tainted 6.4.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023 RIP: 0010:skgetrmem0 include/net/sock.h:2907 [inline] RIP: 0010:skmemraiseallocated+0x806/0x17a0 net/core/sock.c:3006 Code: c1 ea 03 80 3c 02 00 0f 85 23 0f 00 00 48 8b 44 24 08 48 8b 98 38 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <0f> b6 14 02 48 89 d8 83 e0 07 83 c0 03 38 d0 0f 8d 6f 0a 00 00 8b RSP: 0018:ffffc90005d7f450 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004d92000 RDX: 0000000000000000 RSI: ffffffff88066482 RDI: ffffffff8e2ccbb8 RBP: ffff8880173f7000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000030000 R13: 0000000000000001 R14: 0000000000000340 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9800000(0063) knlGS:00000000f7f1cb40 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 000000002e82f000 CR3: 0000000034ff0000 CR4: 00000000003506f0 Call Trace: <TASK> skmemschedule+0x6c/0xe0 net/core/sock.c:3077 udprmemschedule net/ipv4/udp.c:1539 [inline] udpenqueuescheduleskb+0x776/0xb30 net/ipv4/udp.c:1581 udpv6queuercvskb net/ipv6/udp.c:666 [inline] udpv6queuercvoneskb+0xc39/0x16c0 net/ipv6/udp.c:775 udpv6queuercvskb+0x194/0xa10 net/ipv6/udp.c:793 udp6libmcastdeliver net/ipv6/udp.c:906 [inline] udp6librcv+0x1bda/0x2bd0 net/ipv6/udp.c:1013 ip6protocoldeliverrcu+0x2e7/0x1250 net/ipv6/ip6input.c:437 ip6inputfinish+0x150/0x2f0 net/ipv6/ip6input.c:482 NFHOOK include/linux/netfilter.h:303 [inline] NFHOOK include/linux/netfilter.h:297 [inline] ip6input+0xa0/0xd0 net/ipv6/ip6input.c:491 ip6mcinput+0x40b/0xf50 net/ipv6/ip6input.c:585 dstinput include/net/dst.h:468 [inline] ip6rcvfinish net/ipv6/ip6input.c:79 [inline] NFHOOK include/linux/netfilter.h:303 [inline] NFHOOK include/linux/netfilter.h:297 [inline] ipv6rcv+0x250/0x380 net/ipv6/ip6input.c:309 netifreceiveskbonecore+0x114/0x180 net/core/dev.c:5491 netifreceiveskb+0x1f/0x1c0 net/core/dev.c:5605 netifreceiveskbinternal net/core/dev.c:5691 [inline] netifreceiveskb+0x133/0x7a0 net/core/dev.c:5750 tunrxbatched+0x4b3/0x7a0 drivers/net/tun.c:1553 tungetuser+0x2452/0x39c0 drivers/net/tun.c:1989 tunchrwriteiter+0xdf/0x200 drivers/net/tun.c:2035 callwriteiter include/linux/fs.h:1868 [inline] newsyncwrite fs/readwrite.c:491 [inline] vfswrite+0x945/0xd50 fs/readwrite.c:584 ksyswrite+0x12b/0x250 fs/readwrite.c:637 dosyscall32irqson arch/x86/entry/common.c:112 [inline] dofastsyscall32+0x65/0xf0 arch/x86/entry/common.c:178 dofastsyscall32+0x33/0x70 arch/x86/entry/common.c:203 entrySYSENTERcompatafterhwframe+0x70/0x82 RIP: 0023:0xf7f21579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 ---truncated---

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

pppoe: drop PFC frames

RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT RECOMMENDED for PPPoE. In practice, pppd does not support negotiating PFC for PPPoE sessions, and the current PPPoE driver assumes an uncompressed (2-byte) protocol field. However, the generic PPP layer function pppinput() is not aware of the negotiation result, and still accepts PFC frames.

If a peer with a broken implementation or an attacker sends a frame with a compressed (1-byte) protocol field, the subsequent PPP payload is shifted by one byte. This causes the network header to be 4-byte misaligned, which may trigger unaligned access exceptions on some architectures.

To reduce the attack surface, drop PPPoE PFC frames. Introduce pppskbiscompressedproto() helper function to be used in both pppgeneric.c and pppoe.c to avoid open-coding.

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

drm/dp: Fix OOB read when handling Post Cursor2 register

The linkstatus array was not large enough to read the Adjust Request Post Cursor2 register, so remove the common helper function to avoid an OOB read, found with a -Warray-bounds build:

drivers/gpu/drm/drmdphelper.c: In function 'drmdpgetadjustrequestpostcursor': drivers/gpu/drm/drmdphelper.c:59:27: error: array subscript 10 is outside array bounds of 'const u8[6]' {aka 'const unsigned char[6]'} [-Werror=array-bounds] 59 | return linkstatus[r - DPLANE01STATUS]; | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/drmdphelper.c:147:51: note: while referencing 'linkstatus' 147 | u8 drmdpgetadjustrequestpostcursor(const u8 linkstatus[DPLINKSTATUSSIZE], | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Replace the only user of the helper with an open-coded fetch and decode, similar to drivers/gpu/drm/amd/display/dc/core/dclinkdp.c.

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

comedi: pcl812: Fix bit shift out of bounds

When checking for a supported IRQ number, the following test is used:

if ((1 << it->options[1]) & board->irqbits) {

However, it->options[i] is an unchecked int value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring it->options[1] to be within bounds before proceeding with the original test. Valid it->options[1] values that select the IRQ will be in the range [1,15]. The value 0 explicitly disables the use of interrupts.