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

Input: synaptics-rmi4 - fix F55 transmitter electrode count typo

During F55 sensor detection, the transmitter (TX) electrode count was incorrectly assigned the value of the receiver (RX) electrode count due to copy-paste typos.

This incorrect value was then propagated to the driver data and used by F54 to determine the diagnostics report size. On devices with more RX than TX electrodes, this inflated the perceived TX count, leading to incorrect report size calculations and potential out-of-bounds buffer accesses.

Fix the typos by correctly assigning the TX electrode counts.

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

ovpn: run deferred work on a module-owned workqueue

ovpn queues several work items whose callbacks execute module text. These works currently run on the global system workqueues, so module exit has no driver-owned drain point that guarantees the callbacks have fully returned before the module text can be freed.

Object references protect the objects used by the callbacks, but they do not prove that a workqueue function has returned. In particular, a worker can drop the final reference that unblocks device teardown while it is still executing ovpn code.

Add a module-owned workqueue and queue all ovpn work items on it. During module exit, unregister rtnl and netlink first, flush the workqueue so ordinary ovpn workers finish, run the final RCU barrier, and destroy the workqueue last. This keeps the workqueue available for cleanup work queued from RCU callbacks, while ensuring no ovpn work item can outlive the module text.

The per-device delayed keepalive work remains explicitly disabled during netdev teardown (disabledelayedworksync in ndouninit), since flushworkqueue does not flush delayed work that is still only pending on its timer.

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

drm/connector/hdmi: Fix out of bounds memory read

A helper function was copying a given audio infoframe into the connector's copy but using the size of the destination (a generic target, sized to accept many different data blocks) not the source (a very specific type of data block). Thus, it was copying 60 bytes of data from a 28 byte allocation.

Fix that by using the source size instead, together with a build bug on the source size actually being smaller than the destination.

I hit this running KUnit tests under KASAN (while debugging something else entirely). In the real world, it seems unlikely to cause an actual problem. It is a read not a write so it can't corrupt any memory. However, it could potentially fall off the end of a page and cause an accvio bug.

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

mmc: loongson2: Fix sg iteration in data reorder functions

In ls2k0500mmcreordercmddata() and ls2k2000mmcreordercmddata(), the foreachsg() macro already iterates over the scatterlist entries, with 'sg' pointing to the current entry. However, the code incorrectly uses '&sg[i]' and 'sgdmalen(&sg[i])' inside the loop, which treats 'sg' as an array base and indexes it again, leading to access of wrong sg entries (or out-of-bounds if the list is not an array).

drm/amdkfd: Add bounds check for CRAT subtype length

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

serial: amba-pl011: synchronize DMA teardown

dmaengineterminateall() does not wait for a running callback, so the TX callback can still touch the TX buffer after it is freed. The RX poll timer reads the RX buffers without the port lock.

Switch to dmaengineterminatesync() and delete the RX timer before freeing the buffers.

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

thunderbolt: Fix bandwidth group reservation indexing

Valid bandwidth group IDs range from 1 through MAXGROUPS, while Group ID 0 is reserved. tbconsumeddpbandwidth() uses the Group ID directly to index its local groupreserved[] array.

The array currently has MAXGROUPS entries, so its valid indices are 0 through MAXGROUPS - 1. Group ID MAXGROUPS therefore accesses one element past the end, and the final group's reserved bandwidth is not included when the array is summed.

Give groupreserved[] MAXGROUPS + 1 entries so direct Group ID indexing covers the reserved ID 0 and valid IDs 1 through MAXGROUPS.

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

of: reservedmem: prevent OOB when too many dynamic regions are defined

On boot, fdtscanreservedmem() saves each dynamically-placed /reserved-memory subnode into a local array of size MAXRESERVEDREGIONS.

If the device tree defines more than MAXRESERVEDREGIONS dynamically-placed regions, fdtscanreservedmem() writes past the end of the local array.

Add a bounds check that logs an error and skips the excess regions, restoring the original behavior.

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

Bluetooth: ISO: ensure no dangling hcon references in isoconn

After isoconndel(), ISO sockets should not dereference the hcon any more. Currently, clearing isoconn::hcon relies on isoconndel() releasing the last reference to the isoconn.

Simplify this by explicitly clearing conn->hcon in isoconndel(), to avoid more complex reasoning on races about who holds the last reference.

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

