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

platform/chrome: crosectypec: Reject out-of-bounds PD cap count

crostypecregisterpartnerpdos() copies the partner PDOs from the EC TYPECSTATUS response into the fixed capsdesc.pdo[PDOMAXOBJECTS] array.

memcpy(capsdesc.pdo, resp->sourcecappdos, sizeof(u32) resp->sourcecapcount); ... memcpy(capsdesc.pdo, resp->sinkcappdos, sizeof(u32) resp->sinkcapcount);

PDOMAXOBJECTS is 7. sourcecapcount and sinkcapcount are u8 fields from the EC. The only check is that they are not both zero. If either is larger than 7, the memcpy writes past the end of the array on the stack. A count of 255 overflows it by about 1 KB. The EC source arrays are only seven entries wide. A larger count reads past them too.

The ChromeOS EC firmware caps these counts today, so a compliant setup does not hit this. The kernel should still validate these values rather than trust them.

Validate the counts in crostypecregisterpartnerpdos() next to the memcpy. Skip the PDO registration if either count is above PDOMAXOBJECTS. The rest of crostypechandlestatus() still runs so events are handled and cleared.

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

HID: core: quiesce input in hidhwstop() to prevent use-after-free

A driver's probe calls hiddeviceiostart() to enable input delivery, then fails at a later initialization step and unwinds via hidhwstop(). The unwind frees struct hidraw via hidrawdisconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidrawreportevent(). syzbot reports the resulting use-after-free for the corsair-psu HID driver.

Edward Adam Davis posted a per-driver fix for corsair-psu that adds an explicit hiddeviceiostop() before hidhwstop() in the probe error path ("hwmon: prevent packets from going to driver for probe", 2026-04-28). Auditing the tree shows 15 drivers call hiddeviceiostart(); 7 also call hiddeviceiostop() and 8 do not:

drivers calling hiddeviceiostart() without a matching hiddeviceiostop() before hidhwstop(): drivers/hwmon/corsair-psu.c (fix posted by Edward) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabytewaterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c

Roughly half of all callers of the API are exposed. Centralize the quiesce in hidhwstop() so callers do not have to remember the matching stop: if a driver has left hdev->iostarted true on entry, call hiddeviceiostop() before hiddisconnect().

For the 7 drivers that already call hiddeviceiostop() correctly, hdev->iostarted is false on entry, the guard short-circuits, and behavior is unchanged.

No Fixes: tag because the affected drivers gained their hiddeviceiostart() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit.

drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup

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

dmaengine: xilinxdma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers

Fix a race condition in AXIDMA and MCDMA irq handlers where the channel could be incorrectly marked as idle and attempt spurious transfers when descriptors are still being processed.

The issue occurs when: 1. Multiple descriptors are queued and active. 2. An interrupt fires after completing some descriptors. 3. xilinxdmacompletedescriptor() moves completed descriptors to donelist. 4. Channel is marked idle and starttransfer() is called even though activelist still contains unprocessed descriptors. 5. This leads to premature transfer attempts and potential descriptor corruption or missed completions.

Only mark the channel as idle and start new transfers when the active list is actually empty, ensuring proper channel state management and avoiding spurious transfer attempts.

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

platform/chrome: sensorhub: Fix memory overread in ring handler

maxresponse and sensornum are read from different EC commands:

- maxresponse is from crosecgetprotoinfo(). ecdev->maxresponse = info->maxresponsepacketsize - sizeof(struct echostresponse);

- sensornum is from crosecgetsensorcount(). sensornum = crosecgetsensorcount(ec);

With a malfunctioning EC firmware, it is possible that the msg->insize (i.e., fifoinfolength in the context) could be clamped in croseccmdxfer() because msg->insize is greater than maxresponse.

int fifoinfolength = sizeof(struct ecresponsemotionsensefifoinfo) + sizeof(u16) sensorhub->sensornum;

