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

nvme-multipath: fix lockdep WARN due to partition scan work

Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->openmutex, kblockd workqueue completion and partitionscanwork completion.

To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partitionscanwork not by kblockd workqueue but by nvmewq.

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

ASoC: Intel: avs: Disable periods-elapsed work when closing PCM

avsdaifeshutdown() handles the shutdown procedure for HOST HDAudio stream while period-elapsed work services its IRQs. As the former frees the DAI's private context, these two operations shall be synchronized to avoid slab-use-after-free or worse errors.

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

drm/radeon: Remove calls to drmputdev()

Since the allocation of the drivers main structure was changed to devmdrmdevalloc() drmputdev()'ing to trigger it to be free'd should be done by devres.

However, drmputdev() is still in the probe error and device remove paths. When the driver fails to probe warnings like the following are shown because devres is trying to drmputdev() after the driver already did it.

[ 5.642230] radeon 0000:01:05.0: probe with driver radeon failed with error -22 [ 5.649605] ------------[ cut here ]------------ [ 5.649607] refcountt: underflow; use-after-free. [ 5.649620] WARNING: CPU: 0 PID: 357 at lib/refcount.c:28 refcountwarnsaturate+0xbe/0x110

(cherry picked from commit 3eb8c0b4c091da0a623ade0d3ee7aa4a93df1ea4)

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

virtio-net: fix received length check in big packets

Since commit 4959aebba8c0 ("virtio-net: use mtu size as buffer length for big packets"), when guest gso is off, the allocated size for big packets is not MAXSKBFRAGS PAGESIZE anymore but depends on negotiated MTU. The number of allocated frags for big packets is stored in vi->bigpacketsnumskbfrags.