spi: spi-qpic-snand: write the feature value before executing SETFEATURE

qcomspisendcmdaddr() programs NANDFLASHCMD/NANDEXECCMD and submits the descriptors, which makes the controller execute the command immediately. For SPINANDSETFEATURE the value to be written is only placed into NANDFLASHFEATURES afterwards, by qcomspiioop(), in a second submission - so the chip is programmed with whatever that register happened to hold from a previous operation, and the intended value is only applied by the next SETFEATURE.

Measured on a TP-Link Archer AX55 v1 (IPQ5018, ESMT F50L1G41LB): writing 0x40 to the configuration register (0xb0) leaves the chip at 0x00, and the subsequent write of 0x00 leaves it at 0x40 - every write lands one operation late.

This stayed unnoticed until v6.18 added SPI-NAND OTP support together with OTP entries for ESMT chips. spinandotprw() enables OTP mode, reads, and disables it again, and mtdotpnvmemadd() does this during MTD registration. With the off-by-one, the "disable" write actually applies the previously requested value, so CFGOTPENABLE ends up set: the chip stays in OTP mode, every subsequent array read returns the OTP area instead of the array (UBI reports an empty device) and all writes fail with -EIO because the OTP area is write protected. On this board that makes the whole flash unusable and the device unbootable.

Write the feature value into NANDFLASHFEATURES as part of the same transaction, before NANDEXECCMD. While at it, copy only the bytes the operation actually carries - the previous code dereferenced a 4-byte pointer on a one-byte buffer (spinand->scratchbuf).

With this patch the flash contents read back bit-identical to a known-good dump of the same board taken under the vendor firmware (md5-verified across partitions), and writes work.

can: j1939: transport: j1939sessionfreshnew(): initialize receive buffer

drm/vmwgfx: fix guestmemorydirty bitfield clobbered as size

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

hwmon: (ltc4282) Fix reading the minimum alarm voltage

Coverity reports an out-of-bounds access when reading the minimum alarm voltage for the VGPIO channel. Add the missing return statement to fix the problem.

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

Bluetooth: SCO: give the socket its own scoconn reference

scoconndel() drops a reference it does not own. It takes one transient reference via scoconnholdunlesszero() and releases it with the scoconnput() that follows scosockhold(); the additional put in the !sk branch releases a second one:

conn = scoconnholdunlesszero(conn); ... sk = scosockhold(conn); scoconnunlock(conn); scoconnput(conn);

if (!sk) { scoconnput(conn); return; }

When close() races the controller's Disconnection Complete, scochandel() clears conn->sk and drops the socket's reference while scoconndel() is running. scoconndel() then sees sk == NULL, its own put drops the count to zero and frees the conn, and the second put writes to the freed kref:

BUG: KASAN: slab-use-after-free in scoconnput.part.0+0x1a/0x190 Write of size 4 at addr ffff8881099dec74 by task kworker/u17:3/413 Workqueue: hci1 hcirxwork Call Trace: scoconnput.part.0+0x1a/0x190 hcidisconncompleteevt+0x1ee/0x3e0 hcieventpacket+0x54a/0x650 hcirxwork+0x321/0x3d0 Allocated by task 413: scoconnadd+0x72/0x1a0 scoconnectcfm+0x88/0x670 Freed by task 413: scoconndel.isra.0+0x3f/0xf0 hcidisconncompleteevt+0x1ee/0x3e0 refcountt: underflow; use-after-free.

The root cause is that the socket stores the connection without holding a reference of its own. scochanadd() does:

scopi(sk)->conn = conn;

so the socket borrows whatever reference its caller happened to hold, and the callers paper over that with ad-hoc holds and puts. Give the socket a counted reference instead: scochanadd() takes one and it is released together with the channel (scochandel()) and in scosockdestruct(). With the socket holding its own reference, scoconndel() no longer needs the extra put and the redundant hold in scoconnready() goes away.

Making the socket own its reference means the connection is now actually freed on the error paths of scoconnect() where it used to leak, which in turn runs scoconnfree() and its hciconndrop(conn->hcon). To keep the hciconn accounting balanced, make that ownership explicit as well: scoconnadd() consumes one hciconn reference and the scoconn owns it for its lifetime. scoconnect() hands over the reference returned by hciconnectsco() and no longer drops it on the error paths; scoconnectcfm(), which is not given a reference, takes one with hciconnhold() before handing it to scoconnadd() (and drops it again if the allocation fails); and the explicit hciconnhold() in scoconnready() is removed. Every reference then has a single, clear owner.

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

