gpio: eic-sprd: use rawspinlockt in the irq startup 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:

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:

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

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:

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.

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

MIPS: DEC: Prevent initial console buffer from landing in XKPHYS

In 64-bit configurations calling the initial console output handler from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment and consequently so has been the buffer allocated there that is used as the argument corresponding to the %s' output conversion specifier for the firmware's printf() entry point.

This 64-bit address will then be truncated by 32-bit firmware, resulting in an attempt to access the wrong memory location, which in turn will cause all kinds of unpredictable behaviour, such as a kernel crash:

Console: colour dummy device 160x64 Calibrating delay loop... 49.36 BogoMIPS (lpj=192512) pidmax: default: 32768 minimum: 301 CPU 0 Unable to handle kernel paging request at virtual address 000000000203bd00, epc == ffffffffbfc08364, ra == ffffffffbfc08800 Oops[#1]: CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc2-00254-gfb649bda6f56-dirty #121 $ 0 : 0000000000000000 0000000000000001 0000000000000023 ffffffff80684ba0 $ 4 : 000000000203bd00 ffffffffbfc0f3b4 ffffffffffffffff 0000000000000073 $ 8 : 0a303d7469000000 0000000000000000 0000000000000073 ffffffffbfc0f473 $12 : 0000000000000002 0000000000000000 ffffffff80684c1c 0000000000000000 $16 : 0000000000000000 ffffffff80596dc9 0000000000000000 ffffffffbfc09240 $20 : ffffffff80684c40 ffffffffbfc0f400 000000000000002d 000000000000002b $24 : ffffffffffffffbf 000000000203bd00 $28 : ffffffff805f0000 ffffffff80684b58 0000000000000030 ffffffffbfc08800 Hi : 0000000000000000 Lo : 0000000000000aa8 epc : ffffffffbfc08364 0xffffffffbfc08364 ra : ffffffffbfc08800 0xffffffffbfc08800 Status: 140120e2 KX SX UX KERNEL EXL Cause : 00000008 (ExcCode 02) BadVA : 000000000203bd00 PrId : 00000430 (R4000SC) Modules linked in: Process swapper (pid: 0, threadinfo=(ptrval), task=(ptrval), tls=0000000000000000) Stack : 0000000000000000 0000000000000000 0000000000000000 0000004d0000004d 80684cc0806a2a40 80596dc80000004d 8061000000000000 bfc0850c80684c38 0000000000000000 000000000203bd00 0000000000000000 0000000000000000 0000000000000000 00000000bfc0f3b4 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000002500000000 0000000000000000 0000000000000000 802c1a7400000000 0203bd0080596dc8 0203bd4d69000000 6c61632000000018 5f746567646e6172 6c616320625f6d6f 5f736e5f6d6f7266 206361323778302b 303d74696e726320 806a0a38806b0000 806a0a38806b0000 00000000806b0000 80683c58806b0000 ... Call Trace:

Code: a082ffff 03e00008 00601021 <80820000> 00001821 10400005 24840001 80820000 24630001

---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt

KN04 V2.1k (PC: 0xa0026768, SP: 0x806848e8) >>

In this case the pointer in $4 was truncated from 0x980000000203bd00 to 0x000000000203bd00.

This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started.

Fix the issue by making the buffer static and initdata, and therefore placed in the CKSEG0 32-bit compatibility segment, observing that the console output handler is called with the console lock held, implying no need for this code to be reentrant. Add an assertion to verify the buffer actually has been placed in a compatibility segment.

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

tty: serial: pchuart: add check for dmaalloccoherent()

Add a check for dmaalloccoherent() failure to prevent a potential NULL pointer dereference in dmahandlerx(). Properly release DMA channels and the PCI device reference using a goto ladder if the allocation fails.

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

device property: set fwnode->secondary to NULL in fwnodeinit()

If a firmware node is allocated on the stack (for instance: temporary software node whose life-time we control) or on the heap - but using a non-zeroing allocation function - and initialized using fwnodeinit(), its secondary pointer will contain uninitalized memory which likely will be neither NULL nor ISERR() and so may end up being dereferenced (for example: in devtoswnode()). Set fwnode->secondary to NULL on initialization.

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

sysfs: don't remove existing directory on update failure

When sysfsupdategroup() is called for a named group and createfiles() fails (e.g. -ENOMEM), internalcreategroup() calls kernfsremove(kn) on the group directory. In the update path, kn was obtained via kernfsfindandget() and refers to a directory that already existed before this call. Removing it silently destroys a sysfs group that the caller did not create.

Only remove the directory if we created it ourselves. On update failure the directory remains as it is left empty by removefiles() inside createfiles(), but can be repopulated by a retry.

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

phonet/pep: disable BH around forwarded skreceiveskb()

The networking receive path is usually run from softirq context, but protocols that take the socket lock may have packets stored in the backlog and processed later from process context. In that case releasesock() -> releasesock() drops the slock with spinunlockbh() and then calls sk->skbacklogrcv() with bottom halves enabled.

Typical skbacklogrcv handlers process the socket whose backlog is being drained, so the BH state at entry is irrelevant for the slocks they touch. pepdorcv() is different: when the inbound skb targets an existing PEP pipe, it forwards the skb to a different child socket via skreceiveskb(). That helper takes the child slock with bhlocksocknested(), which is just spinlocknested() and assumes BH is already off. The same child slock therefore ends up acquired with BH on (process path) and with BH off (softirq path):

process context softirq context --------------- --------------- releasesock(listener) netifreceiveskb() releasesock() phonetrcv() spinunlockbh() skreceiveskb(listener) [BH now ENABLED] [BH already disabled] skbacklogrcv: skbacklogrcv: pepdorcv() pepdorcv() skreceiveskb(child) skreceiveskb(child) bhlocksocknested(child) bhlocksocknested(child) => SOFTIRQ-ON-W => IN-SOFTIRQ-W

Lockdep flags this as inconsistent lock state, and it can become a real self-deadlock if a softirq on the same CPU tries to receive to the same child socket while its slock is held in the BH-enabled path:

WARNING: inconsistent lock state inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. (slock-AFPHONET/1){+.?.}-{3:3}, at: skreceiveskb+0x1cf/0x900 skreceiveskb net/core/sock.c:563 skreceiveskb include/net/sock.h:2022 [inline] pepdorcv net/phonet/pep.c:675 skbacklogrcv include/net/sock.h:1190 releasesock net/core/sock.c:3216 releasesock net/core/sock.c:3815 pepsockaccept net/phonet/pep.c:879

Wrap the forwarded skreceiveskb() in localbhdisable() / localbhenable() so the child slock is always acquired with BH off. localbhdisable() nests safely on the softirq path.

Discovered via in-house syzkaller fuzzing; the same root cause also on the linux-6.1.y syzbot dashboard as extid 44f0626dd6284f02663c. Reproduced under KASAN + LOCKDEP + PROVELOCKING, reproducer: https://pastebin.com/A3t8xzCR

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

wifi: cfg80211: advance loop vars in cfg80211mergeprofile()

cfg80211mergeprofile() reassembles a Multi-BSSID non-transmitted BSS profile that has been split across multiple consecutive MBSSID elements. Its while-loop calls

cfg80211getprofilecontinuation(ie, ielen, mbssidelem, subelem)

but never advances mbssidelem or subelem inside the body. Each iteration therefore searches for a continuation that follows the same fixed pair; the helper returns the same nextmbssid; and the same nextsub bytes are memcpy()'d into mergedie at a growing offset until the buffer fills.

Advance both mbssidelem and subelem to the just-consumed continuation so the next call to cfg80211getprofilecontinuation() searches for a further continuation beyond it (or returns NULL when none exists).

A specially-crafted malicious beacon can take advantage of this bug to cause the kernel to spend an excessive amount of time in cfg80211mergeprofile (up to as much as 2ms per beacon received), which could theoretically be abused in some way.

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

tracing: Do not call map->ops->eltfree() if eltalloc() fails

In paths where tracingmapeltalloc() failed to allocate objects, the map->ops->eltalloc() call was never successful. In this case, map->ops->eltfree() should not be called.

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

spi: qup: fix error pointer deref after DMA setup failure

The driver falls back to PIO mode if DMA setup fails during probe.

Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer (or attempting to release a channel a second time) on later probe errors or driver unbind.

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.

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

spi: sprd: fix error pointer deref after DMA setup failure

The driver falls back to PIO mode if DMA setup fails during probe.

Make sure to check the dma.enabled flag before trying to release the DMA channels also on late probe errors to avoid dereferencing an error pointer (or attempting to release a channel a second time).

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.

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

ARM: integrator: Fix early initialization

Starting with commit bdb249fce9ad4 ("ARM: integrator: read counter using syscon/regmap"), intcpinitearly calls sysconregmaplookupbycompatible which in turn calls ofsysconregister. This function allocates memory. Since the memory management code has not been initialized at that time, the call always fails. It either returns -ENOMEM or crashes as follows.

Unable to handle kernel NULL pointer dereference at virtual address 0000000c when read [0000000c] pgd=00000000 Internal error: Oops: 5 [#1] ARM Modules linked in: CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.15.0-rc5-00026-g5fcc9bf84ee5 #1 PREEMPT Hardware name: ARM Integrator/CP (Device Tree) PC is at kmalloccachenoprof+0xec/0x39c LR is at kmalloccachenoprof+0x34/0x39c ... Call trace: kmalloccachenoprof from ofsysconregister+0x7c/0x310 ofsysconregister from devicenodegetregmap+0xa4/0xb0 devicenodegetregmap from intcpinitearly+0xc/0x40 intcpinitearly from startkernel+0x60/0x688 startkernel from 0x0

The crash is seen due to a dereferenced pointer which is not supposed to be NULL but is NULL if the memory management subsystem has not been initialized. The crash is not seen with all versions of gcc. Some versions such as gcc 9.x apparently do not dereference the pointer, presumably if tracing is disabled. The problem has been reproduced with gcc 10.x, 11.x, and 13.x. Either case, if the crash is not seen, the call to sysconregmaplookupbycompatible returns -ENOMEM, and schedclockregister is never called.

Fix the problem by moving the early initialization code into the standard machine initialization code.

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

wifi: ath11k: fix error path leaks in some WMI WOW calls

Fix two instances where we used to directly return the result of ath11kwmicmdsend(...). Because we did not check the return value, we also did not free the skb in the error path.

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

hwmon: (pmbus/adm1266) widen blackbox-info buffer to I2CSMBUSBLOCKMAX

adm1266nvmemreadblackbox() declares a 5-byte stack buffer and passes it to i2csmbusreadblockdata() to retrieve the 4-byte BLACKBOXINFO response. i2csmbusreadblockdata() does not honour caller buffer sizes -- it memcpy()s data.block[0] bytes from the SMBus transaction (where data.block[0] is the length byte returned by the slave device, up to I2CSMBUSBLOCKMAX = 32):

memcpy(values, &data.block[1], data.block[0]);

If the device returns any block length above 5, the call overflows the caller's 5-byte stack buffer before the post-call

if (ret != 4) return -EIO;

check has a chance to reject the response.

Widen the local buffer to I2CSMBUSBLOCKMAX so the helper has room for any well-formed SMBus block response, matching the convention used by the other i2csmbusreadblockdata() callers in this driver.

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

batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface

Without rtnllock held, a hardif might be retrieved as primary interface of a meshif, but then (while operating on this interface) getting decoupled from the mesh interface. In this case, the meshif still exists but the pointer from the primary hardif to the meshif is set to NULL.

The meshiface must be checked first to be non-NULL before continuing to send an ARP request using meshif.