The I3C IBI subsystem in drivers/i3c/i3cibiworkq.c hands out statically-allocated work nodes through a free-list i3cibiworknodesfree implemented as a plain sysslistt, which provides no synchronization. The allocation helpers (i3cibiworkenqueue, i3cibiworkenqueuetargetirq, i3cibiworkenqueuehotjoin, i3cibiworkenqueuecontrollerrequest, i3cibiworkenqueuecb) called sysslistget() directly from ISR context, while the workqueue handler i3cibiworkhandler() returned nodes with sysslistappend() from the workqueue thread, with no lock on either side.

Because sysslistget() and sysslistappend() are neither atomic nor interrupt-safe, an IBI interrupt that fires while the workqueue thread is mid-append (or a truly parallel access under CONFIGSMP) races on the shared list. This corrupts the list linkage: a node may be handed to two consumers, a node may be lost, or the head/tail pointers may be left inconsistent so sysslistget() returns a stale or garbage pointer. In the double-hand-out case the subsequent memcpy(ibinode, ibiwork, sizeof(ibinode)) overwrites a node still in flight; a garbage pointer turns the same memcpy into an out-of-bounds write.

The race is driven by I3C bus traffic — IBIs, hot-joins, and controller-role requests originate from target devices on the bus, and I3C supports hot-joining devices. An attacker controlling an I3C peripheral on the board's chip-to-chip bus can generate high-frequency interrupts timed to collide with the free operation. Exploitation requires physical access to the bus and winning a narrow timing window; the most realistic impact is a crash or hang (denial of service), with memory corruption possible but hard to control.

The fix wraps all free-list sysslistget()/sysslistappend() operations in the new ibiworkalloc()/ibiworkfree() helpers, each guarded by a kspinlock (ibiworklock), closing the race across ISR and thread contexts.

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

net/smc: fix qentry overwrite for CONFIRMLINK and ADDLINKCONT in smcllceventhandler()

The SMCLLCCONFIRMLINK / SMCLLCADDLINKCONT branch in smcllceventhandler() stores an incoming qentry into the local LLC flow without first checking whether a qentry is already pending. If a malicious or buggy peer sends a second CONFIRMLINK or ADDLINKCONT request while a flow is active and flow->qentry is already set, smcllcflowqentryset() overwrites the pointer without freeing the previous allocation, leaking one kmalloc-96 object per spurious message.

The sibling SMCLLCDELETELINK branch already has the correct !flow->qentry guard. Apply the same guard to the CONFIRMLINK/ADDLINKCONT branch so that a duplicate message when qentry is already occupied falls through to break and is freed by the kfree(qentry) at the out: label, rather than silently leaking the existing allocation.

The response direction (smcllcrxresponse()) is unaffected: it already guards with flow->qentry at the equivalent site and drops duplicate responses correctly.

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

vt: add permission check for KDSKBMETA ioctl

KDSKBMETA modifies keyboard meta mode but lacks the !perm check that all other keyboard setter ioctls in vtkioctl() enforce, allowing a process to change meta mode on a non-controlling console without authorization.

ima: fix out-of-bounds read in xattrverify()

When auditing a system call executed via ptrace(PTSCREMOTE), the kernel passed the return value of an internal setup function to AUDITSYSCALLEXIT() rather than the actual result of the executed system call. As a result, committed audit records for system calls which returned an error do not reflect the true outcome of the operation. That is, they indicate that the operation succeeded when it in fact failed.

Audit records for system calls executed via ptrace(PTSCREMOTE) may show an incorrect error status. An attacker with the ability to debug a process could use this to produce misleading audit trails, potentially undermining audit-based Intrusion Detection Systems (IDS).

Bluetooth: btintel: Validate length before parsing diagnostics TLV

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

net: openvswitch: fix skb leak on flow key update failure during ct

ovsctexecute() always steals or frees the skb on failure while ovsflowkeyupdate() does not. So, if it fails and we return right away, the skb ends up leaked.

Fix that by breaking instead and letting the common error handling code at the bottom of the loop to free the skb properly.

This is a very unlikely scenario as it requires the packet to become unparseable by applying a set of actions on a previously parseable skb, but should be fixed nevertheless.

Reported by Sashiko.

drm/amdkfd: fix QID bit leak in pqmcreatequeue()

btrfs: free mapping node on duplicate reloc root insert

drm/dpmst: Handle torn-down topology gracefully in drmdpmsttopologyqueueprobe()

btrfs: fix root leak if its reloc root is unexpected in mergerelocroots()

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

wifi: ath9k: hifusb: don't dereference hifdev after re-arming firmware request

ath9khifrequestfirmware() re-arms an asynchronous firmware load via requestfirmwarenowait(), passing hifdev as the completion context, and then still dereferences hifdev:

devinfo(&hifdev->udev->dev, "ath9khtc: Firmware %s requested\n", hifdev->fwname);

The re-armed callback ath9khifusbfirmwarecb() runs on the "events" workqueue and, when the firmware is missing, walks the retry chain into ath9khifusbfirmwarefail() -> completeall(&hifdev->fwdone). That releases the waitforcompletion(&hifdev->fwdone) in a concurrent ath9khifusbdisconnect(), which then kfree()s hifdev. The trailing devinfo() in the frame that re-armed the request can therefore read freed memory (hifdev->udev, the first field of struct hifdeviceusb):

