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.

btrfs: fix the possible bioclist memory leak during error

btrfs: do not force reloc root creation during qgroupaccountsnapshot()

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

ASoC: Intel: avs: Fix unbalanced module reference count

straceopen() invokes trymoduleget() which on success takes the module reference. If any follow up operation causes straceopen() to fail, the refcount shall be put down.

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

net: bcmasp: fix txspbringfull() checking same slot cnt times

The loop initialised nextindex from intf->txspbindex on every iteration, so incrring() always produced the same result and only one slot was ever tested. Move the initialisation before the loop so each iteration advances nextindex and the function correctly checks that cnt consecutive descriptor slots are available before allowing a new transmission.

gpio: eic-sprd: use rawspinlockt in the irq startup path

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

mm/shrinker: do not hold RCU lock in shrinkerdebugfscountshow()

Reading the debugfs "count" file of a memcg-aware shrinker can sleep inside an RCU read-side critical section:

BUG: sleeping function called from invalid context at kernel/cgroup/rstat.c:421 RCU nest depth: 1, expected: 0 cssrstatflush memcgroupflushstats zswapshrinkercount shrinkerdebugfscountshow

shrinkerdebugfscountshow() invokes the ->countobjects() callback under rcureadlock(). The zswap callback flushes memcg stats via cssrstatflush(), which may sleep, so it must not run under RCU.

The RCU lock is not needed here. memcgroupiter() takes RCU internally and returns a memcg holding a css reference (dropped on the next iteration or by memcgroupiterbreak()), so the memcg stays alive without it. The shrinker is kept alive by the open debugfs file: shrinkerfree() removes the debugfs entries via debugfsremoverecursive(), which waits for in-flight readers to drain, before callrcu(..., shrinkerfreercucb). The sibling "scan" handler already invokes the sleeping ->scanobjects() callback with no RCU section.

Drop the rcureadlock()/rcureadunlock().

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

mm: shrinker: fix NULL pointer dereference in debugfs

shrinkerdebugfsadd() creates both "count" and "scan" debugfs files unconditionally.

That assumes every shrinker implements both countobjects() and scanobjects(), which is not guaranteed. For example, the xen-backend shrinker sets countobjects() but leaves scanobjects() NULL, so writing to its scan file calls through a NULL function pointer and panics the kernel:

BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. Call Trace: <TASK> shrinkerdebugfsscanwrite+0x12e/0x270 fullproxywrite+0x5f/0x90 vfswrite+0xde/0x420 ? filpflush+0x75/0x90 ? filpclose+0x1d/0x30 ? dodup2+0xb8/0x120 ksyswrite+0x68/0xf0 ? filpflush+0x75/0x90 dosyscall64+0xb3/0x5b0 entrySYSCALL64afterhwframe+0x76/0x7e

The count path has the same issue in principle if a shrinker omits countobjects().

To fix it, only create "count" and "scan" debugfs files when the corresponding callbacks are present.

Bluetooth: btmtksdio: fix infinite loop in btmtksdiotxrxwork()

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

firmwareloader: fix device reference leak in firmwareuploadregister()

firmwareuploadregister() -> fwcreateinstance() -> deviceinitialize()

After fwcreateinstance() succeeds, the lifetime of the embedded struct device is expected to be managed through the device core reference counting, since fwcreateinstance() has already called deviceinitialize().

In firmwareuploadregister(), if alloclookupfwpriv() fails after fwcreateinstance() succeeds, the code reaches freefwsysfs and frees fwsysfs directly instead of releasing the device reference with putdevice(). This may leave the reference count of the embedded struct device unbalanced, resulting in a refcount leak.

The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix this by using putdevice(fwdev) in the failure path and letting fwdevrelease() handle the final cleanup, instead of freeing the instance directly from the error path.

cpufreq: Fix hotplug-suspend race during reboot

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

proc: protect ptracemayaccess() with execupdatelock (part 1)