libbpf: Reject non-exclusive metadata maps in the signed loader

The loader verifies map->sha against the metadata hash in its instructions. map->sha is calculated when BPFOBJGETINFOBYFD is called on the frozen map.

While the map is frozen, the /signed loader/ must also ensure the map is exclusive, as, without exclusivity (which a hostile host could just omit when loading the loader), another BPF program with map access can mutate the contents afterwards, so the check passes on stale data.

With the extra check as part of the signed loader, it now refuses to move on with map->sha validation if the host set it up wrongly.

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

tools/power/x86/intel-speed-select: Harden daemon pidfile open

Avoid symlink-based pidfile clobbering by opening the pidfile with ONOFOLLOW and validating it with fstat() before locking/writing.

The daemon currently uses a fixed pidfile path under /tmp. A local unprivileged user can pre-create a symlink at that path and cause a root-run daemon instance to write into an attacker-chosen file.

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

cxl: Fix CXLHEADERLOGSIZE to match RAS Capability size

The CXL r4.0 8.2.4.17.7 RAS Capability Structure has total length 0x58 bytes (CXLRASCAPABILITYLENGTH); the Header Log occupies the trailing 64 bytes at offset 0x18. CXLHEADERLOGSIZE was defined as SZ512, eight times the actual on-device size.

headerlogcopy() reads CXLHEADERLOGSIZEU32 (128) dwords from the RAS capability iomap, overrunning the 88-byte mapping by 448 bytes. The cxlaeruncorrectableerror trace event memcpy()s CXLHEADERLOGSIZE (512) bytes from its source. For the CPER caller the source is struct cxlrascapabilityregs::headerlog[16] (64 bytes) embedded in a stack-local cxlcperproterrworkdata, so the memcpy reads 448 bytes of kernel stack into the trace event ring buffer where userspace can read it via tracefs.

Set CXLHEADERLOGSIZE to 64 and derive CXLHEADERLOGSIZEU32 from it, bringing all iomap readers into agreement on 16 dwords. Userspace tools such as rasdaemon have grown a dependency on the buggy 512-byte (128 u32) headerlog layout in the cxlaeruncorrectableerror trace event. Add CXLHEADERLOGTRACESIZEU32 = 128 and use it for the trace event array and its memcpy to preserve that ABI. Both callers now pass a zero-filled u32[CXLHEADERLOGTRACESIZEU32] staging buffer with only the first CXLHEADERLOGSIZEU32 (16) entries populated from hardware; the remaining 112 u32s are zero-padded, keeping the 512-byte trace ring buffer layout intact.

[ dj: Replaced 64 with SZ64 per RichardC ]

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

ufs: core: tracing: Do not dereference pointers in TPprintk()

The trace events in drivers/ufs/core/ufstrace.h were converted to take a pointer to the hba structure as an argument for the tracepoint and then in TPprintk() the printing of the devname from the ring buffer was converted to using the dev dereferenced pointer from the hba saved pointer.

This is not allowed as the TPprintk() is executed at the time the trace event is read from /sys/kernel/tracing/trace file. That can happen literally, seconds, minutes, hours, weeks, days, or even months later! There is no guarantee that the hba pointer will still exist by the time it is dereferenced when the "trace" file is read.

Instead, save the device name from the hba pointer at the time the tracepoint is called and place it into the ring buffer event. Then the TPprintk() can read the name directly from the ring buffer and remove the possibility that it will read a freed pointer and crash the kernel.

This was detected when testing the trace event code that looks for TPprintk() parameters doing illegal derferences[1]

[1] https://lore.kernel.org/all/20260630184836.74d477b6@gandalf.local.home/

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

scsi: hisisas: Add slavedestroy interface for v3 hw

WARNING is triggered when executing link reset of remote PHY and rmmod SAS driver simultaneously. Following is the WARNING log:

WARNING: CPU: 61 PID: 21818 at drivers/base/core.c:1347 devicelinksnodriver+0xb4/0xc0 Call trace: devicelinksnodriver+0xb4/0xc0 devicelinksdrivercleanup+0xb0/0xfc devicereleasedriver+0x198/0x23c devicereleasedriver+0x38/0x50 busremovedevice+0x130/0x140 devicedel+0x184/0x434 scsiremovedevice+0x118/0x150 scsiremovetarget+0x1bc/0x240 sasrphyremove+0x90/0x94 sasrphydelete+0x24/0x3c sasdestructdevices+0x64/0xa0 [libsas] sasrevalidatedomain+0xe4/0x150 [libsas] processonework+0x1e0/0x46c workerthread+0x15c/0x464 kthread+0x160/0x170 retfromfork+0x10/0x20 ---[ end trace 71e059eb58f85d4a ]---

During SAS phy up, link->status is set to DLSTATEAVAILABLE in devicelinksdriverbound, then this setting influences devicelinksnodriver() before driver rmmod and caused WARNING.

Add the slavedestroy interface to make sure link is removed after flush workque.

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

ipv6: guard against possible NULL deref in in6devstatsget()

devgetbyindexrcu() could return NULL if the original physical device is unregistered.

Found by Sashiko.

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

rapidio/tsi721: prevent a bad dereference in tsi721dbdpc()

With a listforeach() loop, if we don't find the item we are looking for in the list, then the loop exits with the iterator, which is "dbell" in this loop, pointing to invalid memory.

This code uses the "found" variable to determine if we have found the doorbell we are looking for or not. However, the problem that the "found" variable needs to be set to false at the start of each iteration, otherwise after the first correct doorbell, then everything is marked as found.

Reset the "found" to false at the start of the iteration and move the variable inside the loop.

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

ocfs2: fix out-of-bounds write in ocfs2removerefcountextent

[BUG] Unlinking a refcounted file whose refcount tree has leaf blocks triggers a fortify panic due to an out-of-bounds write.

[CAUSE] When the last leaf block is removed from a refcount tree, ocfs2removerefcountextent() converts the root back to leaf mode with a bulk memset on &rb->rfrecords. rfrecords sits in an anonymous union with rflist. rflist.ltreedepth aliases rfrecords.rlcount, and is 0 for a single-level tree. With rlcount equal to 0, the memset writes past the 16-byte declared size of rfrecords, which the fortify checker catches.

[FIX] Replace the bulk memset on &rb->rfrecords with a correctly-bounded memset on rlrecs[] alone, after setting rlcount to the correct value.

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

ALSA: seq: oss: Serialize readq reset state with q->lock

sndseqossreadqclear() resets qlen, head, and tail without q->lock even though the normal reader and producer paths serialize the same ring state under that spinlock. A reset can therefore race sndseqossreadqfree() or sndseqossreadqputevent() and leave stale records in the queue, drop freshly queued ones, or report the wrong readiness after wakeup. KCSAN reports a data race between sndseqossreadqclear() and sndseqossreadqfree().

Take q->lock while clearing the ring and resetting inputtime. Factor the enqueue logic into a caller-locked helper so sndseqossreadqputtimestamp() updates its suppression state under the same lock instead of racing the reset path.

The buggy scenario involves two paths, with each column showing the order within that path:

reset path: locked readq updater: 1. sndseqossreset() or 1. A reader or callback producer release reaches takes q->lock on the same queue. sndseqossreadqclear(). 2. sndseqossreadqclear() 2. The updater tests or modifies resets qlen, head, tail, qlen, head, and tail. and inputtime. 3. sndseqossreadqclear() 3. The updater completes its wakes sleepers on read-modify-write sequence. q->midisleep. 4. Without q->lock, the reset 4. The resulting ring state drives can overlap the locked later reads and readiness. update.

KCSAN reports:

BUG: KCSAN: data-race in sndseqossreadqclear / sndseqossreadqfree

write to 0xffff8881069fe608 of 4 bytes by task 120516 on cpu 0: sndseqossreadqfree+0x6c/0x80 sndseqossread+0xcb/0x250 odevread+0x38/0x60 vfsread+0xff/0x600 ksysread+0xb4/0x140 x64sysread+0x46/0x60 dosyscall64+0xbb/0x2f0 entrySYSCALL64afterhwframe+0x77/0x7f

