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:

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.

dlm: validate length in dlmsearchrsbtree

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

ipc/shm: serialize orphan cleanup with shmnattch updates

shmdestroyorphaned() walks the shm idr under shmids(ns).rwsem, but that does not serialize all fields tested by shmmaydestroy(). In particular, shmnattch is updated while holding shmperm.lock, and attach paths can do that without holding the rwsem.

Do not decide that an orphaned segment is unused before taking the object lock. Move the shmmaydestroy() check under shmperm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.

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.

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

staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing

The Extended Supported Rates (ESR) IE handling in OnBeacon accessed (p + 1 + ielen) and (p + 2 + ielen) without verifying that these offsets lie within the received frame buffer. A malformed beacon with an ESR IE positioned at the end of the buffer could cause an out-of-bounds read, potentially triggering a kernel panic.

Add a boundary check to ensure that the ESR IE body and the subsequent bytes are within the limits of the frame before attempting to access them.

This prevents OOB reads caused by malformed beacon frames.

fs: ntfs3: fix infinite loop in attrloadrunsrange on inconsistent metadata

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

cxl/mbox: validate payload size before accessing contents in cxlpayloadfromuserallowed()

cxlpayloadfromuserallowed() casts and dereferences the input payload without first verifying its size. When a raw mailbox command is sent with an undersized payload (ie: 1 byte for CXLMBOXOPCLEARLOG, which expects a 16-byte UUID), uuidequal() reads past the allocated buffer, triggering a KASAN splat:

BUG: KASAN: slab-out-of-bounds in memcmp+0x176/0x1d0 lib/string.c:683 Read of size 8 at addr ffff88810130f5c0 by task syz.1.62/2258

CPU: 2 UID: 0 PID: 2258 Comm: syz.1.62 Not tainted 6.19.0-dirty #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0xab/0xe0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xce/0x650 mm/kasan/report.c:482 kasanreport+0xce/0x100 mm/kasan/report.c:595 memcmp+0x176/0x1d0 lib/string.c:683 uuidequal include/linux/uuid.h:73 [inline] cxlpayloadfromuserallowed drivers/cxl/core/mbox.c:345 [inline] cxlmboxcmdctor drivers/cxl/core/mbox.c:368 [inline] cxlvalidatecmdfromuser drivers/cxl/core/mbox.c:522 [inline] cxlsendcmd+0x9c0/0xb50 drivers/cxl/core/mbox.c:643 cxlmemdevioctl drivers/cxl/core/memdev.c:698 [inline] cxlmemdevioctl+0x14f/0x190 drivers/cxl/core/memdev.c:713 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:597 [inline] sesysioctl fs/ioctl.c:583 [inline] x64sysioctl+0x18e/0x210 fs/ioctl.c:583 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xa8/0x330 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fdaf331ba79 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fdaf1d77038 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fdaf3585fa0 RCX: 00007fdaf331ba79 RDX: 00002000000001c0 RSI: 00000000c030ce02 RDI: 0000000000000003 RBP: 00007fdaf33749df R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fdaf3586038 R14: 00007fdaf3585fa0 R15: 00007ffced2af768 </TASK>

Add 'insize' parameter to cxlpayloadfromuserallowed() and validate the payload is large enough.

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.

Since commit c56e022c0a27 ("iouring: add support for user mapped provided buffer ring"), landed in Linux 6.4, iouring makes it possible to allocate, mmap, and deallocate "buffer rings".

A "buffer ring" can be allocated with iouringregister(..., IORINGREGISTERPBUFRING, ...) and later deallocated with iouringregister(..., IORINGUNREGISTERPBUFRING, ...). It can be mapped into userspace using mmap() with offset IORINGOFFPBUFRING|..., which creates a VMPFNMAP mapping, meaning the MM subsystem will treat the mapping as a set of opaque page frame numbers not associated with any corresponding pages; this implies that the calling code is responsible for ensuring that the mapped memory can not be freed before the userspace mapping is removed.

However, there is no mechanism to ensure this in iouring: It is possible to just register a buffer ring with IORINGREGISTERPBUFRING, mmap() it, and then free the buffer ring's pages with IORINGUNREGISTERPBUFRING, leaving free pages mapped into userspace, which is a fairly easily exploitable situation.

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c392cbecd8eca4c53f2bf508731257d9d0a21c2d

The “Dirty Frag” vulnerability is a chained local privilege escalation (LPE) issue in the Linux kernel that combines flaws in the ESP/XFRM and RXRPC subsystems to allow an unprivileged local attacker to gain root access on major Linux distributions. The attack abuses kernel page-cache manipulation and network protocol handling to overwrite privileged binaries and execute arbitrary code with elevated privileges. Exploitation differs by distribution: the ESP issue affects systems permitting unprivileged user namespaces, while the RXRPC issue impacts distributions with RXRPC enabled, such as Ubuntu. Together, the vulnerabilities provide broad cross-distribution root compromise capability, with mitigations involving disabling vulnerable kernel modules (esp4, esp6, and rxrpc) until upstream patches are fully merged and deployed.

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:

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.