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

net: nexthop: fix percpu use-after-free in removenhgrpentry

When removing a nexthop from a group, removenhgrpentry() publishes the new group via rcuassignpointer() then immediately frees the removed entry's percpu stats with freepercpu(). However, the synchronizenet() grace period in the caller removenexthopfromgroups() runs after the free. RCU readers that entered before the publish still see the old group and can dereference the freed stats via nhgrpentrystatsinc() -> getcpuptr(nhge->stats), causing a use-after-free on percpu memory.

Fix by deferring the freepercpu() until after synchronizenet() in the caller. Removed entries are chained via nhlist onto a local deferred free list. After the grace period completes and all RCU readers have finished, the percpu stats are safely freed.

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

ksmbd: fix use-after-free in ksmbdclosefd() via durable scavenger

When a durable file handle survives session disconnect (TCP close without SMB2LOGOFF), sessionfdcheck() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->locklist.

Later, when the durable scavenger thread times out and calls ksmbdclosefd(NULL, fp), the lock cleanup loop did:

spinlock(&fp->conn->llistlock);

This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbdtcpdisconnect().

The root cause is asymmetric cleanup: lock entries (smblock->clist) were left dangling on the freed conn->locklist while fp->conn was nulled out.

To fix this issue properly, we need to handle the lifetime of smblock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's locklist in sessionfdcheck() - Re-add the lock to the new connection's locklist in ksmbdreopendurablefd().

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

drm/mediatek: dsi: Store driver data before invoking mipidsihostregister

The call to mipidsihostregister triggers a callback to mtkdsibind, which uses devgetdrvdata to retrieve the mtkdsi struct, so this structure needs to be stored inside the driver data before invoking it.

As drvdata is currently uninitialized it leads to a crash when registering the DSI DRM encoder right after acquiring the modeconfig.idrmutex, blocking all subsequent DRM operations.

Fixes the following crash during mediatek-drm probe (tested on Xiaomi Smart Clock x04g):

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040 [...] Modules linked in: mediatekdrm(+) drmdisplayhelper cec drmclientlib drmdmahelper drmkmshelper panelsimple [...] Call trace: drmmodeobjectadd+0x58/0x98 (P) drmencoderinit+0x48/0x140 drmencoderinit+0x6c/0xa0 drmsimpleencoderinit+0x20/0x34 [drmkmshelper] mtkdsibind+0x34/0x13c [mediatekdrm] componentbindall+0x120/0x280 mtkdrmbind+0x284/0x67c [mediatekdrm] trytobringupaggregatedevice+0x23c/0x320 componentadd+0xa4/0x198 componentadd+0x14/0x20 mtkdsihostattach+0x78/0x100 [mediatekdrm] mipidsiattach+0x2c/0x50 panelsimpledsiprobe+0x4c/0x9c [panelsimple] mipidsidrvprobe+0x1c/0x28 reallyprobe+0xc0/0x3dc driverprobedevice+0x80/0x160 driverprobedevice+0x40/0x120 deviceattachdriver+0xbc/0x17c busforeachdrv+0x88/0xf0 deviceattach+0x9c/0x1cc deviceinitialprobe+0x54/0x60 busprobedevice+0x34/0xa0 deviceadd+0x5b0/0x800 mipidsideviceregisterfull+0xdc/0x16c mipidsihostregister+0xc4/0x17c mtkdsiprobe+0x10c/0x260 [mediatekdrm] platformprobe+0x5c/0xa4 reallyprobe+0xc0/0x3dc driverprobedevice+0x80/0x160 driverprobedevice+0x40/0x120 driverattach+0xc8/0x1f8 busforeachdev+0x7c/0xe0 driverattach+0x24/0x30 busadddriver+0x11c/0x240 driverregister+0x68/0x130 platformregisterdrivers+0x64/0x160 mtkdrminit+0x24/0x1000 [mediatekdrm] dooneinitcall+0x60/0x1d0 doinitmodule+0x54/0x240 loadmodule+0x1838/0x1dc0 initmodulefromfile+0xd8/0xf0 arm64sysfinitmodule+0x1b4/0x428 invokesyscall.constprop.0+0x48/0xc8 doel0svc+0x3c/0xb8 el0svc+0x34/0xe8 el0t64synchandler+0xa0/0xe4 el0t64sync+0x198/0x19c Code: 52800022 941004ab 2a0003f3 37f80040 (29005a80)

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