read to 0xffff8881069fe608 of 4 bytes by task 120517 on cpu 1: sndseqossreadqclear+0x1f/0x90 sndseqossreset+0xa7/0xf0 sndseqossioctl+0x6f6/0x7e0 odevioctl+0x56/0xc0 x64sysioctl+0xd1/0x120 dosyscall64+0xbb/0x2f0 entrySYSCALL64afterhwframe+0x77/0x7f

value changed: 0x00000001 -> 0x00000000

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

char: tlclk: fix use-after-free in tlclkcleanup()

This patch improves the module cleanup process in the tlclk driver to prevent potential use-after-free and race conditions.

Currently, the fileoperations structure does not specify the .owner field, which could allow the module to be unloaded while user-space processes are still interacting with the device. Additionally, the tlclkcleanup() function frees the alarmevents memory before ensuring that blocked processes in the waitqueue are fully awakened and that the switchovertimer has completed.

To address these cases, this patch: - Sets '.owner = THISMODULE' in tlclkfops to safely defer module unloading while the device is in use. - Updates tlclkcleanup() to explicitly wake up all blocked readers (wakeupall), properly release hardware I/O regions, and safely delete the timer (timerdeletesync) prior to freeing memory.

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

net: dstmetadata: fix false-positive memcpy overflow in tundstunclone

kmallocflex() in metadatadstalloc() sets countedby for the structure to the optionslen, which is then initialized to zero. Later, we're initializing the structure by copying the tunnel info together with the options, and this triggers a warning for a potential memcpy overflow, since the compiler estimates that the options can't fit into the structure, even though the memory for them is actually allocated.

memcpy: detected buffer overflow: 104 byte write of buffer size 96 WARNING: CPU: X PID: Y at lib/stringhelpers.c:1036 fortifyreport skbtunnelinfounclone+0x179/0x190 genevexmit+0x7fe/0xe00

The issue is triggered when built with clang and source fortification.

Fix that by doing the copy in two stages: first - the main data with the optionslen, then the options. This way the correct length should be known at the time of the copy.

It would be better if the optionslen never changed after allocation, but the allocation code is a little separate from the initialization and it would be awkward and potentially dangerous to return a struct with optionslen set to a non-zero value from the metadatadstalloc().

Another option would be to use iptunnelinfooptsset(), but it is doing too many unnecessary operations for the use case here.

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

veth: fix NAPI leak in XDP enable error path

During XDP enablement in veth, if xdprxqinforeg() or xdprxqinforegmemmodel() fails, the driver rolls back the changes.

However, the rollback loop: for (i--; i >= start; i--) {

decrements the loop index 'i' before the first iteration. This correctly skips unregistering the rxq for the failed index 'i' (as registration failed or was already cleaned up), but it also erroneously skips calling netifnapideli() for rq[i].xdpnapi.

Since netifnapiadd() was already called for index 'i', this leaves a dangling napistruct in the device's napilist. When the veth device is later destroyed, the freed queue memory (which contains the leaked NAPI structure) can be reused.

The subsequent device teardown iterates the NAPI list and corrupts the reallocated memory, leading to UAF.

Fix this by explicitly deleting the NAPI association for the failed index 'i' before rolling back the successfully configured queues.

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

net: emac: Fix NULL pointer dereference in emacprobe

Move devmrequestirq() after devmplatformioremapresource() so that dev->emacp is mapped before the interrupt handler can fire. An early interrupt hitting emacirq() would dereference the NULL dev->emacp and crash.

Also remove redundant error message. devmplatformioremapresource() already returns an error message with deverrprobe().

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

ntfs3: fix out-of-bounds read in decompresslznt

decompresslznt() does not validate array index bounds before accessing the decompression table. A corrupted NTFS3 image with invalid compressed data can trigger an out-of-bounds read.

Add index bounds checking to prevent the OOB access.

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

f2fs: fix listxattr handling of corrupted xattr entries

Validate the xattr entry before reading its fields in f2fslistxattr(). Return -EFSCORRUPTED when the entry is outside the valid xattr storage area instead of returning a successful partial result.

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

drm/shmemhelper: Check VMA boundaries for PMD mappings

In the ->hugefault handler do not install a PMD huge page mapping if the huge page exceeds the boundaries of the VMA.

All other ->hugefault handlers have similar checks and the resulting mapping will trigger a VMBUGONVMA() if it ever reaches copypmdrange().