This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in crosecsensorhubringhandler() overreads the resp->fifoinfo buffer.

Check the return value of croseccmdxferstatus() and abort if the number of bytes read does not match the expected length.

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

nvmet-rdma: fix response resource leak on queue teardown

When an nvme target with rdma transport is removed while I/Os are in flight, a response can be posted but its send completion is never delivered before the connection is torn down. As a result nvmetrdmasenddone() and nvmetrdmareleasersp() are never called for the response, and this leaks the allocated RDMA read/write context and request SGLs.

These leaks are recreated by running blktests nvme/061 with the rdma transport and the siw driver. Kernel kmemleak feature reports them as follows:

unreferenced object 0xffff88812bc490c0 (size 32): comm "kworker/2:1H", pid 409, jiffies 4307744490 backtrace (crc 89afd339): kmallocnoprof+0x5f9/0x890 sglallocorder+0x7b/0x380 nvmetreqallocsgls+0x290/0x4f0 [nvmet] nvmetrdmamapsglkeyed+0x241/0x12e0 [nvmetrdma] nvmetrdmahandlecommand+0x73e/0xb80 [nvmetrdma] ibprocesscq+0x149/0x4c0 [ibcore] ibcqpollwork+0x49/0x160 [ibcore] processonework+0x8b2/0x1640 workerthread+0x5fd/0xfe0 kthread+0x367/0x460 retfromfork+0x655/0x9d0 retfromforkasm+0x1a/0x30

unreferenced object 0xffff88814bd05e80 (size 64): comm "kworker/3:1H", pid 148, jiffies 4295195428 backtrace (crc e35510cb): kmallocnoprof+0x5f9/0x890 rdmarwctxinit+0x333/0x1fa0 [ibcore] nvmetrdmamapsglkeyed+0x5c8/0x12e0 [nvmetrdma] nvmetrdmahandlecommand+0x73e/0xb80 [nvmetrdma] ibprocesscq+0x149/0x4c0 [ibcore] ibcqpollwork+0x49/0x160 [ibcore] processonework+0x8b2/0x1640 workerthread+0x5fd/0xfe0 kthread+0x367/0x460 retfromfork+0x655/0x9d0 retfromforkasm+0x1a/0x30

To avoid the memory leaks, reclaim the memory of the in-flight responses when the queue QP is torn down. Call nvmetrdmafreerspresources() that frees up the RDMA read/write context and the request SGLs of such responses.

bpf: Reject rdonly/rdwrbufsize kfunc arguments that exceed u32 max

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

RDMA/rxe: Avoid reprocessing the current packet after the QP enters the error state

When docomplete() finds the QP in the error state it returns RESPSTCHKRESOURCE. Before commit 49dc9c1f0c7e ("RDMA/rxe: Cleanup reset state handling in rxeresp.c") this was the flush loop: checkresource() had an error-state branch that fetched each remaining recv WQE and completed it with IBWCWRFLUSHERR, without touching the current packet. That commit removed the error-state branch from checkresource() (draining is now done at rxereceiver() entry) but kept the docomplete() error-state return.

As a result, when a QP moves to the error state while a packet is being completed - e.g. an rdmacm disconnect racing with receive processing - the responder state machine loops back into the request processing chain with the already-completed packet still in hand: checkresource() fetches a fresh recv WQE, execute()/senddatain() copies the same packet payload again, docomplete() posts another IBWCSUCCESS CQE (qp->resp.status is still 0), and control returns to the error-state check. The loop re-executes the same packet once per posted recv WQE (observed: ~1000 duplicate IBWCSUCCESS completions of one SEND, one per ~8us, matching the RQ occupancy) until the RQ is exhausted, after which qp->resp.wqe is NULL and senddatain() dereferences it:

BUG: kernel NULL pointer dereference, address: 0000000000000014 Workqueue: rxewq dowork RIP: copydata+0x29/0x1f0 Call Trace: senddatain+0x25/0x50 rxereceiver+0xf36/0x1dd0