idpf: fix PREEMPTRT raw/bh spinlock nesting for async VC handling

Switch from using the completion's raw spinlock to a local lock in the idpfvcxn struct. The conversion is safe because complete/all() are called outside the lock and there is no reason to share the completion lock in the current logic. This avoids invalid wait context reported by the kernel due to the async handler taking BH spinlock:

[ 805.726977] ============================= [ 805.726991] [ BUG: Invalid wait context ] [ 805.727006] 7.0.0-rc2-net-devq-031026+ #28 Tainted: G S OE [ 805.727026] ----------------------------- [ 805.727038] kworker/u261:0/572 is trying to lock: [ 805.727051] ff190da6a8dbb6a0 (&vportconfig->macfilterlistlock){+...}-{3:3}, at: idpfmacfilterasynchandler+0xe9/0x260 [idpf] [ 805.727099] other info that might help us debug this: [ 805.727111] context-{5:5} [ 805.727119] 3 locks held by kworker/u261:0/572: [ 805.727132] #0: ff190da6db3e6148 ((wqcompletion)idpf-0000:83:00.0-mbx){+.+.}-{0:0}, at: processonework+0x4b5/0x730 [ 805.727163] #1: ff3c6f0a6131fe50 ((workcompletion)(&(&adapter->mbxtask)->work)){+.+.}-{0:0}, at: processonework+0x1e5/0x730 [ 805.727191] #2: ff190da765190020 (&x->wait#34){+.+.}-{2:2}, at: idpfrecvmbmsg+0xc8/0x710 [idpf] [ 805.727218] stack backtrace: ... [ 805.727238] Workqueue: idpf-0000:83:00.0-mbx idpfmbxtask [idpf] [ 805.727247] Call Trace: [ 805.727249] <TASK> [ 805.727251] dumpstacklvl+0x77/0xb0 [ 805.727259] lockacquire+0xb3b/0x2290 [ 805.727268] ? irqworkqueuelocal+0x59/0x130 [ 805.727275] lockacquire+0xc6/0x2f0 [ 805.727277] ? idpfmacfilterasynchandler+0xe9/0x260 [idpf] [ 805.727284] ? printk+0x5b/0x80 [ 805.727290] rawspinlockbh+0x38/0x50 [ 805.727298] ? idpfmacfilterasynchandler+0xe9/0x260 [idpf] [ 805.727303] idpfmacfilterasynchandler+0xe9/0x260 [idpf] [ 805.727310] idpfrecvmbmsg+0x1c8/0x710 [idpf] [ 805.727317] processonework+0x226/0x730 [ 805.727322] workerthread+0x19e/0x340 [ 805.727325] ? pfxworkerthread+0x10/0x10 [ 805.727328] kthread+0xf4/0x130 [ 805.727333] ? pfxkthread+0x10/0x10 [ 805.727336] retfromfork+0x32c/0x410 [ 805.727345] ? pfxkthread+0x10/0x10 [ 805.727347] retfromforkasm+0x1a/0x30 [ 805.727354] </TASK>

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

mm/vmalloc: prevent RCU stalls in kasanreleasevmallocnode

When CONFIGPAGEOWNER is enabled, freeing KASAN shadow pages during vmalloc cleanup triggers expensive stack unwinding that acquires RCU read locks. Processing a large purgelist without rescheduling can cause the task to hold CPU for extended periods (10+ seconds), leading to RCU stalls and potential OOM conditions.

The issue manifests in purgevmapnode() -> kasanreleasevmallocnode() where iterating through hundreds or thousands of vmaparea entries and freeing their associated shadow pages causes:

rcu: INFO: rcupreempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-0 rcunode (CPUs 0-1): P6229/1:b..l ... task:kworker/0:17 state:R running task stack:28840 pid:6229 ... kasanreleasevmallocnode+0x1ba/0xad0 mm/vmalloc.c:2299 purgevmapnode+0x1ba/0xad0 mm/vmalloc.c:2299

Each call to kasanreleasevmalloc() can free many pages, and with pageowner tracking, each free triggers savestack() which performs stack unwinding under RCU read lock. Without yielding, this creates an unbounded RCU critical section.

Add periodic condresched() calls within the loop to allow: - RCU grace periods to complete - Other tasks to run - Scheduler to preempt when needed

The fix uses needresched() for immediate response under load, with a batch count of 32 as a guaranteed upper bound to prevent worst-case stalls even under light load.

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

x86/cpu: Remove X86CR4FRED from the CR4 pinned bits mask

Commit in Fixes added the FRED CR4 bit to the CR4 pinned bits mask so that whenever something else modifies CR4, that bit remains set. Which in itself is a perfectly fine idea.

However, there's an issue when during boot FRED is initialized: first on the BSP and later on the APs. Thus, there's a window in time when exceptions cannot be handled.

This becomes particularly nasty when running as SEV-{ES,SNP} or TDX guests which, when they manage to trigger exceptions during that short window described above, triple fault due to FRED MSRs not being set up yet.

See Link tag below for a much more detailed explanation of the situation.

So, as a result, the commit in that Link URL tried to address this shortcoming by temporarily disabling CR4 pinning when an AP is not online yet.

However, that is a problem in itself because in this case, an attack on the kernel needs to only modify the online bit - a single bit in RW memory - and then disable CR4 pinning and then disable SMP, leading to more and worse things to happen to the system.

So, instead, remove the FRED bit from the CR4 pinning mask, thus obviating the need to temporarily disable CR4 pinning.

If someone manages to disable FRED when poking at CR4, then idtinvalidate() would make sure the system would crash'n'burn on the first exception triggered, which is a much better outcome security-wise.

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

drm/amdgpu: Change AMDGPUVARESERVEDTRAPSIZE to 64KB

Currently, AMDGPUVARESERVEDTRAPSIZE is hardcoded to 8KB, while KFDCWSRTBATMASIZE is defined as 2 PAGESIZE. On systems with 4K pages, both values match (8KB), so allocation and reserved space are consistent.

However, on 64K page-size systems, KFDCWSRTBATMASIZE becomes 128KB, while the reserved trap area remains 8KB. This mismatch causes the kernel to crash when running rocminfo or rccl unit tests.

Kernel attempted to read user page (2) - exploit attempt? (uid: 1001) BUG: Kernel NULL pointer dereference on read at 0x00000002 Faulting instruction address: 0xc0000000002c8a64 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGESIZE=64K MMU=Radix SMP NRCPUS=2048 NUMA pSeries CPU: 34 UID: 1001 PID: 9379 Comm: rocminfo Tainted: G E 6.19.0-rc4-amdgpu-00320-gf23176405700 #56 VOLUNTARY Tainted: [E]=UNSIGNEDMODULE Hardware name: IBM,9105-42A POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.30 (ML1060896) hv:phyp pSeries NIP: c0000000002c8a64 LR: c00000000125dbc8 CTR: c00000000125e730 REGS: c0000001e0957580 TRAP: 0300 Tainted: G E MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24008268 XER: 00000036 CFAR: c00000000125dbc4 DAR: 0000000000000002 DSISR: 40000000 IRQMASK: 1 GPR00: c00000000125d908 c0000001e0957820 c0000000016e8100 c00000013d814540 GPR04: 0000000000000002 c00000013d814550 0000000000000045 0000000000000000 GPR08: c00000013444d000 c00000013d814538 c00000013d814538 0000000084002268 GPR12: c00000000125e730 c000007e2ffd5f00 ffffffffffffffff 0000000000020000 GPR16: 0000000000000000 0000000000000002 c00000015f653000 0000000000000000 GPR20: c000000138662400 c00000013d814540 0000000000000000 c00000013d814500 GPR24: 0000000000000000 0000000000000002 c0000001e0957888 c0000001e0957878 GPR28: c00000013d814548 0000000000000000 c00000013d814540 c0000001e0957888 NIP [c0000000002c8a64] mutexaddwaiter+0x24/0xc0 LR [c00000000125dbc8] mutexlock.constprop.0+0x318/0xd00 Call Trace: 0xc0000001e0957890 (unreliable) mutexlock.constprop.0+0x58/0xd00 amdgpuamdkfdgpuvmallocmemoryofgpu+0x6fc/0xb60 [amdgpu] kfdprocessallocgpuvm+0x54/0x1f0 [amdgpu] kfdprocessdeviceinitcwsrdgpu+0xa4/0x1a0 [amdgpu] kfdprocessdeviceinitvm+0xd8/0x2e0 [amdgpu] kfdioctlacquirevm+0xd0/0x130 [amdgpu] kfdioctl+0x514/0x670 [amdgpu] sysioctl+0x134/0x180 systemcallexception+0x114/0x300 systemcallvectoredcommon+0x15c/0x2ec

