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.

afkey: validate families in pfkeysendmigrate()

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

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:

ksm: use range-walk function to jump over holes in scangetnextrmapitem

Currently, scangetnextrmapitem() walks every page address in a VMA to locate mergeable pages. This becomes highly inefficient when scanning large virtual memory areas that contain mostly unmapped regions, causing ksmd to use large amount of cpu without deduplicating much pages.

This patch replaces the per-address lookup with a range walk using walkpagerange(). The range walker allows KSM to skip over entire unmapped holes in a VMA, avoiding unnecessary lookups. This problem was previously discussed in [1].

Consider the following test program which creates a 32 TiB mapping in the virtual address space but only populates a single page:

#include <unistd.h> #include <stdio.h> #include <sys/mman.h>

/ 32 TiB / const sizet size = 32ul 1024 1024 1024 1024;

int main() { char area = mmap(NULL, size, PROTREAD | PROTWRITE, MAPNORESERVE | MAPPRIVATE | MAPANON, -1, 0);

if (area == MAPFAILED) { perror("mmap() failed\n"); return -1; }

/ Populate a single page such that we get an anonvma. / area = 0;

/ Enable KSM. / madvise(area, size, MADVMERGEABLE); pause(); return 0; }

$ ./ksm-sparse & $ echo 1 > /sys/kernel/mm/ksm/run

Without this patch ksmd uses 100% of the cpu for a long time (more then 1 hour in my test machine) scanning all the 32 TiB virtual address space that contain only one mapped page. This makes ksmd essentially deadlocked not able to deduplicate anything of value. With this patch ksmd walks only the one mapped page and skips the rest of the 32 TiB virtual address space, making the scan fast using little cpu.

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:

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.

dm: fix unconditional IO throttle caused by REQPREFLUSH

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:

ceph: fix memory leak in cephreaddir when notelastdentry returns error

Reset the lastreaddir at the same time, and add a comment explaining why we don't free lastreaddir when diremit returns false.

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:

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:

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:

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:

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:

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:

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:

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:

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.

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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