Fix the easy cases where procfs currently calls ptracemayaccess() without execupdatelock protection, where the fix is to simply add the extra lock or use mmaccess():

- dotaskstat(): grab execupdatelock - procpidwchan(): grab execupdatelock - procmapfileslookup(): use mmaccess() instead of gettaskmm() - procmapfilesreaddir(): use mmaccess() instead of gettaskmm() - procnsgetlink(): grab execupdatelock - procnsreadlink(): grab execupdatelock

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

posix-cpu-timers: Fix pid refcount leak in docpunanosleep() error path

In docpunanosleep(), posixcputimercreate() takes a pid reference via getpid() and stores it in timer.it.cpu.pid. If the subsequent posixcputimerset() call fails, the function returns immediately without calling posixcputimerdel() to release the pid reference, causing a leak.

Fix it by calling posixcputimerdel() before the unlock-and-return on the error path, consistent with the other exit paths in the same function.

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

s390: Revert support for DCACHEWORDACCESS

loadunalignedzeropad() reads eight bytes from unaligned addresses and may cross page boundaries. It handles exceptions which may happen if reading from the second page results in an exception.

For pages which are donated to the Ultravisor for secure execution purposes the dosecurestorageaccess() exception handler however does not handle such exceptions correctly. Such an exception may result in an endless exception loop which will never be resolved.

An attempt to fix this [1] turned out to be not sufficient. For now revert loadunalignedzeropad() until this problem has been resolved in a proper way.

Note that the implementation of loadunalignedzeropad() itself is correct. The revert is just a temporary workaround until there is complete fix for secure storage access exceptions.

[1] commit b00be77302d7 ("s390/mm: Add missing secure storage access fixups for donated memory")

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

nilfs2: reject CLEANSEGMENTS ioctl with out-of-range segment numbers

Syzbot reported a hung task in nilfstransactionbegin() where multiple tasks performing chmod() on a nilfs2 mount blocked for over 143 seconds waiting to acquire nssegctorsem for read:

INFO: task syz.0.17:5918 blocked for more than 143 seconds. Call Trace: schedule+0x164/0x360 rwsemdownreadslowpath+0x6d9/0x940 downread+0x99/0x2e0 nilfstransactionbegin+0x364/0x710 fs/nilfs2/segment.c:221 nilfssetattr+0x124/0x2c0 fs/nilfs2/inode.c:921 notifychange+0xc1a/0xf40 chmodcommon+0x273/0x4a0 dofchmodat+0x12d/0x230

The writer holding nssegctorsem was a concurrent NILFSIOCTLCLEANSEGMENTS caller, stuck inside printk while emitting per-element warnings from nilfssufileupdatev():

nilfsmsg+0x373/0x450 fs/nilfs2/super.c:78 nilfssufileupdatev+0x21c/0x6d0 fs/nilfs2/sufile.c:186 nilfssufilefreev fs/nilfs2/sufile.h:93 [inline] nilfsfreesegments fs/nilfs2/segment.c:1140 [inline] nilfssegctorcollectblocks fs/nilfs2/segment.c:1261 [inline] nilfssegctordoconstruct+0x1f55/0x76c0 nilfscleansegments+0x3bd/0xa50 nilfsioctlcleansegments fs/nilfs2/ioctl.c:922 [inline] nilfsioctl+0x261f/0x2780

The root cause is that user-supplied segment numbers are not validated before nilfscleansegments() begins doing work; the range check on each segnum is performed deep inside the call chain by nilfssufileupdatev(), which emits a nilfswarn() per invalid entry while still holding the segctor lock and the sufile misem. Under load (repeated invocations across multiple mounts saturating the global printk path), the cumulative printk latency keeps nssegctorsem held long enough to trip the hungtask watchdog, blocking concurrent operations such as chmod() that need nssegctorsem for read.