This patch changes AMDGPUVARESERVEDTRAPSIZE to 64 KB and KFDCWSRTBATMASIZE to the AMD GPU page size. This means we reserve 64 KB for the trap in the address space, but only allocate 8 KB within it. With this approach, the allocation size never exceeds the reserved area.

(cherry picked from commit 31b8de5e55666f26ea7ece5f412b83eab3f56dbb)

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

smb: client: fix off-by-8 bounds check in checkwsleas()

The bounds check uses (u8 )ea + nlen + 1 + vlen as the end of the EA name and value, but eadata sits at offset sizeof(struct smb2filefulleainfo) = 8 from ea, not at offset 0. The strncmp() later reads ea->eadata[0..nlen-1] and the value bytes follow at eadata[nlen+1..nlen+vlen], so the actual end is ea->eadata + nlen + 1 + vlen. Isn't pointer math fun?

The earlier check (u8 )ea > end - sizeof(ea) only guarantees the 8-byte header is in bounds, but since the last EA is placed within 8 bytes of the end of the response, the name and value bytes are read past the end of iov.

Fix this mess all up by using ea->eadata as the base for the bounds check.

An "untrusted" server can use this to leak up to 8 bytes of kernel heap into the EA name comparison and influence which WSL xattr the data is interpreted as.

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

net: fix memory leak in skbsegmentlist for GRO packets

When skbsegmentlist() is called during packet forwarding, it handles packets that were aggregated by the GRO engine.

Historically, the segmentation logic in skbsegmentlist assumes that individual segments are split from a parent SKB and may need to carry their own socket memory accounting. Accordingly, the code transfers truesize from the parent to the newly created segments.

Prior to commit ed4cccef64c1 ("gro: fix ownership transfer"), this truesize subtraction in skbsegmentlist() was valid because fragments still carry a reference to the original socket.

However, commit ed4cccef64c1 ("gro: fix ownership transfer") changed this behavior by ensuring that fraglist entries are explicitly orphaned (skb->sk = NULL) to prevent illegal orphaning later in the stack. This change meant that the entire socket memory charge remained with the head SKB, but the corresponding accounting logic in skbsegmentlist() was never updated.

As a result, the current code unconditionally adds each fragment's truesize to deltatruesize and subtracts it from the parent SKB. Since the fragments are no longer charged to the socket, this subtraction results in an effective under-count of memory when the head is freed. This causes skwmemalloc to remain non-zero, preventing socket destruction and leading to a persistent memory leak.

The leak can be observed via KMEMLEAK when tearing down the networking environment:

unreferenced object 0xffff8881e6eb9100 (size 2048): comm "ping", pid 6720, jiffies 4295492526 backtrace: kmemcacheallocnoprof+0x5c6/0x800 skprotalloc+0x5b/0x220 skalloc+0x35/0xa00 inet6create.part.0+0x303/0x10d0 sockcreate+0x248/0x640 syssocket+0x11b/0x1d0

