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

net: liquidio: Initialize netdev pointer before queue setup

In setupnicdevices(), the netdev is allocated using allocetherdevmq(). However, the pointer to this structure is stored in oct->props[i].netdev only after the calls to netifsetrealnumrxqueues() and netifsetrealnumtxqueues().

If either of these functions fails, setupnicdevices() returns an error without freeing the allocated netdev. Since oct->props[i].netdev is still NULL at this point, the cleanup function liquidiodestroynicdevice() will fail to find and free the netdev, resulting in a memory leak.

Fix this by initializing oct->props[i].netdev before calling the queue setup functions. This ensures that the netdev is properly accessible for cleanup in case of errors.

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

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

gpio: loongson-64bit: Fix incorrect NULL check after devmkcalloc()

Fix incorrect NULL check in loongsongpioinitirqchip(). The function checks chip->parent instead of chip->irq.parents.

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

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

During Mode 1 reset, the ASIC undergoes a reset cycle and becomes temporarily inaccessible via PCIe. Any attempt to access MMIO registers during this window (e.g., from interrupt handlers or other driver threads) can result in uncompleted PCIe transactions, leading to NMI panics or system hangs.

To prevent this, set the nohwaccess flag to true immediately after triggering the reset. This signals other driver components to skip register accesses while the device is offline.

A memory barrier smpmb() is added to ensure the flag update is globally visible to all cores before the driver enters the sleep/wait state.

(cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)

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.

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

pmdomain: imx8m-blk-ctrl: fix out-of-range access of bc->domains

Fix out-of-range access of bc->domains in imx8mblkctrlremove().

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:

octeonep: Fix memory leak in octepdevicesetup()

In octepdevicesetup(), if octepctrlnetinit() fails, the function returns directly without unmapping the mapped resources and freeing the allocated configuration memory.

Fix this by jumping to the unsupporteddev label, which performs the necessary cleanup. This aligns with the error handling logic of other paths in this function.

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

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

mm/damon/sysfs: cleanup attrs subdirs on context dir setup failure

When a context DAMON sysfs directory setup is failed after setup of attrs/ directory, subdirectories of attrs/ directory are not cleaned up. As a result, DAMON sysfs interface is nearly broken until the system reboots, and the memory for the unremoved directory is leaked.

Cleanup the directories under such failures.

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

l2tp: avoid one data-race in l2tptunneldelwork()

We should read sk->sksocket only when dealing with kernel sockets.

syzbot reported the following data-race:

BUG: KCSAN: data-race in l2tptunneldelwork / skcommonrelease

write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sksetsocket include/net/sock.h:2092 [inline] sockorphan include/net/sock.h:2118 [inline] skcommonrelease+0xae/0x230 net/core/sock.c:4003 udplibclose+0x15/0x20 include/net/udp.h:325 inetrelease+0xce/0xf0 net/ipv4/afinet.c:437 sockrelease net/socket.c:662 [inline] sockclose+0x6b/0x150 net/socket.c:1455 fput+0x29b/0x650 fs/filetable.c:468 fput+0x1c/0x30 fs/filetable.c:496 taskworkrun+0x131/0x1a0 kernel/taskwork.c:233 resumeusermodework include/linux/resumeusermode.h:50 [inline] exittousermodeloop kernel/entry/common.c:44 [inline] exittousermodeloop+0x1fe/0x740 kernel/entry/common.c:75 exittousermodeprepare include/linux/irq-entry-common.h:226 [inline] syscallexittousermodeprepare include/linux/irq-entry-common.h:256 [inline] syscallexittousermodework include/linux/entry-common.h:159 [inline] syscallexittousermode include/linux/entry-common.h:194 [inline] dosyscall64+0x1e1/0x2b0 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f

read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tptunneldelwork+0x2f/0x1a0 net/l2tp/l2tpcore.c:1418 processonework kernel/workqueue.c:3257 [inline] processscheduledworks+0x4ce/0x9d0 kernel/workqueue.c:3340 workerthread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 retfromfork+0x149/0x290 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246

value changed: 0xffff88811b818000 -> 0x0000000000000000

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

mISDN: annotate data-race around dev->work

dev->work can re read locklessly in mISDNread() and mISDNpoll(). Add READONCE()/WRITEONCE() annotations.

BUG: KCSAN: data-race in mISDNioctl / mISDNread