Fix by validating the contents of kbufs[4] in nilfscleansegments() immediately after acquiring nssegctorsem via nilfstransactionlock(). Holding nssegctorsem serializes the check against nilfsioctlresize(), which can modify nsnsegments, so the validation uses a consistent value. Out-of-range segment numbers are rejected with -EINVAL before any segment-cleaning work begins, so the bad entries never reach the per-element diagnostic path inside nilfssufileupdatev().

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

usb: cdnsp: fix stream context array leak in cdnspallocstreaminfo()

cdnspallocstreaminfo() allocates streaminfo->streamctxarray with cdnspallocstreamctx(). If a later stream ring allocation or stream mapping update fails, the error path frees the allocated stream rings and streamrings array, but leaves streamctxarray allocated.

Free the stream context array before falling through to the streamrings cleanup path.

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

net: usb: kalmia: bound RX frame length in kalmiarxfixup()

kalmiarxfixup() computes usbpacketlength = skb->len - (2 KALMIAHEADERLENGTH) as a u16, guarded only by a pre-loop check that skb->len is at least KALMIAHEADERLENGTH, which is 6. A device can deliver a short bulk-IN frame with skb->len in the 6 to 11 range, or leave a short trailing remainder on a later loop iteration. Either case underflows usbpacketlength to about 65530.

That bypasses the usbpacketlength < etherpacketlength truncation path. The device-supplied etherpacketlength, a le16 up to 65535 read from headerstart[2], then drives a memcmp() and the following skbtrim() and skbpull() past the end of the rx buffer. The rx buffer is hardmtu 10, which is 14000 bytes. That is an out of bounds read.

Require both the start and end framing headers to be present before subtracting them, on every loop iteration.

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

usb: gadget: composite: fix dead empty check in the USBDTOTG handler

The OTG branch of compositesetup() falls back to the first configuration when none is selected:

if (cdev->config) config = cdev->config; else config = listfirstentry(&cdev->configs, struct usbconfiguration, list); if (!config) goto done; ... memcpy(req->buf, config->descriptors[0], value);

listfirstentry() never returns NULL. On an empty list it returns containerof() of the list head. So the "if (!config)" check is dead.

When cdev->configs is empty, config points at the head inside struct usbcompositedev. config->descriptors[0] reads whatever sits at that offset. The memcpy copies up to wlength bytes of it into the response buffer.

cdev->configs can be empty in two cases. One is a teardown race on gadget unbind with a control transfer in flight. The other is a driver that sets isotg before it adds a config. A reproducer that holds cdev->configs empty triggers a KASAN fault in this branch.

Use listfirstentryornull() so the existing check does its job.

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

usb: gadget: fprinter: take kref only for successful open

printeropen() returns -EBUSY when the character device is already open, but it increments dev->kref regardless of the return value. VFS does not call ->release() for a failed open, so every rejected second open permanently leaks one reference.

Move krefget() into the successful-open branch.

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

usb: mtu3: unmap request DMA on queue failure

mtu3gadgetqueue() maps the request before checking whether the QMU GPD ring can accept another transfer. the request is returned with -EAGAIN before it is linked on the endpoint request list if mtu3preparetransfer() fails.

Normal completion and dequeue paths unmap requests from mtu3reqcomplete(), but this error path never reaches that helper, so the DMA mapping is left active. Unmap the request before returning from the failed queue path.

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

USB: serial: keyspanpda: fix information leak

The write() callback is supposed to return the number of characters accepted or a negative errno. Since the addition of write fifo support the keyspanpda implementation will however return the number characters submitted to the device if the write urb is not already in use. If this number is larger than the number of characters passed to write(), the line discipline continues writing data from beyond the tty write buffer.

Fix the information leak by making sure that keyspanpdawritestart() returns zero on success as intended.

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

USB: serial: digiacceleport: fix broken rx after throttle

If the port is closed while throttled, the read urb is never resubmitted and the port will not receive any further data until the device is reconnected (or the driver is rebound).

