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

smb: client: fix OOB read in smb2ioctlqueryinfo QUERYINFO path

smb2ioctlqueryinfo() has two response-copy branches: PASSTHRUFSCTL and the default QUERYINFO path. The QUERYINFO branch clamps qi.inputbufferlength to the server-reported OutputBufferLength and then copies qi.inputbufferlength bytes from qirsp->Buffer to userspace, but it never verifies that the flexible-array payload actually fits within rspiov[1].iovlen.

A malicious server can return OutputBufferLength larger than the actual QUERYINFO response, causing copytouser() to walk past the response buffer and expose adjacent kernel heap to userspace.

Guard the QUERYINFO copy with a bounds check on the actual Buffer payload. Use structsize(qirsp, Buffer, qi.inputbufferlength) rather than an open-coded addition so the guard cannot overflow on 32-bit builds.

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

wifi: iwlwifi: mei: pass correct argument to function

The first argument to iwlmeiwritecyclicbuf() should be the cldev but the qhead pointer is passed instead. Fix it.

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

Input: lkkbd - disable pending work before freeing device

lkkbdinterrupt() schedules lk->tq via schedulework(), and the work handler lkkbdreinit() dereferences the lkkbd structure and its serio/inputdev fields.

lkkbddisconnect() and error paths in lkkbdconnect() free the lkkbd structure without preventing the reinit work from being queued again until serioclose() returns. This can allow the work handler to run after the structure has been freed, leading to a potential use-after-free.

Use disableworksync() instead of cancelworksync() to ensure the reinit work cannot be re-queued, and call it both in lkkbddisconnect() and in lkkbdconnect() error paths after serioopen().

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

NTB: epf: Avoid pciiounmap() with offset when PEERSPAD and CONFIG share BAR

When BARPEERSPAD and BARCONFIG share one PCI BAR, the module teardown path ends up calling pciiounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following:

Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pciiounmap+0x2c/0x40 ntbepfpciremove+0x44/0x80 [ntbhwepf] pcideviceremove+0x48/0xf8 deviceremove+0x50/0x88 devicereleasedriverinternal+0x1c8/0x228 driverdetach+0x50/0xb0 busremovedriver+0x74/0x100 driverunregister+0x34/0x68 pciunregisterdriver+0x34/0xa0 ntbepfpcidriverexit+0x14/0xfe0 [ntbhwepf] [...]

Fix it by unmapping only when PEERSPAD and CONFIG use difference bars.

i2c: i801: fix hardware state machine corruption in error path

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

xfs: fail recovery on a committed log item with no regions

If the first op of a transaction is a bare transaction header (len == sizeof(struct xfstransheader)), xlogrecoveraddtotrans() adds an item but no region, leaving it on ritemq with ricnt == 0 and ribuf == NULL.

The header can be split across op records, so later ops may still add regions; the item is only invalid if the transaction commits with none. The runtime commit path never emits such a transaction, so this only happens on a crafted log. It came from an AI-assisted code audit of the recovery parser.

xlogrecoverreordertrans() calls ITEMTYPE() on the item, which reads (unsigned short )item->ribuf[0].iovbase and faults on the NULL ribuf. Reject it there, before the commit handlers that also read ribuf[0].

KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:xlogrecoverreordertrans (fs/xfs/xfslogrecover.c:1836) xlogrecovercommittrans (fs/xfs/xfslogrecover.c:2043) xlogrecoverprocessdata (fs/xfs/xfslogrecover.c:2501) xlogdorecoverypass (fs/xfs/xfslogrecover.c:3244) xlogrecover (fs/xfs/xfslogrecover.c:3493) xfslogmount (fs/xfs/xfslog.c:618) xfsmountfs (fs/xfs/xfsmount.c:1034) xfsfsfillsuper (fs/xfs/xfssuper.c:1938) vfsgettree (fs/super.c:1695) pathmount (fs/namespace.c:4161) x64sysmount (fs/namespace.c:4367)

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

netfs: Fix overrun check in netfsextractuseriter()

Fix netfsextractuseriter() so that if ioviterextractpages() overfills pages[], then those pages don't get included in the iterator constructed at the end of the function. If there was an overfill, memory corruption has already happened.

drivers/base/memory: set mem->altmap after successful device registration

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

powerpc/eeh: Make EEH driver device hotplug safe

Multiple race conditions existed between the PCIe hotplug driver and the EEH driver, leading to a variety of kernel oopses of the same general nature:

<pcie device unplug> <eeh driver trigger> <hotplug removal trigger> <pcie tree reconfiguration> <eeh recovery next step> <oops in EEH driver bus iteration loop>

A second class of oops is also seen when the underlying bus disappears during device recovery.

Refactor the EEH module to be PCI rescan and remove safe. Also clean up a few minor formatting / readability issues.

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

crypto: ccp - copy IV using skcipher ivsize

AFALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver.

ccpaescomplete() restores AESBLOCKSIZE bytes into the caller's IV buffer while RFC3686 skciphers expose an 8-byte IV, so the restore overruns the provided buffer.