write to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1: misdnaddtimer drivers/isdn/mISDN/timerdev.c:175 [inline] mISDNioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:597 [inline] sesysioctl+0xce/0x140 fs/ioctl.c:583 x64sysioctl+0x43/0x50 fs/ioctl.c:583 x64syscall+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls64.h:17 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xd8/0x2c0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

read to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0: mISDNread+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112 doloopreadvwritev fs/readwrite.c:847 [inline] vfsreadv+0x3fb/0x690 fs/readwrite.c:1020 doreadv+0xe7/0x210 fs/readwrite.c:1080 dosysreadv fs/readwrite.c:1165 [inline] sesysreadv fs/readwrite.c:1162 [inline] x64sysreadv+0x45/0x50 fs/readwrite.c:1162 x64syscall+0x2831/0x3000 arch/x86/include/generated/asm/syscalls64.h:20 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xd8/0x2c0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

value changed: 0x00000000 -> 0x00000001

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

iio: dac: ad3552r-hs: fix out-of-bound write in ad3552rhswritedatasource

When simplewritetobuffer() succeeds, it returns the number of bytes actually copied to the buffer. The code incorrectly uses 'count' as the index for null termination instead of the actual bytes copied. If count exceeds the buffer size, this leads to out-of-bounds write. Add a check for the count and use the return value as the index.

The bug was validated using a demo module that mirrors the original code and was tested under QEMU.

Pattern of the bug: - A fixed 64-byte stack buffer is filled using count. - If count > 64, the code still does buf[count] = '\0', causing an - out-of-bounds write on the stack.

Steps for reproduce: - Opens the device node. - Writes 128 bytes of A to it. - This overflows the 64-byte stack buffer and KASAN reports the OOB.

Found via static analysis. This is similar to the commit da9374819eb3 ("iio: backend: fix out-of-bound write")

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

ALSA: usb-audio: Fix use-after-free in sndusbmixerfree()

When sndusbcreatemixer() fails, sndusbmixerfree() frees mixer->idelems but the controls already added to the card still reference the freed memory. Later when sndcardregister() runs, the OSS mixer layer calls their callbacks and hits a use-after-free read.

Call trace: getctlvalue+0x63f/0x820 sound/usb/mixer.c:411 getminmaxwithquirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241 mixerctlfeatureinfo+0x26b/0x490 sound/usb/mixer.c:1381 sndmixerossbuildtest+0x174/0x3a0 sound/core/oss/mixeross.c:887 ... sndcardregister+0x4ed/0x6d0 sound/core/init.c:923 usbaudioprobe+0x5ef/0x2a90 sound/usb/card.c:1025

Fix by calling sndctlremove() for all mixer controls before freeing idelems. We save the next pointer first because sndctlremove() frees the current element.

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

iommu/io-pgtable-arm: fix sizet signedness bug in unmap path

armlpaeunmap() returns sizet but was returning -ENOENT (negative error code) when encountering an unmapped PTE. Since sizet is unsigned, -ENOENT (typically -2) becomes a huge positive value (0xFFFFFFFFFFFFFFFE on 64-bit systems).

This corrupted value propagates through the call chain: armlpaeunmap() returns -ENOENT as sizet -> armlpaeunmappages() returns it -> iommuunmap() adds it to iova address -> iommupgsize() triggers BUGON due to corrupted iova

This can cause IOVA address overflow in iommuunmap() loop and trigger BUGON in iommupgsize() from invalid address alignment.

Fix by returning 0 instead of -ENOENT. The WARNON already signals the error condition, and returning 0 (meaning "nothing unmapped") is the correct semantic for sizet return type. This matches the behavior of other io-pgtable implementations (io-pgtable-arm-v7s, io-pgtable-dart) which return 0 on error conditions.

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

iio: adc: at91-sama5d2adc: Fix potential use-after-free in sama5d2adc driver

at91adcinterrupt can call at91adctouchdatahandler function to start the work by schedulework(&st->touchst.workq).

If we remove the module which will call at91adcremove to make cleanup, it will free indiodev through iiodeviceunregister but quite a bit later. While the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:

CPU0 CPU1

| at91adcworkqhandler at91adcremove | iiodeviceunregister(indiodev) | //free indiodev a bit later | | iiopushtobuffers(indiodev) | //use indiodev

Fix it by ensuring that the work is canceled before proceeding with the cleanup in at91adcremove.

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

LoongArch: KVM: Fix kvmdevice leak in kvmeiointcdestroy()

In kvmioctlcreatedevice(), kvmdevice has allocated memory, kvmdevice->destroy() seems to be supposed to free its kvmdevice struct, but kvmeiointcdestroy() is not currently doing this, that would lead to a memory leak.