Clear the throttle flags and submit the urb if needed when opening the port.

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

USB: serial: digiacceleport: fix hard lockup on disconnect

If submitting the OOB write urb fails persistently (e.g if the device is being disconnected) the driver would loop indefinitely with interrupts disabled.

Check for urb submission errors when sending OOB commands to avoid hanging if, for example, open(), settermios() or close() races with a physical disconnect.

This is issue was flagged by Sashiko when reviewing an unrelated change to the driver.

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

USB: ulpi: fix memory leak on registration failure

The allocated device name is never freed on early ULPI device registration failures.

Fix this by initialising the device structure earlier and releasing the initial reference whenever registration fails.

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

usbip: vudc: fix NULL deref in vepdequeue()

vepallocrequest() wasn't initializing vrequest->udc, so cancellations on the FunctionFS AIO path were arriving in vepdequeue without a valid UDC reference.

Since vrequest->udc is never actually properly used anywhere, we opt to remove it, and update vepdequeue to obtain a reference to the udc with eptovudc(), consistent with the other vep ops.

AFAICT this bug has existed for ~10 years. Seems that nobody has really stressed the FunctionFS AIO path on usbip's vudc.

I tested this fix in a QEMU aarch64 guest driving FunctionFS endpoints via AIO. Before the fix, running usbip attach from the host would cause the guest to oops with the following backtrace:

Call trace: vepdequeue+0x1c/0xe4 (P) usbepdequeue+0x14/0x20 ffsaiocancel+0x24/0x34 arm64sysiocancel+0xb0/0x124 doel0svc+0x68/0x100 el0svc+0x18/0x5c el0t64synchandler+0x98/0xdc el0t64sync+0x154/0x158

block: skip syncblockdev() on surprise removal in bdevmarkdead()

crypto: drbg - Fix returning success on failure in CTRDRBG

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

regulator: scmi: fix ofnode refcount leak in scmiregulatorprobe()

scmiregulatorprobe() calls offindnodebyname() which takes a reference on the returned device node. On the error path where processscmiregulatorofnode() fails, the function returns without calling ofnodeput() on the child node, leaking the reference.

Add ofnodeput(np) on the error path to properly release the reference.

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

module: decompress: check return value of moduleextendmaxpages()

moduleextendmaxpages() calls kvrealloc() internally and returns -ENOMEM on allocation failure. The return value is never checked.

If the initial allocation fails, info->pages remains NULL and info->maxpages remains 0. Subsequent calls to modulegetnextpage() will attempt to dynamically grow the array by calling moduleextendmaxpages(info, 0) since info->usedpages is 0. This results in kvrealloc(NULL, 0) returning ZEROSIZEPTR, which is treated as a success, leading to a dereference of ZEROSIZEPTR and a kernel oops.

Fix: add the missing error check after moduleextendmaxpages() and return immediately on failure. This matches the pattern used by every other kvrealloc() caller in the module loading path.

[Sami: Corrected the analysis in the commit message.]

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

Input: elani2c - prevent division by zero and arithmetic underflow

The Elan I2C touchpad driver queries the device for its physical dimensions and trace counts to calculate the device resolution and width. However, if the device firmware or device tree provides invalid zero values for xtraces or ytraces, it results in a fatal division-by-zero exception leading to a kernel panic during device probe.

Add checks to ensure these parameters are non-zero before performing the division. If invalid trace values are detected, fall back to a safe default of 1.

Additionally, prevent an arithmetic underflow in the touch reporting logic. Previously, if the calculated or fallback width was smaller than ETPFWIDTHREDUCE (90), the subtraction would underflow, resulting in a massive unsigned integer being reported to userspace. Clamp the adjusted width to a minimum of 0 to safely handle small physical dimensions and fallback scenarios.

Completing the probe with safe fallback values ensures the sysfs nodes are created, keeping the firmware update path intact so a recovery firmware can be flashed to the device.