The duplicate completions are indistinguishable from real receives to the ULP. During an rds stress test, the message was accepted as new and delivered the same datagram to user space hundreds of times, corrupting the stream; any ULP that relies on RC exactly-once delivery is affected.

A live packet reaching the error-state check in docomplete() has been executed and completed exactly once and must be consumed, not re-processed. Return RESPSTCLEANUP for it (dequeue and free); keep returning RESPSTCHKRESOURCE for the pkt == NULL case.

firmware: armscmi: Avoid IDR updates while cleaning channels

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

media: ipu6: Do not free aux device pdata after init

ipu6businitializedevice() stores the isys/psys pdata pointer in struct ipu6busdevice and initializes the auxiliary device. After that point, error unwinding must drop the auxiliary device reference and let ipu6busrelease() free both the bus device and adev->pdata.

The isys and psys init paths already call putdevice() when MMU initialization fails, and ipu6busadddevice() calls auxiliarydeviceuninit() on auxiliarydeviceadd() failure. Both paths therefore run the bus release callback. The extra kfree(pdata) in the callers can release the same object a second time.

Remove the manual pdata frees after the auxiliary device has been initialized.

This issue was found by a static analysis checker and confirmed by manual source review.

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

wifi: iwlwifi: mvm: fix off-by-one in TXF key sanitiser

iwlmvmfrobtxfkeyiter() tracks the last matched byte position in loop variable 'i'. When a full key match is found (match == keylen), 'i' points at the last byte of the matched key. The memset start offset should therefore be i + 1 - keylen, not i - keylen; the current code zeroes one byte before the match and leaves the final key byte un-sanitised.

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

wifi: iwlwifi: mei: check SAP message length before reading it

Verify the SAP message size is not larger than the local buffer before reading the message to avoid buffer overflow.

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

ipack: ipoctal: fix UAF, null-ptr-deref, and use-after-free in cleanup on remove

Three issues arise when the device is removed while a tty session is still active:

1. UAF of struct ipoctal: the remove callback frees ipoctal via kfree() while tty ops may still access it. Fix by introducing kref-based lifetime management — kref is taken in install() when a tty is opened and released in cleanup() when the tty is finally destroyed; remove() uses krefput() instead of kfree().

2. NULL dereference in ipoctalwritetty(): ipoctalremove() frees xmitbuf via ttyportfreexmitbuf() while a userspace process may still hold the tty fd and call write(). Fix by checking for NULL xmitbuf in ipoctalwritetty().

3. UAF in ipoctalcleanup(): ipackputcarrier(ipoctal->dev) dereferences ipoctal->dev after the ipackdevice has been freed by ipackdevicedel(). Fix by caching ipoctal->carrierowner during probe() and calling moduleput() on the cached pointer directly in cleanup(), avoiding any access to ipoctal->dev.

Also introduce a "removed" flag in struct ipoctal, set at the start of ipoctalremove(), and checked in every tty op that accesses hardware resources (portactivate, writetty, settermios, hangup, shutdown). This prevents page faults when devmioremap() regions are unmapped after remove() returns.

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

software node: Fix softwarenodegetreferenceargs() with index -1

The bounds check for the index passed to softwarenodegetreferenceargs() was failing when passed UINTMAX, this in turn would lead to an out of bound access in the property array. Fix the bound check to also cover the UINTMAX case.

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

RDMA/hfi1: Propagate sdmatxinitahg() errors

settxreqheaderahg() ignores the return value of sdmatxinitahg().

If sdmatxinitahg() fails, it returns before initializing tx->txreq. However, settxreqheaderahg() ignores the error and returns the AHG change count, causing the caller to continue processing the request as though initialization had succeeded.

Propagate sdmatxinitahg() failures to the caller and abort request processing when initialization fails.

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

ACPI: processor: validate MADT IOAPIC entry bounds

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