Use cryptoskcipherivsize() to copy only the algorithm's IV length.

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

nvmet-tcp: add bounds checks in nvmettcpbuildpduiovec

nvmettcpbuildpduiovec() could walk past cmd->req.sg when a PDU length or offset exceeds sgcnt and then use bogus sg->length/offset values, leading to copytoiter() GPF/KASAN. Guard sgidx, remaining entries, and sg->length/offset before building the bvec.

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

ipv6: fix possible infinite loop in fib6selectpath()

Found while auditing the same pattern Sashiko reported in rt6fillnode() [1]. Apply the same fix as commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6infousesdev()").

Writers holding tb6lock can listdelrcu(&first->fib6siblings) without waiting for RCU readers; first->fib6siblings.next then still points into the old ring and this softirq-side walker never reaches &first->fib6siblings as its terminator. fib6purgert() always WRITEONCE()s first->fib6nsiblings to 0 before listdelrcu(), so an inside-loop check is a reliable detach signal.

[1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev

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

KVM: x86: hyper-v: Bound the bank index when querying sparse banks

When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096.

Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU.

================================================================== BUG: KASAN: use-after-free in hvisvpinsparseset+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hypervevmcs/2802

CPU: 12 UID: 1000 PID: 2802 Comm: hypervevmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dumpstacklvl+0x51/0x60 printreport+0xcb/0x5d0 kasanreport+0xb4/0xe0 kasancheckrange+0x35/0x1b0 hvisvpinsparseset+0x85/0x100 [kvm] kvmhvflushtlb+0xe9e/0x16c0 [kvm] kvmhvhypercall+0xe6b/0x1e60 [kvm] vmxhandleexit+0x485/0x1b60 [kvmintel] kvmarchvcpuioctlrun+0x22e3/0x5070 [kvm] kvmvcpuioctl+0x5d0/0x10c0 [kvm] x64sysioctl+0x129/0x1a0 dosyscall64+0xb9/0xcf0 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf </TASK>

The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint

Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask.

[sean: add KASAN splat, drop comment, add assert, massage changelog]

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

ALSA: ice1712: check sndctlnew1() return value

sndctlnew1() can return NULL when memory allocation fails. The ice1712 driver calls sndctlnew1() without checking the return value before dereferencing the pointer in multiple places (ice1712.c, ice1724.c, aureon.c), which can lead to NULL pointer dereferences.

Add NULL checks after sndctlnew1() calls and return -ENOMEM if any fails.

bpf: use kvfree() for replaced sysctl write buffer

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

usb: typec: ucsi: unregister debugfs entries on teardown

ucsiregister() creates per-instance debugfs entries, but ucsiunregister() keeps them around until ucsidestroy().

Drivers like ucsiglink that unregister/register the same UCSI instance across remoteproc restart then try to create an already existing debugfs directory and log:

debugfs: 'pmicglink.ucsi.0' already exists in 'ucsi'

Unregister debugfs entries as part of ucsiunregister(), and clear ucsi->debugfs after freeing it so repeated unregister paths remain safe.

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

netfilter: ebtables: module names must be null-terminated

We need to explicitly check the length, else we may pass non-null terminated string to requestmodule().

dm log: fix out-of-bounds write due to regioncount overflow

afpacket: Don't cast tpackethdr.tplen to int in tpacketparseheader().

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

md/raid5: validate payload size before accessing journal metadata

r5crecoveryanalyzemetablock() and r5lrecoveryverifydatachecksumformb() iterate over payloads in a journal metadata block using on-disk payload size fields without validating them against the remaining space in the metadata block.

A corrupted journal contains payload sizes extending beyond the PAGESIZE boundary can cause out-of-bounds reads when accessing payload fields or computing offsets.

Add bounds validation for each payload type to ensure the full payload fits within metasize before processing.

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

staging: rtl8723bs: fix OOB reads in rtwgetsecie(), rtwgetwapiie(), and rtwgetwpsattr()

Three IE/attribute parsing functions have missing bounds checks.

rtwgetsecie() and rtwgetwapiie() iterate over a raw IE buffer without verifying that the header bytes (tag + length) are within the remaining buffer before reading them. Additionally, rtwgetsecie() compares the 4-byte WPA OUI at cnt+2 without checking that at least 6 bytes remain, and rtwgetwapiie() compares a 4-byte WAPI OUI at cnt+6 without checking that at least 10 bytes remain.

rtwgetwpsattr() reads wpsie[0] and wpsie+2 unconditionally at entry, before verifying that wpsielen is large enough to contain the 6-byte WPS IE header (elementid + length + 4-byte OUI). Inside the attribute loop, getunalignedbe16() is called on attrptr and attrptr+2 without checking that 4 bytes remain in the buffer.

Add a cnt+2 bounds check before each loop body in rtwgetsecie() and rtwgetwapiie(), guard each multi-byte comparison with a minimum IE length requirement, add a wpsielen < 6 early return in rtwgetwpsattr(), and add a 4-byte bounds check in its inner loop.

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

smb: client: require a full NFS mode SID before reading mode bits

parsedacl() treats an ACE SID matching sidunixNFSmode as an NFS mode SID and reads sid.subauth[2] to recover the mode bits.

That assumes the ACE carries three subauthorities, but comparesids() only compares min(a, b) subauthorities. A malicious server can return an ACE with numsubauth = 2 and subauth[] = {88, 3}, which still matches sidunixNFSmode and then drives the subauth[2] read four bytes past the end of the ACE.

Require numsubauth >= 3 before treating the ACE as an NFS mode SID. This keeps the fix local to the special-SID mode path without changing comparesids() semantics for the rest of cifsacl.

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

nvmet-tcp: fix race between ICReq handling and queue teardown

nvmettcphandleicreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown.

If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before iowork drains the already buffered ICReq. In that case, nvmettcpschedulereleasequeue() sets queue->state to NVMETTCPQDISCONNECTING and drops the queue reference under statelock.

If iowork later processes that ICReq, nvmettcphandleicreq() can still overwrite the state back to NVMETTCPQLIVE. That defeats the DISCONNECTING-state guard in nvmettcpschedulereleasequeue() and allows a later socket state change to re-enter teardown and issue a second krefput() on an already released queue.

The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMETTCPQFAILED, again reopening the window for a second teardown path to drop the queue reference.

Fix this by serializing both post-send state transitions with statelock and bailing out if teardown has already started.

Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmettcpsocketerror() setting rcvstate to NVMETTCPRECVERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.

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

x86,fs/resctrl: Prevent out-of-bounds access while offlining CPU when SNC enabled

The architecture updates the cpumask in a domain's header to track which online CPUs are associated with the domain. When this mask becomes empty the architecture initiates offline of the domain that includes calling on resctrl fs to offline the domain. If it is a monitoring domain in which LLC occupancy is tracked resctrl fs forces the limbo handler to clear all busy RMID state associated with the domain.

The limbo handler always reads the current event value associated with a busy RMID irrespective of it being checked as part of regular "is it still busy" check or whether it will be forced released anyway. When reading an RMID on a system with SNC enabled the "logical RMID" is converted to the "physical RMID" and this conversion requires the NUMA node ID of the resctrl monitoring domain that is in turn determined by querying the NUMA node ID of any CPU belonging to the monitoring domain.

When the monitoring domain is going offline its cpumask is empty causing the NUMA node ID query via cputonode() to be done with "nrcpuids" as argument resulting in an out-of-bounds access.

Refactor the limbo handler to skip reading the RMID when the RMID will just be forced to no longer be dirty in the domain anyway. Add a safety check to the architecture's RMID reader to protect against this scenario.

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

Bluetooth: bnep: Fix UAF read of dev->name

bnepaddconnection() needs to keep holding the bnepsessionsem while reading dev->name (just like bnepgetconnlist() does); otherwise the bnepsession() thread can concurrently free the netdevice, which can for example be triggered by a concurrent bnepdelconnection().

(This UAF is fairly uninteresting from a security perspective; calling bnepaddconnection() requires passing a capable(CAPNETADMIN) check. It also requires completely tearing down a netdev during a fairly tight race window.)

Bluetooth: L2CAP: cancel pendingrxwork before taking conn->lock

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

net: wwan: iosm: fix potential memory leaks in ipcimeminit()

The memory allocated in ipcprotocolinit() is not freed on the error paths that follow in ipcimeminit(). Fix that by calling the corresponding release function ipcprotocoldeinit() in the error path.

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

drm/amd/display: Validate payload length and linkindex in dcprocessdmubauxtransferasync

[Why&How] dcprocessdmubauxtransferasync() copies payload->length bytes into a 16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which is a no-op in release builds. If a caller ever passes length > 16 this results in a stack buffer overflow via memcpy.

Additionally, linkindex is used to dereference dc->links[] without bounds checking against dc->linkcount, risking an out-of-bounds access.

Replace the ASSERT with a hard runtime check that returns false when payload->length exceeds the destination buffer size, and add a bounds check for linkindex before it is used.

(cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881)

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

device property: set fwnode->secondary to NULL in fwnodeinit()

If a firmware node is allocated on the stack (for instance: temporary software node whose life-time we control) or on the heap - but using a non-zeroing allocation function - and initialized using fwnodeinit(), its secondary pointer will contain uninitalized memory which likely will be neither NULL nor ISERR() and so may end up being dereferenced (for example: in devtoswnode()). Set fwnode->secondary to NULL on initialization.

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

spi: ti-qspi: fix use-after-free after DMA setup failure

The driver falls back to PIO mode if DMA setup fails during probe.

Make sure to clear the DMA channel pointer also if buffer allocation fails to avoid passing a pointer to the released channel to the DMA engine (or trying to free the channel a second time on late probe errors or driver unbind).

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.