Because the host announced buffer length can be malicious (e.g. the host vhostnet driver's getrxbufs is modified to announce incorrect length), we need a check in virtionet receive path. Currently, the check is not adapted to the new change which can lead to NULL page pointer dereference in the below while loop when receiving length that is larger than the allocated one.

This commit fixes the received length check corresponding to the new change.

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

libceph: return the handler error from monhandleauthdone()

Currently any error from cephauthhandlereplydone() is propagated via finishauth() but isn't returned from monhandleauthdone(). This results in higher layers learning that (despite the monitor considering us to be successfully authenticated) something went wrong in the authentication phase and reacting accordingly, but msgr2 still trying to proceed with establishing the session in the background. In the case of secure mode this can trigger a WARN in setupcrypto() and later lead to a NULL pointer dereference inside of prepareauthsignature().

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

dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation

Make sure to drop the reference taken when looking up the crossbar platform device during am335x route allocation.

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

ipv4: Fix reference count leak when using error routes with nexthop objects

When a nexthop object is deleted, it is marked as dead and then fibtableflush() is called to flush all the routes that are using the dead nexthop.

The current logic in fibtableflush() is to only flush error routes (e.g., blackhole) when it is called as part of network namespace dismantle (i.e., with flushall=true). Therefore, error routes are not flushed when their nexthop object is deleted:

# ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show blackhole 198.51.100.2 nhid 1 dev dummy1

As such, they keep holding a reference on the nexthop object which in turn holds a reference on the nexthop device, resulting in a reference count leak:

# ip link del dev dummy1 [ 70.516258] unregisternetdevice: waiting for dummy1 to become free. Usage count = 2

Fix by flushing error routes when their nexthop is marked as dead.

IPv6 does not suffer from this problem.

binfmtmisc: restore write access before closing files opened by openexec()

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

wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode

Currently, whenever there is a need to transmit an Action frame, the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR to firmware. The P2P interfaces were available when wpasupplicant is managing the wlan interface.

However, the P2P interfaces are not created/initialized when only hostapd is managing the wlan interface. And if hostapd receives an ANQP Query REQ Action frame even from an un-associated STA, the brcmfmac driver tries to use an uninitialized P2P vif pointer for sending the IOVAR to firmware. This NULL pointer dereferencing triggers a driver crash.

[ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmfp2psendactionframe+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmfcfg80211mgmttx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211mlmemgmttx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211txmgmt+0x238/0x388 [cfg80211] [ 1417.076281] genlfamilyrcvmsgdoit+0xe0/0x158 [ 1417.076302] genlrcvmsg+0x220/0x2a0 [ 1417.076317] netlinkrcvskb+0x68/0x140 [ 1417.076330] genlrcv+0x40/0x60 [ 1417.076343] netlinkunicast+0x330/0x3b8 [ 1417.076357] netlinksendmsg+0x19c/0x3f8 [ 1417.076370] socksendmsg+0x64/0xc0 [ 1417.076391] syssendmsg+0x268/0x2a0 [ 1417.076408] syssendmsg+0xb8/0x118 [ 1417.076427] syssendmsg+0x90/0xf8 [ 1417.076445] arm64syssendmsg+0x2c/0x40 [ 1417.076465] invokesyscall+0x50/0x120 [ 1417.076486] el0svccommon.constprop.0+0x48/0xf0 [ 1417.076506] doel0svc+0x24/0x38 [ 1417.076525] el0svc+0x30/0x100 [ 1417.076548] el0t64synchandler+0x100/0x130 [ 1417.076569] el0t64sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000)

Fix this, by always using the vif corresponding to the wdev on which the Action frame Transmission request was initiated by the userspace. This way, even if P2P vif is not available, the IOVAR is sent to firmware on AP vif and the ANQP Query RESP Action frame is transmitted without crashing the driver.

Move initcompletion() for "sendafdone" from brcmfp2pcreatep2pdev() to brcmfp2pattach(). Because the former function would not get executed when only hostapd is managing wlan interface, and it is not safe to do reinitcompletion() later in brcmfp2ptxactionframe(), without any prior initcompletion().

And in the brcmfp2ptxactionframe() function, the condition check for P2P Presence response frame is not needed, since the wpasupplicant is properly sending the P2P Presense Response frame on the P2P-GO vif instead of the P2P-Device vif.

[Cc stable]

accel/habanalabs: support mapping cb with vmalloc-backed coherent memory

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

ASoC: Intel: avs: Do not share the name pointer between components

By sharing 'name' directly, tearing down components may lead to use-after-free errors. Duplicate the name to avoid that.

At the same time, update the order of operations - since commit cee28113db17 ("ASoC: dmaenginepcm: Allow passing component name via config") the framework does not override component->name if set before invoking the initializer.

ALSA: firewire-motu: add bounds check in putuser loop for DSP events

block: Use RCU in blkmq[un]quiescetagset() instead of set->taglistlock

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

PCI/AER: Fix NULL pointer access by aerinfo

The kzalloc(GFPKERNEL) may return NULL, so all accesses to aerinfo->xxx will result in kernel panic. Fix it.

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

blk-cgroup: fix possible deadlock while configuring policy

Following deadlock can be triggered easily by lockdep:

WARNING: possible circular locking dependency detected 6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted ------------------------------------------------------ check/1334 is trying to acquire lock: ff1100011d9d0678 (&q->sysfslock){+.+.}-{4:4}, at: blkunregisterqueue+0x53/0x180

but task is already holding lock: ff1100011d9d00e0 (&q->qusagecounter(queue)#3){++++}-{0:0}, at: delgendisk+0xba/0x110

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&q->qusagecounter(queue)#3){++++}-{0:0}: blkqueueenter+0x40b/0x470 blkgconfprep+0x7b/0x3c0 tgsetlimit+0x10a/0x3e0 cgroupfilewrite+0xc6/0x420 kernfsfopwriteiter+0x189/0x280 vfswrite+0x256/0x490 ksyswrite+0x83/0x190 x64syswrite+0x21/0x30 x64syscall+0x4608/0x4630 dosyscall64+0xdb/0x6b0 entrySYSCALL64afterhwframe+0x76/0x7e

-> #1 (&q->rqqosmutex){+.+.}-{4:4}: mutexlock+0xd8/0xf50 mutexlocknested+0x2b/0x40 wbtinit+0x17e/0x280 wbtenabledefault+0xe9/0x140 blkregisterqueue+0x1da/0x2e0 adddisk+0x38c/0x5d0 adddiskfwnode+0x89/0x250 deviceadddisk+0x18/0x30 virtblkprobe+0x13a3/0x1800 virtiodevprobe+0x389/0x610 reallyprobe+0x136/0x620 driverprobedevice+0xb3/0x230 driverprobedevice+0x2f/0xe0 driverattach+0x158/0x250 busforeachdev+0xa9/0x130 driverattach+0x26/0x40 busadddriver+0x178/0x3d0 driverregister+0x7d/0x1c0 registervirtiodriver+0x2c/0x60 virtioblkinit+0x6f/0xe0 dooneinitcall+0x94/0x540 kernelinitfreeable+0x56a/0x7b0 kernelinit+0x2b/0x270 retfromfork+0x268/0x4c0 retfromforkasm+0x1a/0x30

-> #0 (&q->sysfslock){+.+.}-{4:4}: lockacquire+0x1835/0x2940 lockacquire+0xf9/0x450 mutexlock+0xd8/0xf50 mutexlocknested+0x2b/0x40 blkunregisterqueue+0x53/0x180 delgendisk+0x226/0x690 delgendisk+0xba/0x110 sdremove+0x49/0xb0 [sdmod] deviceremove+0x87/0xb0 devicereleasedriverinternal+0x11e/0x230 devicereleasedriver+0x1a/0x30 busremovedevice+0x14d/0x220 devicedel+0x1e1/0x5a0 scsiremovedevice+0x1ff/0x2f0 scsiremovedevice+0x37/0x60 sdevstoredelete+0x77/0x100 devattrstore+0x1f/0x40 sysfskfwrite+0x65/0x90 kernfsfopwriteiter+0x189/0x280 vfswrite+0x256/0x490 ksyswrite+0x83/0x190 x64syswrite+0x21/0x30 x64syscall+0x4608/0x4630 dosyscall64+0xdb/0x6b0 entrySYSCALL64afterhwframe+0x76/0x7e

other info that might help us debug this:

Chain exists of: &q->sysfslock --> &q->rqqosmutex --> &q->qusagecounter(queue)#3

Possible unsafe locking scenario:

CPU0 CPU1 ---- ---- lock(&q->qusagecounter(queue)#3); lock(&q->rqqosmutex); lock(&q->qusagecounter(queue)#3); lock(&q->sysfslock);

Root cause is that queueusagecounter is grabbed with rqqosmutex held in blkgconfprep(), while queue should be freezed before rqqosmutex from other context.

The blkqueueenter() from blkgconfprep() is used to protect against policy deactivation, which is already protected with blkcgmutex, hence convert blkqueueenter() to blkcgmutex to fix this problem. Meanwhile, consider that blkcgmutex is held after queue is freezed from policy deactivation, also convert blkgalloc() to use GFPNOIO.

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

bpf: Add bpfprogrundatapointers()

syzbot found that clsbpfclassify() is able to change tcskbcb(skb)->dropreason triggering a warning in skskbreasondrop().

WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 skskbreasondrop net/core/skbuff.c:1189 [inline] WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 skskbreasondrop+0x76/0x170 net/core/skbuff.c:1214

struct tcskbcb has been added in commit ec624fe740b4 ("net/sched: Extend qdisc control block with tc control block"), which added a wrong interaction with db58ba459202 ("bpf: wire in data and dataend for clsactbpf").

dropreason was added later.

Add bpfprogrundatapointers() helper to save/restore the netsched storage colliding with BPF datameta/dataend.

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

drm/plane: Fix createinformatblob() return value

createinformatblob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.

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

staging: rtl8723bs: fix out-of-bounds read in rtwgetie() parser

The Information Element (IE) parser rtwgetie() trusted the length byte of each IE without validating that the IE body (len bytes after the 2-byte header) fits inside the remaining frame buffer. A malformed frame can advertise an IE length larger than the available data, causing the parser to increment its pointer beyond the buffer end. This results in out-of-bounds reads or, depending on the pattern, an infinite loop.

Fix by validating that (offset + 2 + len) does not exceed the limit before accepting the IE or advancing to the next element.

This prevents OOB reads and ensures the parser terminates safely on malformed frames.

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

crypto: aead - Fix reqsize handling

Commit afddce13ce81d ("crypto: api - Add reqsize to cryptoalg") introduced crareqsize field in cryptoalg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks.

However, this is being recommended for use in all crypto algs instead of setting reqsize using cryptosetreqsize(). Using crareqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from crareqsize. [1]

Add proper setreqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework.

[1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b

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

perf/x86: Fix NULL event access and potential PEBS record loss

When intelpmudrainpebsicl() is called to drain PEBS records, the perfeventoverflow() could be called to process the last PEBS record.

While perfeventoverflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows.

perfeventoverflow() -> perfeventoverflow() ->perfeventaccountinterrupt() -> perfeventthrottlegroup() -> perfeventthrottle() -> event->pmu->stop() -> x86pmustop()

The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL.

Assume there are two PEBS events (event a and event b) in a group. When intelpmudrainpebsicl() calls perfeventoverflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intelpmudrainpebsicl() tries to process the last PEBS record of event b and encounters NULL pointer access.

To avoid this issue, move cpuc->events[] clearing from x86pmustop() to x86pmudel(). It's safe since cpuc->activemask or cpuc->pebsenabled is always checked before access the event pointer from cpuc->events[].

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

ntfs3: Fix uninit buffer allocated by getname()

Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.

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

isdn: mISDN: hfcsusb: fix memory leak in hfcsusbprobe()

In hfcsusbprobe(), the memory allocated for ctrlurb gets leaked when setupinstance() fails with an error code. Fix that by freeing the urb before freeing the hw structure. Also change the error paths to use the goto ladder style.

Compile tested only. Issue found using a prototype static analysis tool.

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

spi: tegra210-quad: Fix timeout handling

When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached.

While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the currxfer field pointing at stale memory.

To avoid this, clear currxfer to NULL upon timeout and check for this condition when the IRQ thread is finally run.

While at it, also make sure to clear interrupts on failure so that new interrupts can be run.

A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.

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

drm/panthor: Prevent potential UAF in group creation

This commit prevents the possibility of a use after free issue in the GROUPCREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUPDESTROY ioctl from another thread around the same time as GROUPCREATE ioctl.

To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUPCREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet.

v2: Add R-bs and fixes tags

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

spi: tegra210-quad: Protect currxfer check in IRQ handler

Now that all other accesses to currxfer are done under the lock, protect the currxfer NULL check in tegraqspiisrthread() with the spinlock. Without this protection, the following race can occur:

CPU0 (ISR thread) CPU1 (timeout path) ---------------- ------------------- if (!tqspi->currxfer) // sees non-NULL spinlock() tqspi->currxfer = NULL spinunlock() handlexfer() spinlock() t = tqspi->currxfer // NULL! ... t->len ... // NULL dereference!

With this patch, all currxfer accesses are now properly synchronized.

Although all accesses to currxfer are done under the lock, in tegraqspiisrthread() it checks for NULL, releases the lock and reacquires it later in handlecpubasedxfer()/handledmabasedxfer(). There is a potential for an update in between, which could cause a NULL pointer dereference.

To handle this, add a NULL check inside the handlers after acquiring the lock. This ensures that if the timeout path has already cleared currxfer, the handler will safely return without dereferencing the NULL pointer.

drm/amd/pm: Disable MMIO access during SMU Mode 1 reset

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

usb: phy: fsl-usb: Fix use-after-free in delayed work during device removal

The delayed work item otgevent is initialized in fslotgconf() and scheduled under two conditions: 1. When a host controller binds to the OTG controller. 2. When the USB ID pin state changes (cable insertion/removal).

A race condition occurs when the device is removed via fslotgremove(): the fslotg instance may be freed while the delayed work is still pending or executing. This leads to use-after-free when the work function fslotgevent() accesses the already freed memory.

The problematic scenario:

(detach thread) | (delayed work) fslotgremove() | kfree(fslotgdev) //FREE| fslotgevent() | og = containerof(...) //USE | og-> //USE

Fix this by calling disabledelayedworksync() in fslotgremove() before deallocating the fslotg structure. This ensures the delayed work is properly canceled and completes execution prior to memory deallocation.

This bug was identified through static analysis.

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

net: cpsw: Execute ndosetrxmode callback in a work queue

Commit 1767bb2d47b7 ("ipv6: mcast: Don't hold RTNL for IPV6ADDMEMBERSHIP and MCASTJOINGROUP.") removed the RTNL lock for IPV6ADDMEMBERSHIP and MCASTJOINGROUP operations. However, this change triggered the following call trace on my BeagleBone Black board: WARNING: net/8021q/vlancore.c:236 at vlanforeach+0x120/0x124, CPU#0: rpcbind/481 RTNL: assertion failed at net/8021q/vlancore.c (236) Modules linked in: CPU: 0 UID: 997 PID: 481 Comm: rpcbind Not tainted 6.19.0-rc7-next-20260130-yocto-standard+ #35 PREEMPT Hardware name: Generic AM33XX (Flattened Device Tree) Call trace: unwindbacktrace from showstack+0x28/0x2c showstack from dumpstacklvl+0x30/0x38 dumpstacklvl from warn+0xb8/0x11c warn from warnslowpathfmt+0x130/0x194 warnslowpathfmt from vlanforeach+0x120/0x124 vlanforeach from cpswaddmcaddr+0x54/0x98 cpswaddmcaddr from hwaddrrefsyncdev+0xc4/0xec hwaddrrefsyncdev from devmcadd+0x78/0x88 devmcadd from igmp6groupadded+0x84/0xec igmp6groupadded from ipv6devmcinc+0x1fc/0x2f0 ipv6devmcinc from ipv6sockmcjoin+0x124/0x1b4 ipv6sockmcjoin from doipv6setsockopt+0x84c/0x1168 doipv6setsockopt from ipv6setsockopt+0x88/0xc8 ipv6setsockopt from dosocksetsockopt+0xe8/0x19c dosocksetsockopt from syssetsockopt+0x84/0xac syssetsockopt from retfastsyscall+0x0/0x54

This trace occurs because vlanforeach() is called within cpswndosetrxmode(), which expects the RTNL lock to be held. Since modifying vlanforeach() to operate without the RTNL lock is not straightforward, and because ndosetrxmode() is invoked both with and without the RTNL lock across different code paths, simply adding rtnllock() in cpswndosetrxmode() is not a viable solution.

To resolve this issue, we opt to execute the actual processing within a work queue, following the approach used by the icssg-prueth driver.

Please note: To reproduce this issue, I manually reverted the changes to am335x-bone-common.dtsi from commit c477358e66a3 ("ARM: dts: am335x-bone: switch to new cpsw switch drv") in order to revert to the legacy cpsw driver.

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

net: octeonepvf: fix freeirq devid mismatch in IRQ rollback

octepvfrequestirqs() requests MSI-X queue IRQs with devid set to ioqvector. If requestirq() fails part-way, the rollback loop calls freeirq() with devid set to 'oct', which does not match the original devid and may leave the irqaction registered.

This can keep IRQ handlers alive while ioqvector is later freed during unwind/teardown, leading to a use-after-free or crash when an interrupt fires.

Fix the error path to free IRQs with the same ioqvector devid used during requestirq().

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

wifi: rtlwifi: 8192cu: fix tid out of range in rtl92cutxfilldesc()

TID getting from ieee80211gettid() might be out of range of array size of staentry->tids[], so check TID is less than MAXTIDCOUNT. Othwerwise, UBSAN warn:

UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:514:30 index 10 is out of range for type 'rtltiddata [9]'