RDMA/core: Fix potential use after free in ibdestroycquser()

When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdmarestrackget(). Currently, rdmarestrackdel() is invoked at the end of ibdestroycquser(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free.

Fix this by moving the rdmarestrackbegindel() call to the start of ibdestroycquser(), ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction.

In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable.

firmware: armscmi: Fix requested device removal race

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

iommu/tegra241-cmdqv: Synchronize the error ISR against VINTF (de)init

A user VINTF is torn down by tegra241cmdqvdeinitvintf(), which runs from the destroy callback and from the init-failure unwind in the alloc handler. It clears the cmdqv->vintfs[] slot and lets the iommufd core free it, but nothing serializes that against the error interrupt: tegra241cmdqvisr() reads cmdqv->vintfs[idx] and dereferences the vintf. A concurrent error can make the ISR read a slot mid-clear (a NULL deref) or use a vintf which is about to be freed (a use-after-free).

deinitvintf() also returns idx to the IDA before clearing the slot, so a concurrent create that reuses idx can publish its new vintf into the slot, only for this teardown to erase it again with the stale NULL store.

On the other end, tegra241cmdqvinitvintf() publishes a new vintf with a plain store to the cmdqv->vintfs[] slot, and the ISR dereferences fields of a published vintf such as vintf->base. A plain store gives no ordering on a weakly-ordered CPU, and a stale VINTFERRMAP bit on a reused idx can make the ISR pick a vintf the moment it is published, before its fields are set or tegra241vintfhwinit() runs.

The cmdqv->vintfs[0] slot stays NULL until tegra241cmdqvinitstructures() first creates VINTF0, so the slot 0 read needs the same NULL check.

Publish every slot with an smpstorerelease(), and read each slot in the ISR with an smploadacquire() under a NULL check, so the ISR always sees a fully built vintf or NULL. Also make deinitvintf() clear the slot, and synchronizeirq() prior to returning idx to the IDA, so no vintf is freed under a running handler and no reused idx is clobbered.

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

nilfs2: prevent out-of-bounds read in super root block parsing

super-root inode metadata size is trusted before nilfsreadinodecommon().

Reject super-root inode sizes whose computed on-disk footprint exceeds the filesystem block size. This prevents malformed filesystem images from making nilfsreadinodecommon() read past the end of the super-root block.

[ryusuke: clarify the commit title]

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

nvme-fc: unmap cmdiu DMA on rspiu mapping failure in initrequest

nvmefcinitrequest() maps cmdiu and then rspiu for DMA. If the rspiu mapping fails, the original code only recorded the error and fell through: it left the already-mapped cmdiu unmapped and still marked the op as FCPOPSTATEIDLE before returning. Since blk-mq does not call .exitrequest() when .initrequest() fails, the cmdiu mapping is leaked for every op whose rspiu mapping fails.

Jump to an error path on rspiu mapping failure that unmaps cmdiu and returns the error without marking the op idle, so it stays in the FCPOPSTATEUNINIT state set by the initial memset().

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

wifi: mt76: mt792x: fix use-after-free in mt76rxpollcomplete

A use-after-free issue occurs in mt76rxpollcomplete due to a race condition. The STA has already been removed, but the rxstatus still had a pointer to the wcid in the STA.

Set the links' wcid pointers to be NULL for a MLD in mt7925staprercuremove()

BUG: KASAN: invalid-access in mt76rxpollcomplete+0x280/0x470 Call trace: dumpbacktrace+0xec/0x128 showstack+0x18/0x28 dumpstacklvl+0x40/0xc8 printreport+0x1b8/0x710 kasanreport+0xe0/0x144 dobadarea+0x120/0x260 dotagcheckfault+0x20/0x34 domemabort+0x54/0xa8 el1abort+0x3c/0x5c el1h64synchandler+0x40/0xcc el1h64sync+0x7c/0x80 mt76rxpollcomplete+0x280/0x470 mt76dmarxpoll+0x114/0x51c mt792xpollrx+0x60/0xf8 napithreadedpollloop+0xe0/0x450 napithreadedpoll+0x80/0x9c kthread+0x11c/0x158 retfromfork+0x10/0x20

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

wifi: mt76: fix RXDMADC buffer recycling race

The RXDMADC buffers come from the RRO data queues' page pools, which are bound to a different NAPI, so the direct page-pool recycle used here could race the owning NAPI; take the non-direct path as is already done for WED RX queues.

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

wifi: mt76: mt7996: reserve space for the CSA-abort countdown TLV

When a CSA countdown is active, mt7996mcubeaconcntdwn() emits two bssbcncntdwntlv entries (the CSA countdown and the CCA-abort BCC), but MT7996BEACONUPDATESIZE only reserved one. With MBSSID enabled and a near-maximum beacon template the extra 8 bytes could push the offload command past MT7996MAXBSSOFFLOADSIZE and trigger skboverpanic(). Reserve room for both countdown TLVs.

drm/msm/dsi: Drop devpmoppsetrate(0)

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

wifi: mt76: mt7915: fix ext PHY use-after-free on register error path

After mt7915registerextphy() succeeded, a failure of the main PHY mt7915initdebugfs() or mt7915coredumpregister() unwound through freephy2, which called ieee80211freehw() on the ext PHY hw while it was still registered with mac80211, since mt76unregisterdevice() only unregisters the main hw. Unregister the ext PHY (thermal + phy + hw) first and skip the redundant free.

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

firmware: coreboot: Validate table bounds

The existing coreboottablepopulate() bounds checks limit individual entries to the mapped length. However, coreboottableprobe() replaces the platform resource length with header and table sizes supplied by firmware before mapping the full table.

A malformed table can overflow the 32-bit size addition or advertise an extent beyond the resource, causing the driver to map and parse memory outside the resource. A resource shorter than the fixed header is also mapped as though it contained a complete header.

Reject resources shorter than the fixed header. After validating the signature, require a complete header, calculate the advertised extent with overflow checking, and reject extents beyond the resource before remapping the table.

HID: synchronize input before cleaning up a failed probe

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

ublk: check importubuf() return value

importubuf() can fail if the address range (provided by the userspace ublk server) is outside the allowed user address space. Return that 0 bytes were copied if importubuf() fails rather than passing an uninitialized struct ioviter to ublkcopyuserpages().

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

ocfs2: validate inline xattrs during inode block validation

Patch series "ocfs2: validate xattr entry bounds", v7.

This series validates OCFS2 xattr entry name/value bounds when xattr metadata is read and validated, before getxattr() or listxattr() can walk out-of-range entry arrays or offsets from corrupted metadata.

This patch (of 2):

ocfs2validateinodeblock() verifies a dinode before OCFS2 users walk metadata from it, but inline xattr metadata is still checked only in operation-specific consumers. The existing ibody lookup helper validates inline header placement and entry count, but inode block validation does not reject entry name/value bounds.

Add a flat xattr entry validator and call it from inode block validation for inline xattrs. Keep the operation paths on their existing header/count lookup checks; the full entry bounds check now runs when the inode block is validated at read time.

Reject corrupted inline xattr metadata before ocfs2xattribodyget() or listxattr() can walk past the inline storage.

Validation reproduced this kernel report: BUG: KASAN: use-after-free in ocfs2xattrfindentry+0x5a/0x170 Read of size 2 at addr ffff8881242a2000 by task python3/529 Call Trace: dumpstacklvl+0x66/0xa0 printreport+0xce/0x630 kasanreport+0xe0/0x110 ocfs2xattrfindentry+0x5a/0x170 ocfs2xattrgetnolock+0x20a/0x820 ocfs2xattrget+0x10c/0x1e0 vfsgetxattr+0xe2/0x130 vfsgetxattr+0x185/0x1b0