BUG: KASAN: slab-use-after-free in ath9khifrequestfirmware Read of size 8 ... by task kworker/... ath9khifrequestfirmware ath9khifusbfirmwarecb drivers/net/wireless/ath/ath9k/hifusb.c:1247 requestfirmwareworkfunc Allocated by ...: ath9khifusbprobe drivers/net/wireless/ath/ath9k/hifusb.c Freed by ...: ath9khifusbdisconnect -> kfree drivers/net/wireless/ath/ath9k/hifusb.c

The fwdone barrier only makes disconnect wait for the firmware chain to terminate; it does not protect the outer ath9khifrequestfirmware() frame that re-armed the request and keeps touching hifdev afterwards.

Drop the post-request devinfo(): it is the only use of hifdev after the async request is armed, and it is purely informational (the deverr() on the failure path runs only when requestfirmwarenowait() did not arm a callback, so hifdev is still alive there).

This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9khtc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.

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

net: hsr: fix memory leak on slave unregistration by removing synced VLANs

When an HSR master device is brought UP, it auto-adds VLAN 0 via vlanvid0add(), which propagates VID 0 to its slave devices (slave A and B).

If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsrdelport() is called to detach the slave port from the HSR master. However, hsrdelport() currently does not delete the VLAN IDs that were synced to the slave device by HSR.

As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlaninfo / vlanvidinfo structure remains allocated, leading to a memory leak.

Fix this by calling vlanvidsdelbydev(port->dev, master->dev) in hsrdelport() before unlinking slave A or slave B ports, matching the propagation logic in hsrndovlanrxaddvid() / hsrndovlanrxkillvid() and the cleanup behavior in bonding and team drivers.

drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers

drm/i915/gem: Add missing nospec on parallel submit slot

drm/amd/display: detectlinkandlocalsink: DP alt mode timeout path leaks prevsink reference

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

media: nxp: imx8-isi: Add missing v4l2subdevcleanup() in crossbar and pipe

Both mxcisicrossbarinit() and mxcisipipeinit() call v4l2subdevinitfinalize() which allocates the subdev active state, but neither mxcisicrossbarcleanup() nor mxcisipipecleanup() calls v4l2subdevcleanup() to free it.

This causes a memory leak on every rmmod, reported by kmemleak:

unreferenced object 0xffff0000d06fc800 (size 192): comm "(udev-worker)", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleakalloc+0x34/0x40 kvmallocnodenoprof+0x5f8/0x7d8 v4l2subdevstatealloc+0x1fc/0x30c v4l2subdevinitfinalize+0x178/0x368

Add the missing v4l2subdevcleanup() calls before mediaentitycleanup() in both crossbar and pipe cleanup paths.

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

wifi: p54: validate RX frame length in p54rxeepromreadback()

p54rxeepromreadback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 ("wifi: p54: prevent buffer-overflow in p54rxeepromreadback()") closed the destination overflow by copying a fixed priv->eepromslicesize (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes.

A malicious USB device can send a short frame whose advertised len matches priv->eepromslicesize while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap:

BUG: KASAN: slab-out-of-bounds in p54rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: <IRQ> ... asanmemcpy (mm/kasan/shadow.c:105) p54rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54urxcb (drivers/net/wireless/intersil/p54/p54usb.c:163) usbhcdgivebackurb (drivers/usb/core/hcd.c:1657) dummytimer (drivers/usb/gadget/udc/dummyhcd.c:2005) ... </IRQ>

The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuffsmallhead of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380)

Check that the slice fits in the skb before copying.

Bluetooth: bpa10x: avoid OOB read of revision string in bpa10xsetup()

ACPI: CPPC: Suppress UBSAN warning caused by field misuse

Chromium: CVE-2026-11690 Out of bounds read and write in Media

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

landlock: Fix LOGSUBDOMAINSOFF inheritance across fork()

hookcredtransfer() only copies the Landlock security blob when the source credential has a domain. This is inconsistent with landlockrestrictself() which can set LOGSUBDOMAINSOFF on a credential without creating a domain (via the rulesetfd=-1 path): the field is committed but not preserved across fork() because the child's preparecreds() calls hookcredtransfer() which skips the copy when domain is NULL.

This breaks the documented use case where a process mutes subdomain logs before forking sandboxed children: the children lose the muting and their domains produce unexpected audit records.

Fix this by unconditionally copying the Landlock credential blob.

Chromium: CVE-2026-11674 Use after free in Guest View

Chromium: CVE-2026-11683 Use after free in WebCodecs

Chromium: CVE-2026-12458 Incorrect security UI in Passwords

Chromium: CVE-2026-12017 Insufficient validation of untrusted input  Extensions

Chromium: CVE-2026-13945 Insufficient policy enforcement in Extensions

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

crypto: afalg - limit RX SG extraction by receive buffer budget

Make afalggetrsgl() limit each RX scatterlist extraction to the remaining receive buffer budget.

afalggetrsgl() currently uses afalgreadable() only as a gate before extracting data into the RX scatterlist. Limit each extraction to the remaining afalgrcvbuf(sk) budget so that receive-side accounting matches the amount of data attached to the request.

If skcipher cannot obtain enough RX space for at least one chunk while more data remains to be processed, reject the recvmsg call instead of rounding the request length down to zero.

Chromium: CVE-2026-9944 Uninitialized Use in ANGLE

Chromium: CVE-2026-6312 Insufficient policy enforcement in Passwords