So, fix it.

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

LoongArch: KVM: Fix kvmdevice leak in kvmpchpicdestroy()

In kvmioctlcreatedevice(), kvmdevice has allocated memory, kvmdevice->destroy() seems to be supposed to free its kvmdevice struct, but kvmpchpicdestroy() is not currently doing this, that would lead to a memory leak.

So, fix it.

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:

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:

net/mlx5e: Don't store mlx5epriv in mlx5edev devlink priv

mlx5epriv is an unstable structure that can be memset(0) if profile attaching fails, mlx5epriv in mlx5edev devlink private is used to reference the netdev and mdev associated with that struct. Instead, store netdev directly into mlx5edev and get mdev from the containing mlx5adev aux device structure.

This fixes a kernel oops in mlx5eremove when switchdev mode fails due to change profile failure.

$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5core 0012:03:00.1: mlx5enetdevinitprofile:6214:(pid 37199): mlx5eprivinit failed, err=-12 mlx5core 0012:03:00.1 gpu3rdma1: mlx5enetdevchangeprofile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5core 0012:03:00.1: mlx5enetdevinitprofile:6214:(pid 37199): mlx5eprivinit failed, err=-12 mlx5core 0012:03:00.1 gpu3rdma1: mlx5enetdevchangeprofile: failed to rollback to orig profile, -12

$ devlink dev reload pci/0000:00:03.0 ==> oops

BUG: kernel NULL pointer dereference, address: 0000000000000520 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5eremove+0x68/0x130 RSP: 0018:ffffc900034838f0 EFLAGS: 00010246 RAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10 R10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0 R13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400 FS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0 Call Trace: <TASK> devicereleasedriverinternal+0x19c/0x200 busremovedevice+0xc6/0x130 devicedel+0x160/0x3d0 ? devlparamdriverinitvalueget+0x2d/0x90 mlx5detachdevice+0x89/0xe0 mlx5unloadonedevllocked+0x3a/0x70 mlx5devlinkreloaddown+0xc8/0x220 devlinkreload+0x7d/0x260 devlinknlreloaddoit+0x45b/0x5a0 genlfamilyrcvmsgdoit+0xe8/0x140

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:

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]'

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.

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

net: usb: asix: validate PHY address before use

The ASIX driver reads the PHY address from the USB device via asixreadphyaddr(). A malicious or faulty device can return an invalid address (>= PHYMAXADDR), which causes a warning in mdiobusgetphy():

addr 207 out of range WARNING: drivers/net/phy/mdiobus.c:76

Validate the PHY address in asixreadphyaddr() and remove the now-redundant check in ax88172a.c.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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

KVM: Disallow toggling KVMMEMGUESTMEMFD on an existing memslot

Reject attempts to disable KVMMEMGUESTMEMFD on a memslot that was initially created with a guestmemfd binding, as KVM doesn't support toggling KVMMEMGUESTMEMFD on existing memslots. KVM prevents enabling KVMMEMGUESTMEMFD, but doesn't prevent clearing the flag.

Failure to reject the new memslot results in a use-after-free due to KVM not unbinding from the guestmemfd instance. Unbinding on a FLAGSONLY change is easy enough, and can/will be done as a hardening measure (in anticipation of KVM supporting dirty logging on guestmemfd at some point), but fixing the use-after-free would only address the immediate symptom.

================================================================== BUG: KASAN: slab-use-after-free in kvmgmemrelease+0x362/0x400 [kvm] Write of size 8 at addr ffff8881111ae908 by task repro/745

CPU: 7 UID: 1000 PID: 745 Comm: repro Not tainted 6.18.0-rc6-115d5de2eef3-next-kasan #3 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dumpstacklvl+0x51/0x60 printreport+0xcb/0x5c0 kasanreport+0xb4/0xe0 kvmgmemrelease+0x362/0x400 [kvm] fput+0x2fa/0x9d0 taskworkrun+0x12c/0x200 doexit+0x6ae/0x2100 dogroupexit+0xa8/0x230 x64sysexitgroup+0x3a/0x50 x64syscall+0x737/0x740 dosyscall64+0x5b/0x900 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7f581f2eac31 </TASK>

Allocated by task 745 on cpu 6 at 9.746971s: kasansavestack+0x20/0x40 kasansavetrack+0x13/0x50 kasankmalloc+0x77/0x90 kvmsetmemoryregion.part.0+0x652/0x1110 [kvm] kvmvmioctl+0x14b0/0x3290 [kvm] x64sysioctl+0x129/0x1a0 dosyscall64+0x5b/0x900 entrySYSCALL64afterhwframe+0x4b/0x53