Since skbsegmentlist() is exclusively used for SKBGSOFRAGLIST packets constructed by GRO, the truesize adjustment is removed.

The call to skbreleaseheadstate() must be preserved. As documented in commit cf673ed0e057 ("net: fix fraglist segmentation reference count leak"), it is still required to correctly drop references to SKB extensions that may be overwritten during copyskbheader().

Bluetooth: hcisync: hcicmdsyncqueueonce() return -EEXIST if exists

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

f2fs: fix to avoid memory leak in f2fsrename()

syzbot reported a f2fs bug as below:

BUG: memory leak unreferenced object 0xffff888127f70830 (size 16): comm "syz.0.23", pid 6144, jiffies 4294943712 hex dump (first 16 bytes): 3c af 57 72 5b e6 8f ad 6e 8e fd 33 42 39 03 ff <.Wr[...n..3B9.. backtrace (crc 925f8a80): kmemleakallocrecursive include/linux/kmemleak.h:44 [inline] slabpostallochook mm/slub.c:4520 [inline] slaballocnode mm/slub.c:4844 [inline] dokmallocnode mm/slub.c:5237 [inline] kmallocnoprof+0x3bd/0x560 mm/slub.c:5250 kmallocnoprof include/linux/slab.h:954 [inline] fscryptsetupfilename+0x15e/0x3b0 fs/crypto/fname.c:364 f2fssetupfilename+0x52/0xb0 fs/f2fs/dir.c:143 f2fsrename+0x159/0xca0 fs/f2fs/namei.c:961 f2fsrename2+0xd5/0xf20 fs/f2fs/namei.c:1308 vfsrename+0x7ff/0x1250 fs/namei.c:6026 filenamerenameat2+0x4f4/0x660 fs/namei.c:6144 dosysrenameat2 fs/namei.c:6173 [inline] sesysrenameat2 fs/namei.c:6168 [inline] x64sysrenameat2+0x59/0x80 fs/namei.c:6168 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xe2/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

The root cause is in commit 40b2d55e0452 ("f2fs: fix to create selinux label during whiteout initialization"), we added a call to f2fssetupfilename() without a matching call to f2fsfreefilename(), fix it.

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

ksmbd: validate owner of durable handle on reconnect

Currently, ksmbd does not verify if the user attempting to reconnect to a durable handle is the same user who originally opened the file. This allows any authenticated user to hijack an orphaned durable handle by predicting or brute-forcing the persistent ID.

According to MS-SMB2, the server MUST verify that the SecurityContext of the reconnect request matches the SecurityContext associated with the existing open. Add a durableowner structure to ksmbdfile to store the original opener's UID, GID, and account name. and catpure the owner information when a file handle becomes orphaned. and implementing ksmbdvfscomparedurableowner() to validate the identity of the requester during SMB2CREATE (DHnC).

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

nvmem: zynqmpnvmem: Fix buffer size in DMA and memcpy

Buffer size used in dma allocation and memcpy is wrong. It can lead to undersized DMA buffer access and possible memory corruption. use correct buffer size in dmaalloccoherent and memcpy.

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

gpio: Fix resource leaks on errors in gpiochipadddatawithkey()

Since commit aab5c6f20023 ("gpio: set device type for GPIO chips"), gdev->dev.release is unset. As a result, the reference count to gdev->dev isn't dropped on the error handling paths.

Drop the reference on errors.

Also reorder the instructions to make the error handling simpler. Now gpiochipadddatawithkey() roughly looks like:

>>> Some memory allocation. Go to ERR ZONE 1 on errors. >>> deviceinitialize().

gpiodevrelease() takes over the responsibility for freeing the resources of gdev->dev. The subsequent error handling paths shouldn't go through ERR ZONE 1 again which leads to double free.

>>> Some initialization mainly on gdev. >>> The rest of initialization. Go to ERR ZONE 2 on errors. >>> Chip registration success and exit.

>>> ERR ZONE 2. gpiodeviceput() and exit. >>> ERR ZONE 1.

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

reset: gpio: suppress bind attributes in sysfs

This is a special device that's created dynamically and is supposed to stay in memory forever. We also currently don't have a devlink between it and the actual reset consumer. Suppress sysfs bind attributes so that user-space can't unbind the device because - as of now - it will cause a use-after-free splat from any user that puts the reset control handle.

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

wifi: iwlwifi: mvm: don't send a 6E related command when not supported

MCCALLOWEDAPTYPECMD is related to 6E support. Do not send it if the device doesn't support 6E. Apparently, the firmware is mistakenly advertising support for this command even on AX201 which does not support 6E and then the firmware crashes.

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

ksmbd: fix use-after-free in smblazyparentleasebreakclose()

opinfo pointer obtained via rcudereference(fp->fopinfo) is being accessed after rcureadunlock() has been called. This creates a race condition where the memory could be freed by a concurrent writer between the unlock and the subsequent pointer dereferences (opinfo->islease, etc.), leading to a use-after-free.

afunix: Set gcinprogress to true in unixgc().

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

ipv6: Fix a potential NPD in cleanupprefixroute()

addrconfgetprefixroute() can return the fib6nullentry sentinel entry which has a NULL fib6table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1].

