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

net: ipa: fix event ring index not programmed for IPA v5.0+

For IPA v5.0+, the event ring index field moved from CHCCNTXT0 to CHCCNTXT1. The v5.0 register definition intended to define this field in the CHCCNTXT1 fmask array but used the old identifier of ERINDEX instead of CHERINDEX.

Without a valid event ring, GSI channels could never signal transfer completions. This caused gsichanneltransquiesce() to block forever in waitforcompletion().

At least for IPA v5.2 this resolves an issue seen where runtime suspend, system suspend, and remoteproc stop all hanged forever. It also meant the IPA data path was completely non functional.

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

ice: ptp: don't WARN when controlling PF is unavailable

In VFIO passthrough setups, it is possible to pass through only a PF which doesn't own the source timer. In that case the PTP controlling PF (adapter->ctrlpf) is never initialized in the VM, so icegetctrlptp() returns NULL and triggers WARNON() in iceptpsetuppf().

Since this is an expected behavior in that configuration, replace WARNON() with an informational message and return -EOPNOTSUPP.

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

mm/hugetlb: restore failed global reservations to subpool

Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") fixed an underflow error for hstate->resvhugepages caused by incorrectly attributing globally requested pages to the subpool's reservation.

Unfortunately, this fix also introduced the opposite problem, which would leave spool->usedhpages elevated if the globally requested pages could not be acquired. This is because while a subpool's reserve pages only accounts for what is requested and allocated from the subpool, its "used" counter keeps track of what is consumed in total, both from the subpool and globally. Thus, we need to adjust spool->usedhpages in the other direction, and make sure that globally requested pages are uncharged from the subpool's used counter.

Each failed allocation attempt increments the usedhpages counter by how many pages were requested from the global pool. Ultimately, this renders the subpool unusable, as usedhpages approaches the max limit.

The issue can be reproduced as follows: 1. Allocate 4 hugetlb pages 2. Create a hugetlb mount with max=4, min=2 3. Consume 2 pages globally 4. Request 3 pages from the subpool (2 from subpool + 1 from global) 4.1 hugepagesubpoolgetpages(spool, 3) succeeds. usedhpages += 3 4.2 hugetlbacctmemory(h, 1) fails: no global pages left usedhpages -= 2 5. Subpool now has usedhpages = 1, despite not being able to successfully allocate any hugepages. It believes it can now only allocate 3 more hugepages, not 4.

With each failed allocation attempt incrementing the used counter, the subpool eventually reaches a point where its used counter equals its max counter. At that point, any future allocations that try to allocate hugeTLB pages from the subpool will fail, despite the subpool not having any of its hugeTLB pages consumed by any user.

Once this happens, there is no way to make the subpool usable again, since there is no way to decrement the used counter as no process is really consuming the hugeTLB pages.

The underflow issue that the original commit fixes still remains fixed as well.

Without this fix, usedhpages would keep on leaking if hugetlbacctmemory() fails.

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:

ext4: always drain queued discard work in ext4mbrelease()

While reviewing recent ext4 patch[1], Sashiko raised the following concern[2]:

If the filesystem is initially mounted with the discard option, deleting files will populate sbi->sdiscardlist and queue sdiscardwork. If it is then remounted with nodiscard, the EXT4MOUNTDISCARD flag is cleared, but the pending sdiscardwork is neither cancelled nor flushed.