Freed by task 745 on cpu 6 at 9.747467s: kasansavestack+0x20/0x40 kasansavetrack+0x13/0x50 kasansavefreeinfo+0x37/0x50 kasanslabfree+0x3b/0x60 kfree+0xf5/0x440 kvmsetmemslot+0x3c2/0x1160 [kvm] kvmsetmemoryregion.part.0+0x86a/0x1110 [kvm] kvmvmioctl+0x14b0/0x3290 [kvm] x64sysioctl+0x129/0x1a0 dosyscall64+0x5b/0x900 entrySYSCALL64afterhwframe+0x4b/0x53

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

net/mlx5: Fix double unregister of HCAPORTS component

Clear hcadevcomcomp in device's private data after unregistering it in LAG teardown. Otherwise a slightly lagging second pass through mlx5unloadone() might try to unregister it again and trip over use-after-free.

On s390 almost all PCI level recovery events trigger two passes through mxl5unloadone() - one through the pollhealth() method and one through mlx5pcierrdetected() as callback from generic PCI error recovery. While testing PCI error recovery paths with more kernel debug features enabled, this issue reproducibly led to kernel panics with the following call chain:

Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 6b6b6b6b6b6b6000 TEID: 6b6b6b6b6b6b6803 ESOP-2 FSI Fault in home space mode while using kernel ASCE. AS:00000000705c4007 R3:0000000000000024 Oops: 0038 ilc:3 [#1]SMP

CPU: 14 UID: 0 PID: 156 Comm: kmcheck Kdump: loaded Not tainted 6.18.0-20251130.rc7.git0.16131a59cab1.300.fc43.s390x+debug #1 PREEMPT

Krnl PSW : 0404e00180000000 0000020fc86aa1dc (lockacquire+0x5c/0x15f0) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000000 0000020f00000001 6b6b6b6b6b6b6c33 0000000000000000 0000000000000000 0000000000000000 0000000000000001 0000000000000000 0000000000000000 0000020fca28b820 0000000000000000 0000010a1ced8100 0000010a1ced8100 0000020fc9775068 0000018fce14f8b8 0000018fce14f7f8 Krnl Code: 0000020fc86aa1cc: e3b003400004 lg %r11,832 0000020fc86aa1d2: a7840211 brc 8,0000020fc86aa5f4 0000020fc86aa1d6: c09000df0b25 larl %r9,0000020fca28b820 >0000020fc86aa1dc: d50790002000 clc 0(8,%r9),0(%r2) 0000020fc86aa1e2: a7840209 brc 8,0000020fc86aa5f4 0000020fc86aa1e6: c0e001100401 larl %r14,0000020fca8aa9e8 0000020fc86aa1ec: c01000e25a00 larl %r1,0000020fca2f55ec 0000020fc86aa1f2: a7eb00e8 aghi %r14,232

Call Trace: lockacquire+0x5c/0x15f0 lockacquire.part.0+0xf8/0x270 lockacquire+0xb0/0x1b0 downwrite+0x5a/0x250 mlx5detachdevice+0x42/0x110 [mlx5core] mlx5unloadonedevllocked+0x50/0xc0 [mlx5core] mlx5unloadone+0x42/0x60 [mlx5core] mlx5pcierrdetected+0x94/0x150 [mlx5core] zpcieventattempterrorrecovery+0xcc/0x388

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/handshake: duplicate handshake cancellations leak socket

When a handshake request is cancelled it is removed from the handshakenet->hnrequests list, but it is still present in the handshakerhashtbl until it is destroyed.

If a second cancellation request arrives for the same handshake request, then removepending() will return false... and assuming HANDSHAKEFREQCOMPLETED isn't set in req->hrflags, we'll continue processing through the outtrue label, where we put another reference on the sock and a refcount underflow occurs.

This can happen for example if a handshake times out - particularly if the SUNRPC client sends the AUTHTLS probe to the server but doesn't follow it up with the ClientHello due to a problem with tlshd. When the timeout is hit on the server, the server will send a FIN, which triggers a cancellation request via xsresettransport(). When the timeout is hit on the client, another cancellation request happens via xstlshandshakesync().

Add a testandsetbit(HANDSHAKEFREQCOMPLETED) in the pending cancel path so duplicate cancels can be detected.

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

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