Note that the other callers of addrconfgetprefixroute() are not susceptible to this bug:

1. addrconfprefixrcv(): Requests a route with the 'RTFADDRCONF | RTFPREFIXRT' flags which are not set on fib6nullentry.

2. modifyprefixroute(): Fixed by commit a747e02430df ("ipv6: avoid possible NULL deref in modifyprefixroute()").

3. ipv6ifanotify(): Calls ip6delrt() which specifically checks for fib6nullentry and returns an error.

[1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: <TASK> kasancheckbyte (mm/kasan/common.c:573) lockacquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) rawspinlockbh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanupprefixroute (net/ipv6/addrconf.c:1280) ipv6deladdr (net/ipv6/addrconf.c:1342) inet6addrdel.isra.0 (net/ipv6/addrconf.c:3119) inet6rtmdeladdr (net/ipv6/addrconf.c:4812) rtnetlinkrcvmsg (net/core/rtnetlink.c:6997) netlinkrcvskb (net/netlink/afnetlink.c:2555) netlinkunicast (net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/afnetlink.c:1899) socksendmsg (net/socket.c:802 (discriminator 4)) syssendmsg (net/socket.c:2698) syssendmsg (net/socket.c:2752) syssendmsg (net/socket.c:2784) dosyscall64 (arch/x86/entry/syscall64.c:63 arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:121)

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

Bluetooth: L2CAP: fix chan ref leak in l2capchantimeout() on !conn

setchantimer() takes a l2capchan reference via l2capchanhold() before scheduling the delayed work. The normal path in l2capchantimeout() drops this reference with l2capchanput() at the end, but the early return when chan->conn is NULL skips the put, leaking the reference.

Add the missing l2capchanput() before the early return.

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

ASoC: Intel: avs: Refactor and fix initconfig access

Existing code accesses enties found in ->initconfigs array through indexes that are part of ->configids array. Those two are limited by: ->numinitconfigs and ->numconfigids respectively. Using ID larger or equal to ->numinitconfigs leads to out-of-bounds access:

avspathmodulesendinitconfigs() loop: (...) &acomp->tplg->initconfigs[ids[i]] ^ out-of-bounds candidate

Rather than adding another if-statement, refactor the code. There is no need to store the IDs, have a list of pointers to actual config-entries instead. As the verification of ->initconfig entries does not differ from verification of other types that are part of the topology.c file, simply reuse the code.

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

usb: gadget: ffs: Initialize epfile->in early to fix endpoint direction checks

