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

drm: Account property blob allocations to memcg

DRMIOCTLMODECREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory.

Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM.

Mark the property blob data allocation with GFPKERNELACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits.

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

xfrm: account XFRMAIFID in aevent size calculation

xfrmgetae() allocates the reply skb with xfrmaeventmsgsize(), then buildaevent() appends attributes including XFRMAIFID when x->ifid is set.

xfrmaeventmsgsize() does not include space for XFRMAIFID. For states with ifid, buildaevent() can fail with -EMSGSIZE and hit BUGON(err < 0) in xfrmgetae(), turning a malformed netlink interaction into a kernel panic.

Account XFRMAIFID in the size calculation unconditionally and replace the BUGON with normal error unwinding.

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

wifi: brcmfmac: validate bsscfg indices in IF events

brcmffwehhandleifevent() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check.

Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array.

[add missing wifi prefix]

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

fs/smb/client: fix out-of-bounds read in cifssanitizeprepath

When cifssanitizeprepath is called with an empty string or a string containing only delimiters (e.g., "/"), the current logic attempts to check (cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read.

This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL.

The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.

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

ipv6: ioam: fix potential NULL dereferences in ioam6filltracedata()

We need to check in6devget() for possible NULL value, as suggested by Yiming Qian.

Also add skbdstdevrcu() instead of skbdstdev(), and two missing READONCE().

Note that @dev can't be NULL.

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

wifi: wl1251: validate packet IDs before indexing txframes

wl1251txpacketcb() uses the firmware completion ID directly to index the fixed 16-entry wl->txframes[] array. The ID is a raw u8 from the completion block, and the callback does not currently verify that it fits the array before dereferencing it.

Reject completion IDs that fall outside wl->txframes[] and keep the existing NULL check in the same guard. This keeps the fix local to the trust boundary and avoids touching the rest of the completion flow.

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

net: qrtr: replace qrtrtxflow radixtree with xarray to fix memory leak

radixtreecreate() allocates and links intermediate nodes into the tree one by one. If a subsequent allocation fails, the already-linked nodes remain in the tree with no corresponding leaf entry. These orphaned internal nodes are never reclaimed because radixtreeforeachslot() only visits slots containing leaf values.

The radixtree API is deprecated in favor of xarray. As suggested by Matthew Wilcox, migrate qrtrtxflow from radixtree to xarray instead of fixing the radixtree itself [1]. xarray properly handles cleanup of internal nodes — xadestroy() frees all internal xarray nodes when the qrtrnode is released, preventing the leak.

[1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/

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

usb: gadget: ftcm: Fix NULL pointer dereferences in nexus handling

The tpg->tpgnexus pointer in the USB Target driver is dynamically managed and tied to userspace configuration via ConfigFS. It can be NULL if the USB host sends requests before the nexus is fully established or immediately after it is dropped.

Currently, functions like botsubmitcommand() and the data transfer paths retrieve tvnexus = tpg->tpgnexus and immediately dereference tvnexus->tvnsesess without any validation. If a malicious or misconfigured USB host sends a BOT (Bulk-Only Transport) command during this race window, it triggers a NULL pointer dereference, leading to a kernel panic (local DoS).

This exposes an inconsistent API usage within the module, as peer functions like usbgsubmitcommand() and botsendbadresponse() correctly implement a NULL check for tvnexus before proceeding.

Fix this by bringing consistency to the nexus handling. Add the missing if (!tvnexus) checks to the vulnerable BOT command and request processing paths, aborting the command gracefully with an error instead of crashing the system.

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

USB: dummy-hcd: Fix locking/synchronization error

Syzbot testing was able to provoke an addressing exception and crash in the usbgadgetudcreset() routine in drivers/usb/gadgets/udc/core.c, resulting from the fact that the routine was called with a second ("driver") argument of NULL. The bad caller was setlinkstate() in dummyhcd.c, and the problem arose because of a race between a USB reset and driver unbind.

These sorts of races were not supposed to be possible; commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"), along with a few followup commits, was written specifically to prevent them. As it turns out, there are (at least) two errors remaining in the code. Another patch will address the second error; this one is concerned with the first.

The error responsible for the syzbot crash occurred because the stopactivity() routine will sometimes drop and then re-acquire the dum->lock spinlock. A call to stopactivity() occurs in setlinkstate() when handling an emulated USB reset, after the test of dum->intsenabled and before the increment of dum->callbackusage. This allowed another thread (doing a driver unbind) to sneak in and grab the spinlock, and then clear dum->intsenabled and dum->driver. Normally this other thread would have to wait for dum->callbackusage to go down to 0 before it would clear dum->driver, but in this case it didn't have to wait since dum->callbackusage had not yet been incremented.

The fix is to increment dum->callbackusage before calling stopactivity() instead of after. Then the thread doing the unbind will not clear dum->driver until after the call to usbgadgetudcreset() safely returns and dum->callbackusage has been decremented again.

drm/amdgpu: fix sync handling in amdgpudmabufmovenotify

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

USB: dummy-hcd: Fix interrupt synchronization error

This fixes an error in synchronization in the dummy-hcd driver. The error has a somewhat involved history. The synchronization mechanism was introduced by commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"), which added an emulated "interrupts enabled" flag together with code emulating synchronizeirq() (it waits until all current handler callbacks have returned).

But the emulated interrupt-disable occurred too late, after the driver containing the handler callback routines had been told that it was unbound and no more callbacks would occur. Commit 4a5d797a9f9c ("usb: gadget: dummyhcd: fix gpf in gadgetsetup") tried to fix this by moving the synchronizeirq() emulation code from dummystop() to dummypullup(), which runs before the unbind callback.

There still were races, though, because the emulated interrupt-disable still occurred too late. It couldn't be moved to dummypullup(), because that routine can be called for reasons other than an impending unbind. Therefore commits 7dc0c55e9f30 ("USB: UDC core: Add udcasynccallbacks gadget op") and 04145a03db9d ("USB: UDC: Implement udcasynccallbacks in dummy-hcd") added an API allowing the UDC core to tell dummy-hcd exactly when emulated interrupts and their callbacks should be disabled.

That brings us to the current state of things, which is still wrong because the emulated synchronizeirq() occurs before the emulated interrupt-disable! That's no good, beause it means that more emulated interrupts can occur after the synchronizeirq() emulation has run, leading to the possibility that a callback handler may be running when the gadget driver is unbound.

To fix this, we have to move the synchronizeirq() emulation code yet again, to the dummyudcasynccallbacks() routine, which takes care of enabling and disabling emulated interrupt requests. The synchronization will now run immediately after emulated interrupts are disabled, which is where it belongs.

Bluetooth: hcisync: annotate data-races around hdev->reqstatus

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

bridge: guard local VLAN-0 FDB helpers against NULL vlan group

When CONFIGBRIDGEVLANFILTERING is not set, brvlangroup() and nbpvlangroup() return NULL (brprivate.h stub definitions). The BRBOOLOPTFDBLOCALVLAN0 toggle code is compiled unconditionally and reaches brfdbdeletelocalspervlanport() and brfdbinsertlocalspervlanport(), where the NULL vlan group pointer is dereferenced via listforeachentry(v, &vg->vlanlist, vlist).

The observed crash is in the delete path, triggered when creating a bridge with IFLABRMULTIBOOLOPT containing BRBOOLOPTFDBLOCALVLAN0 via RTMNEWLINK. The insert helper has the same bug pattern.

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000056: 0000 [#1] KASAN NOPTI KASAN: null-ptr-deref in range [0x00000000000002b0-0x00000000000002b7] RIP: 0010:brfdbdeletelocalspervlan+0x2b9/0x310 Call Trace: brfdbtogglelocalvlan0+0x452/0x4c0 brtogglefdblocalvlan0+0x31/0x80 net/bridge/br.c:276 brboolopttoggle net/bridge/br.c:313 brbooloptmultitoggle net/bridge/br.c:364 brchangelink net/bridge/brnetlink.c:1542 brdevnewlink net/bridge/brnetlink.c:1575

Add NULL checks for the vlan group pointer in both helpers, returning early when there are no VLANs to iterate. This matches the existing pattern used by other bridge FDB functions such as brfdbadd() and brfdbdelete().

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

srcu: Use irqwork to start GP in tiny SRCU

Tiny SRCU's srcugpstartifneeded() directly calls schedulework(), which acquires the workqueue pool->lock.

This causes a lockdep splat when callsrcu() is called with a scheduler lock held, due to:

callsrcu() [holding pilock] srcugpstartifneeded() schedulework() -> pool->lock

workqueueinit() / createworker() [holding pool->lock] wakeupprocess() -> trytowakeup() -> pilock

Also add irqworksync() to cleanupsrcustruct() to prevent a use-after-free if a queued irqwork fires after cleanup begins.

Tested with rcutorture SRCU-T and no lockdep warnings.

[ Thanks to Boqun for similar fix in patch "rcu: Use an intermediate irqwork to start processsrcu()" ]

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

hwmon: (tps53679) Fix array access with zero-length block read

i2csmbusreadblockdata() can return 0, indicating a zero-length read. When this happens, tps53679identifychip() accesses buf[ret - 1] which is buf[-1], reading one byte before the buffer on the stack.

Fix by changing the check from "ret < 0" to "ret <= 0", treating a zero-length read as an error (-EIO), which prevents the out-of-bounds array access.

Also fix a typo in the adjacent comment: "if present" instead of duplicate "if".

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

Bluetooth: hciconn: fix potential UAF in setcigparamssync

hciconn lookup and field access must be covered by hdev lock in setcigparamssync, otherwise it's possible it is freed concurrently.

Take hdev lock to prevent hciconn from being deleted or modified concurrently. Just RCU lock is not suitable here, as we also want to avoid "tearing" in the configuration.

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

Bluetooth: hcievent: fix potential UAF in hcileremoteconnparamreqevt

hciconn lookup and field access must be covered by hdev lock in hcileremoteconnparamreqevt, otherwise it's possible it is freed concurrently.

Extend the hcidevlock critical section to cover all conn usage.

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

usb: cdns3: gadget: fix NULL pointer dereference in epqueue

When the gadget endpoint is disabled or not yet configured, the ep->desc pointer can be NULL. This leads to a NULL pointer dereference when cdns3gadgetepqueue() is called, causing a kernel crash.

Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the standard return code for unconfigured endpoints.

This prevents potential crashes when epqueue is called on endpoints that are not ready.

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

drm/ioc32: stop speculation on the drmcompatioctl path

The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling arrayindexnospec() on the index to the function pointer list.

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

usb: gadget: frndis: Fix netdevice lifecycle with devicemove

The netdevice is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the netdevice survives, resulting in dangling sysfs symlinks:

console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory

Use devicemove() to reparent the netdevice between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling devicemove(NULL) moves the netdevice to the virtual device tree before the gadget device is destroyed. On rebinding, devicemove() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering.

To maintain compatibility with legacy composite drivers (e.g., multi.c), the borrowednet flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase.

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

counter: rz-mtu3-cnt: prevent counter from being toggled multiple times

Runtime PM counter is incremented / decremented each time the sysfs enable file is written to.

If user writes 0 to the sysfs enable file multiple times, runtime PM usage count underflows, generating the following message.

rz-mtu3-counter rz-mtu3-counter.0: Runtime PM usage count underflow!

At the same time, hardware registers end up being accessed with clocks off in rzmtu3terminatecounter() to disable an already disabled channel.

If user writes 1 to the sysfs enable file multiple times, runtime PM usage count will be incremented each time, requiring the same number of 0 writes to get it back to 0.

If user writes 0 to the sysfs enable file while PWM is in progress, PWM is stopped without counter being the owner of the underlying MTU3 channel.

Check against the cached countisenabled value and exit if the user is trying to set the same enable value.

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

iio: gyro: mpu3050: Fix irq resource leak

The interrupt handler is setup but only a few lines down if iiotriggerregister() fails the function returns without properly releasing the handler.

Add cleanup goto to resolve resource leak.

Detected by Smatch: drivers/iio/gyro/mpu3050-core.c:1128 mpu3050triggerprobe() warn: 'irq' from requestthreadedirq() not released on lines: 1124.

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

iommupt: Fix short gather if the unmap goes into a large mapping

unmap has the odd behavior that it can unmap more than requested if the ending point lands within the middle of a large or contiguous IOPTE.

In this case the gather should flush everything unmapped which can be larger than what was requested to be unmapped. The gather was only flushing the range requested to be unmapped, not extending to the extra range, resulting in a short invalidation if the caller hits this special condition.

This was found by the new invalidation/gather test I am adding in preparation for ARMv8. Claude deduced the root cause.

As far as I remember nothing relies on unmapping a large entry, so this is likely not a triggerable bug.

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

usb: gadget: frndis: Protect RNDIS options with mutex

The class/subclass/protocol options are suspectible to race conditions as they can be accessed concurrently through configfs.

Use existing mutex to protect these options. This issue was identified during code inspection.

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

eventpoll: defer struct eventpoll free to RCU grace period

In certain situations, epfree() in eventpoll.c will kfree the epi->ep eventpoll struct while it still being used by another concurrent thread. Defer the kfree() to an RCU callback to prevent UAF.

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

perf/x86/intel/uncore: Fix die ID init and look up bugs

In snbeppci2phymapinit(), in the nrnodeids > 8 path, uncoredevicetodie() may return -1 when all CPUs associated with the UBOX device are offline.

Remove the WARNONONCE(dieid == -1) check for two reasons:

- The current code breaks out of the loop. This is incorrect because pcigetdevice() does not guarantee iteration in domain or bus order, so additional UBOX devices may be skipped during the scan.

- Returning -EINVAL is incorrect, since marking offline buses with dieid == -1 is expected and should not be treated as an error.

Separately, when NUMA is disabled on a NUMA-capable platform, pcibustonode() returns NUMANONODE, causing uncoredevicetodie() to return -1 for all PCI devices. As a result, sprupdatedevicelocation(), used on Intel SPR and EMR, ignores the corresponding PMON units and does not add them to the RB tree.

Fix this by using uncorepcibustodieid(), which retrieves topology from the UBOX GIDNIDMAP register and works regardless of whether NUMA is enabled in Linux. This requires snbeppci2phymapinit() to be added in spruncorepciinit().

Keep uncoredevicetodie() only for the nrnodeids > 8 case, where NUMA is expected to be enabled.

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

lib/crypto: chacha: Zeroize permutedstate before it leaves scope

Since the ChaCha permutation is invertible, the local variable 'permutedstate' is sufficient to compute the original 'state', and thus the key, even after the permutation has been done.

While the kernel is quite inconsistent about zeroizing secrets on the stack (and some prominent userspace crypto libraries don't bother at all since it's not guaranteed to work anyway), the kernel does try to do it as a best practice, especially in cases involving the RNG.

Thus, explicitly zeroize 'permutedstate' before it goes out of scope.

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

interconnect: qcom: sm8450: Fix NULL pointer dereference in icclinknodes()

The change to dynamic IDs for SM8450 platform interconnects left two links unconverted, fix it to avoid the NULL pointer dereference in runtime, when a pointer to a destination interconnect is not valid:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 <...> Call trace: icclinknodes+0x3c/0x100 (P) qcomiccrpmhprobe+0x1b4/0x528 platformprobe+0x64/0xc0 reallyprobe+0xc4/0x2a8 driverprobedevice+0x80/0x140 driverprobedevice+0x48/0x170 deviceattachdriver+0xc0/0x148 busforeachdrv+0x88/0xf0 deviceattach+0xb0/0x1c0 deviceinitialprobe+0x58/0x68 busprobedevice+0x40/0xb8 deferredprobeworkfunc+0x90/0xd0 processonework+0x15c/0x3c0 workerthread+0x2e8/0x400 kthread+0x150/0x208 retfromfork+0x10/0x20 Code: 900310f4 911d6294 91008280 94176078 (f94002a0) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception

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

bpf: reject direct access to nullable PTRTOBUF pointers

checkmemaccess() matches PTRTOBUF via basetype() which strips PTRMAYBENULL, allowing direct dereference without a null check.

Map iterator ctx->key and ctx->value are PTRTOBUF | PTRMAYBENULL. On stop callbacks these are NULL, causing a kernel NULL dereference.

Add a typemaybenull() guard to the PTRTOBUF branch, matching the existing PTRTOBTFID pattern.

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

most: core: fix leak on early registration failure

A recent commit fixed a resource leak on early registration failures but for some reason left out the first error path which still leaks the resources associated with the interface.

Fix up also the first error path so that the interface is always released on errors.