[1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/ [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev

The concern was valid, but it had nothing to do with the patch[1]. One of the problems with Sashiko in its current (early) form is that it will detect pre-existing issues and report it as a problem with the patch that it is reviewing.

In practice, it would be hard to hit deliberately (unless you are a malicious syzkaller fuzzer), since it would involve mounting the file system with -o discard, and then deleting a large number of files, remounting the file system with -o nodiscard, and then immediately unmounting the file system before the queued discard work has a change to drain on its own.

Fix it because it's a real bug, and to avoid Sashiko from raising this concern when analyzing future patches to mballoc.c.

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

ipv4: icmp: fix null-ptr-deref in icmpbuildprobe()

ipv6stub->ipv6devfind() may return ERRPTR(-EAFNOSUPPORT) when the IPv6 stack is not active (CONFIGIPV6=m and not loaded), and passing this error pointer to devhold() will cause a kernel crash with null-ptr-deref.

Instead, silently discard the request. RFC 8335 does not appear to define a specific response for the case where an IPv6 interface identifier is syntactically valid but the implementation cannot perform the lookup at runtime, and silently dropping the request may safer than misreporting "No Such Interface".

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

soc: qcom: pd-mapper: Fix element length in servreglocpfrreqei

It looks element length declared in servreglocpfrreqei for reason not matching servreglocpfrreq's reason field due which we could observe decoding error on PD crash.

qmidecodestringelem: String len 81 >= Max Len 65

Fix this by matching with servreglocpfrreq's reason field.

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:

xsk: validate MTU against usable frame size on bind

AFXDP bind currently accepts zero-copy pool configurations without verifying that the device MTU fits into the usable frame space provided by the UMEM chunk.

This becomes a problem since we started to respect tailroom which is subtracted from chunksize (among with headroom). 2k chunk size might not provide enough space for standard 1500 MTU, so let us catch such settings at bind time. Furthermore, validate whether underlying HW will be able to satisfy configured MTU wrt XSK's frame size multiplied by supported Rx buffer chain length (that is exposed via netdevice::xdpzcmaxsegs).

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

x86: shadow stacks: proper error handling for mmap lock

김영민 reports that shstkpopsigframe() doesn't check for errors from mmapreadlockkillable(), which is a silly oversight, and also shows that we haven't marked those functions with "mustcheck", which would have immediately caught it.

So let's fix both issues.

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: airoha: Fix memory leak in airohaqdmarxprocess()

If an error occurs on the subsequents buffers belonging to the non-linear part of the skb (e.g. due to an error in the payload length reported by the NIC or if we consumed all the available fragments for the skb), the pagepool fragment will not be linked to the skb so it will not return to the pool in the airohaqdmarxprocess() error path. Fix the memory leak partially reverting commit 'd6d2b0e1538d ("net: airoha: Fix page recycling in airohaqdmarxprocess()")' and always running pagepoolputfullpage routine in the airohaqdmarxprocess() error path.

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:

net: use skbheaderpointer() for TCPv4 GSO fragoff check

Syzbot reported a KMSAN uninit-value warning in gsofeaturescheck() called from netifskbfeatures() [1].

gsofeaturescheck() reads iph->fragoff to decide whether to clear mangleidfeatures. Accessing the IPv4 header via iphdr()/inneriphdr() can rely on skb header offsets that are not always safe for direct dereference on packets injected from PFPACKET paths.

Use skbheaderpointer() for the TCPv4 fragoff check so the header read is robust whether data is already linear or needs copying.

[1] https://syzkaller.appspot.com/bug?extid=1543a7d954d9c6d00407

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:

drm/vc4: Fix memory leak of BO array in hang state

The hang state's BO array is allocated separately with kzalloc() in vc4savehangstate() but never freed in vc4freehangstate(). Add the missing kfree() for the BO array before freeing the hang state struct.

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:

xfrm: fix refcount leak in xfrmmigratepolicyfind

syzkaller reported a memory leak in xfrmpolicyalloc:

BUG: memory leak unreferenced object 0xffff888114d79000 (size 1024): comm "syz.1.17", pid 931 ... xfrmpolicyalloc+0xb3/0x4b0 net/xfrm/xfrmpolicy.c:432

The root cause is a double call to xfrmpolholdrcu() in xfrmmigratepolicyfind(). The lookup function already returns a policy with held reference, making the second call redundant.

Remove the redundant xfrmpolholdrcu() call to fix the refcount imbalance and prevent the memory leak.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

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:

iouring/rsrc: reject zero-length fixed buffer import

validatefixedrange() admits bufaddr at the exact end of the registered region when len is zero, because the check uses strict greater-than (bufend > imu->ubuf + imu->len). ioimportfixed() then computes offset == imu->len, which causes the bvec skip logic to advance past the last biovec entry and read bvoffset from out-of-bounds slab memory.

Return early from ioimportfixed() when len is zero. A zero-length import has no data to transfer and should not walk the bvec array at all.

BUG: KASAN: slab-out-of-bounds in ioimportregbuf+0x697/0x7f0 Read of size 4 at addr ffff888002bcc254 by task poc/103 Call Trace: ioimportregbuf+0x697/0x7f0 iowritefixed+0xd9/0x250 ioissuesqe+0xad/0x710 ioissuesqe+0x7d/0x1100 iosubmitsqes+0x86a/0x23c0 dosysiouringenter+0xa98/0x1590 Allocated by task 103: The buggy address is located 12 bytes to the right of allocated 584-byte region [ffff888002bcc000, ffff888002bcc248)

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.