When parsing endpoint descriptors, ffsdatagotdescs() generates the epsaddrmap which contains the endpoint direction. However, epfile->in was previously only populated in ffsfuncepsenable() which executes upon USB host connection. As a result, early userspace ioctls like FUNCTIONFSDMABUFATTACH that run before the host connects would see epfile->in as 0, leading to incorrect DMA directions.

By moving the initialization to ffsepfilescreate(), epfile->in is accurate before userspace opens the endpoint files.

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

usb: gadget: ffs: Fix DMA fence leak

In ffsdmabuftransfer(), a ffsdmafence object is kmalloc'd, with the underlying dmafence later initialized by dmafenceinit(), which sets its kref counter to 1. Then, dmaresvaddfence() gets a second reference, and a pointer to the ffsdmafence is passed as the usbrequest's "context" field.

The dma-resv mechanism will manage the second reference, but the first reference is never properly released; the ffsdmabufcleanup() function decreases the reference count, but only to balance with the reference grab in ffsdmabufsignaldone().

The code will then slowly leak memory as more ffsdmafence objects are created without being ever freed.

Address this issue by transferring ownership of the fence to the DMA reservation object, by calling dmafenceput() right after dmaresvaddfence(). The ffsdmafence then gets properly discarded after being signalled.

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

kernel/fork: clear PFBLOCKTS in copyprocess()

PFBLOCKTS is only set in blktimegetns() when current->plug is non-NULL, and blkfinishplug() clears it via blkflushplug() before NULLing the plug pointer. copyprocess() breaks the invariant by inheriting PFBLOCKTS from the parent while resetting the child's plug to NULL.

Clear PFBLOCKTS alongside that assignment so callers can rely on "PFBLOCKTS set implies current->plug != NULL" and dereference current->plug unguarded.

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

wifi: mac80211: consume only present negotiated TTLM maps

ieee80211tidtolinkmapsizeok() validates negotiated TTLM elements against the number of link-map entries indicated by linkmappresence. ieee80211parsenegttlm() must consume the same layout.

The parser advanced its cursor for every TID, including TIDs whose presence bit is clear and therefore have no map bytes in the element. A sparse map can then make a later present TID read past the validated element.

The bad bytes land in negttlm->{up,down}link[tid] but are gated by validlinks before being applied to driver state, so a peer cannot turn the read into a policy change. Under KUnit + KASAN with an exact-sized element allocation the OOB read is reported as a slab-out-of-bounds; whether the same trigger fires under the production RX path depends on surrounding allocator state.

Advance the cursor only when the current TID has a map present.

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

x86/ftrace: Relocate %rip-relative percpu refs in dynamic trampolines

With CONFIGCALLDEPTHTRACKING enabled on an x86 retbleed-affected platform (eg: Skylake), with retbleed=stuff, registering a dynamic ftrace trampoline crashes on the first call into the traced function:

BUG: unable to handle page fault for address: ffff88817ae18880 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 4b53067 P4D 4b53067 PUD 0 Oops: Oops: 0002 [#1] SMP PTI CPU: 3 UID: 0 PID: 187 Comm: usleep Not tainted 7.0.10 #243 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 Code: 24 78 00 00 00 00 48 89 ea 48 89 54 24 20 48 8b b4 24 b8 00 00 00 48 8b bc 24 b0 00 00 00 48 89 bc 24 80 00 00 00 48 83 ef 05 <65> 48 c1 3d 1f a8 b6 02 05 48 8b 15 f6 00 00 00 4c 89 3c 24 4c 89 Call Trace: <TASK> ? findheldlock ? excpagefault ? lockrelease ? x64sysclocknanosleep ? lockdephardirqsonprepare ? tracehardirqson x64sysclocknanosleep dosyscall64 ? excpagefault ? calldepthreturnthunk entrySYSCALL64afterhwframe ... Kernel panic - not syncing: Fatal exception

This small reproducer allows to easily trigger the crash:

# echo 'p x64sysclocknanosleep' > /sys/kernel/tracing/kprobeevents # echo 1 > /sys/kernel/tracing/events/kprobes/px64sysclocknanosleep0/enable # usleep 1

Monitoring the crash under GDB points to the exact instruction in charge of incrementing the call depth:

sarq $5, %gs:x86calldepth(%rip)

This instruction matches the one inserted by the ftraceregscaller from ftrace64.S. This emitted code was likely working fine until the introduction of

59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PERCPUVAR()"):

it has made the call depth accounting addressing relative to $rip, instead of being based on an absolute address.

As this code exact location depends on where the trampoline lives in memory, the corresponding displacement needs to be adjusted at runtime to actually correctly find the per-cpu x86calldepth value, otherwise the targeted address is wrong, leading to the page fault seen above.

Fix the %rip-relative displacement of the copied CALLDEPTHACCOUNT instruction (from ftraceregscaller) by calling textpokeapplyrelocation(), as it is done for example by the x86 BPF JIT compiler through x86calldepthemitaccounting(). This corrects both CALLDEPTHACCOUNT slots, in ftracecaller and ftraceregscaller.

[ bp: Massage. ]

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

ksmbd: fix null pointer dereference in compareguidkey()

sessionfdcheck() walks the per-inode moplist during durable-handle session teardown and sets op->conn = NULL for every opinfo whose conn matched the closing session's connection. The matching opinfo, however, stays linked in its per-ClientGuid leasetablelist entry's lb->leaselist because destroyleasetable() only runs on full TCP-connection teardown, not on SESSIONLOGOFF.

If the same TCP connection then negotiates a fresh session with the same ClientGuid (ClientGuid is bound to NEGOTIATE, not the session, and is unchanged across LOGOFF + SETUP) and issues a SMB2 CREATE with a lease context on a different inode, findsameleasekey() walks lb->leaselist, reaches the stale opinfo, and calls compareguidkey(), which unconditionally dereferences opinfo->conn->ClientGUID. The conn pointer is NULL and the kernel panics.

Reproducer requires only a successful SMB2 SESSIONSETUP and a share configured with 'durable handles = yes'. KASAN report on mainline 70390501d194:

general protection fault, probably for non-canonical address 0xdffffc0000000069: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000348-0x000000000000034f] Workqueue: ksmbd-io handleksmbdwork RIP: 0010:bcmp+0x5b/0x230 Call Trace: compareguidkey+0x4b/0xd0 findsameleasekey+0x324/0x690 smb2open+0x6aea/0x8e60 handleksmbdwork+0x796/0xee0 ...

Faulting address 0x348 is the offset of ClientGUID within struct ksmbdconn, confirming opinfo->conn was NULL.

Read opinfo->conn once and bail out if it has been cleared by a concurrent sessionfdcheck(). A half-detached opinfo cannot be the owner of an active lease, so returning 0 is the correct match result.

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

fuse: clear intrentry in fuseresend and fuseremovependingreq

When fuseresend() moves a request from fpq->processing back to fiq->pending, it sets FRPENDING and clears FRSENT but does not remove the requests intrentry from fiq->interrupts. If the request had FRINTERRUPTED set from a prior signal, intrentry remains dangling on fiq->interrupts. When the requesting task then receives a fatal signal, fuseremovependingreq() sees FRPENDING=1, removes the request from fiq->pending and frees it via the refcount path, also without cleaning intrentry. The stale intrentry causes use-after-free when fusereadinterrupt() iterates fiq->interrupts: - listdelinit(&req->intrentry) -> UAF write on freed slab - req->in.h.unique -> UAF read, data leaked to userspace

Remove intrentry from fiq->interrupts in fuseresend() for interrupted requests before they are placed back on fiq->pending.

Add a WARNON if the intrentry is not empty on request destruction.

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

drm/amdgpu/vcn: set nouserfence for VCN v5.0.0 enc ring

VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences.

(cherry picked from commit 49b1fbbb5a071197ee71e2d70959b1cb29bdc317)

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

drm/amdgpu/jpeg: set nouserfence for JPEG v5.0.0 ring

JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences.

(cherry picked from commit 0f43893d3cd478fa57836697525b338817c9c23d)