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.

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).

bpf: Fix re-attachment branch in bpftracingprogattach

The following case can cause a crash due to missing attachbtf:

1) load rawtp program 2) load fentry program with rawtp as targetfd 3) create tracing link for fentry program with targetfd = 0 4) repeat 3

In the end we have:

- prog->aux->dsttrampoline == NULL - tgtprog == NULL (because we did not provide targetfd to linkcreate) - prog->aux->attachbtf == NULL (the program was loaded with attachprogfd=X) - the program was loaded for tgtprog but we have no way to find out which one

BUG: kernel NULL pointer dereference, address: 0000000000000058 Call Trace: <TASK> ? die+0x20/0x70 ? pagefaultoops+0x15b/0x430 ? fixupexception+0x22/0x330 ? excpagefault+0x6f/0x170 ? asmexcpagefault+0x22/0x30 ? bpftracingprogattach+0x279/0x560 ? btfobjid+0x5/0x10 bpftracingprogattach+0x439/0x560 sysbpf+0x1cf4/0x2de0 x64sysbpf+0x1c/0x30 dosyscall64+0x41/0xf0 entrySYSCALL64afterhwframe+0x6e/0x76

Return -EINVAL in this situation.

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.

A vulnerability was found in the tcp subsystem in the Linux Kernel, due to a data race around icsk->icskafops. This issue could allow an attacker to leak internal kernel information.

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.

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

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

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.

btrfs: free mapping node on duplicate reloc root insert

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/i915/gem: Add missing nospec on parallel submit slot

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.

An SSH misconfigurations exists in Tenable OT that led to the potential exfiltration of socket, port, and service information via the ostunnel user and GatewayPorts. This could be used to potentially glean information about the underlying system and give an attacker information that could be used to attempt to compromise the host.

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

Bluetooth: btintel: Validate length before parsing diagnostics TLV

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

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.

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

ACPI: CPPC: Suppress UBSAN warning caused by field misuse

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

ext4: fix use-after-free in ext4orphancleanup

I caught a issue as follows: ================================================================== BUG: KASAN: use-after-free in listaddvalid+0x28/0x1a0 Read of size 8 at addr ffff88814b13f378 by task mount/710

CPU: 1 PID: 710 Comm: mount Not tainted 6.1.0-rc3-next #370 Call Trace: <TASK> dumpstacklvl+0x73/0x9f printreport+0x25d/0x759 kasanreport+0xc0/0x120 asanload8+0x99/0x140 listaddvalid+0x28/0x1a0 ext4orphancleanup+0x564/0x9d0 [ext4] ext4fillsuper+0x48e2/0x5300 [ext4] ext4fillsuper+0x19f/0x3a0 [ext4] gettreebdev+0x27b/0x450 ext4gettree+0x19/0x30 [ext4] vfsgettree+0x49/0x150 pathmount+0xaae/0x1350 domount+0xe2/0x110 x64sysmount+0xf0/0x190 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x63/0xcd </TASK> [...] ==================================================================

Above issue may happen as follows: ------------------------------------- ext4fillsuper ext4orphancleanup --- loop1: assume lastorphan is 12 --- listadd(&EXT4I(inode)->iorphan, &EXT4SB(sb)->sorphan) ext4truncate --> return 0 ext4inodeattachjinode --> return -ENOMEM iput(inode) --> free inode<12> --- loop2: lastorphan is still 12 --- listadd(&EXT4I(inode)->iorphan, &EXT4SB(sb)->sorphan); // use inode<12> and trigger UAF

To solve this issue, we need to propagate the return value of ext4inodeattachjinode() appropriately.

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

wifi: mac80211: don't use rate mask for offchannel TX either

Like the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask for scanning"), ignore incorrect settings to avoid no supported rate warning reported by syzbot.

The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211: fix default HE tx bitrate mask in 2G band"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL.

As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well.

[1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024

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

lib/buildid: use kernelread() for sleepable context

Prevent a "BUG: unable to handle kernel NULL pointer dereference in filemapreadfolio".

For the sleepable context, convert freader to use kernelread() instead of direct page cache access via readcachefolio(). This simplifies the faultable code path by using the standard kernel file reading interface which handles all the complexity of reading file data.

At the moment we are not changing the code for non-sleepable context which uses filemapgetfolio() and only succeeds if the target folios are already in memory and up-to-date. The reason is to keep the patch simple and easier to backport to stable kernels.

Syzbot repro does not crash the kernel anymore and the selftests run successfully.

In the follow up we will make kernelread() with IOCBNOWAIT work for non-sleepable contexts. In addition, I would like to replace the secretmem check with a more generic approach and will add fstest for the buildid code.

Chromium: CVE-2026-7351 Race in MHTML

Chromium: CVE-2026-7360 Insufficient validation of untrusted input in Compositing

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

net: fix memory leak in skbsegmentlist for GRO packets

When skbsegmentlist() is called during packet forwarding, it handles packets that were aggregated by the GRO engine.

Historically, the segmentation logic in skbsegmentlist assumes that individual segments are split from a parent SKB and may need to carry their own socket memory accounting. Accordingly, the code transfers truesize from the parent to the newly created segments.

Prior to commit ed4cccef64c1 ("gro: fix ownership transfer"), this truesize subtraction in skbsegmentlist() was valid because fragments still carry a reference to the original socket.

However, commit ed4cccef64c1 ("gro: fix ownership transfer") changed this behavior by ensuring that fraglist entries are explicitly orphaned (skb->sk = NULL) to prevent illegal orphaning later in the stack. This change meant that the entire socket memory charge remained with the head SKB, but the corresponding accounting logic in skbsegmentlist() was never updated.

As a result, the current code unconditionally adds each fragment's truesize to deltatruesize and subtracts it from the parent SKB. Since the fragments are no longer charged to the socket, this subtraction results in an effective under-count of memory when the head is freed. This causes skwmemalloc to remain non-zero, preventing socket destruction and leading to a persistent memory leak.

The leak can be observed via KMEMLEAK when tearing down the networking environment:

unreferenced object 0xffff8881e6eb9100 (size 2048): comm "ping", pid 6720, jiffies 4295492526 backtrace: kmemcacheallocnoprof+0x5c6/0x800 skprotalloc+0x5b/0x220 skalloc+0x35/0xa00 inet6create.part.0+0x303/0x10d0 sockcreate+0x248/0x640 syssocket+0x11b/0x1d0

Since skbsegmentlist() is exclusively used for SKBGSOFRAGLIST packets constructed by GRO, the truesize adjustment is removed.

The call to skbreleaseheadstate() must be preserved. As documented in commit cf673ed0e057 ("net: fix fraglist segmentation reference count leak"), it is still required to correctly drop references to SKB extensions that may be overwritten during copyskbheader().

Chromium: CVE-2026-9944 Uninitialized Use in ANGLE