Kernel memory leak in the Linux USB gadget FunctionFS (f_fs) subsystem allows a local low-privileged user to slowly exhaust kernel memory by repeatedly triggering DMA buffer transfers via the ffs_dmabuf_transfer() code path. Affected kernels span from the commit introducing DMA buffer sharing (7b07a2a7ca02) through versions prior to 6.12.96, 7.1.4, and 7.2-rc3. The root cause is a missing dma_fence_put() call after dma_resv_add_fence(), leaving the initial kref permanently outstanding and causing ffs_dma_fence objects to accumulate without ever being freed. No public exploit has been identified at time of analysis.
The USB gadget FunctionFS (f_fs) subsystem in the Linux kernel fails to initialize the endpoint direction field (epfile->in) until USB host connection, leaving it zero when userspace performs early DMA ioctl calls such as FUNCTIONFS_DMABUF_ATTACH before a host connects. This incorrect DMA direction causes kernel-mode availability loss - crashes or hangs - on systems actively using FunctionFS-based USB gadgets with DMABUF. No public exploit has been identified, and EPSS probability stands at 0.21% (11th percentile), reflecting very low opportunistic exploitation risk.
The block device layer in Linux Kernel hangs indefinitely during NVMe surprise removal when `bdev_mark_dead()` is called with `surprise=true`, because a missing guard causes `sync_blockdev()` to be invoked on an already-dead device, permanently blocking `folio_wait_writeback()`. Triggered via `nvme_reset_work()` I/O-queues-lost path, the bug wedges the NVMe reset worker and every task waiting on it, requiring a system reboot to recover. Discovered by FuzzNvme (syzkaller + FEMU fuzzing framework); no public exploit identified at time of analysis.
Reference count leak in the Linux kernel NVMe-oF target RDMA subsystem causes local denial of service on affected storage servers. When nvmet_rdma_queue_connect() calls nvmet_rdma_find_get_device() and the host queue backlog is exceeded (NVME_SC_CONNECT_CTRL_BUSY), the kref acquired by kref_get() is never released via the put_device cleanup path. Repeated triggering of this code path by a local low-privileged process causes progressive resource exhaustion, ultimately rendering the affected device unreclaimable and degrading availability. No public exploit has been identified at time of analysis, and EPSS is 0.21% (11th percentile).
Incorrect idmap handling in the Linux kernel memory management subsystem causes `owner_or_capable()` checks inside `mincore()` and `madvise(MADV_PAGEOUT)` to use the identity no-op mount idmap (`nop_mnt_idmap`) rather than the actual mount's idmap, producing incorrect ownership evaluations on idmapped mounts. Local users with low privileges on Linux 5.12+ systems configured with idmapped mounts may trigger incorrect authorization decisions that deny legitimate memory management operations, with the most impactful edge case occurring on 0444 files where neither the idmap check nor the fallback `file_permission(MAY_WRITE)` path succeeds. No public exploit is known and EPSS is 0.21% (11th percentile), reflecting minimal real-world exploitation risk despite the Linux kernel's ubiquitous deployment footprint.
Unbounded cache invalidation parameters in the Linux kernel iommufd subsystem allow a local low-privileged user to pin a CPU indefinitely or trigger a soft-lockup watchdog fault, resulting in a kernel denial of service. The iommufd_hwpt_invalidate() ioctl accepts user-supplied entry_len and entry_num values bounded only by U32_MAX, enabling an uninterruptible gigabyte-scale memory scan or a no-reschedule VT-d flush loop. No public exploit has been identified and EPSS stands at 0.21% (11th percentile); the vulnerability is not listed in CISA KEV, indicating low active exploitation pressure.
XFS filesystem quota iteration in the Linux kernel wraps a 32-bit quota ID back to zero when a disk quota entry (dquot) exists at XFS_DQ_ID_MAX, producing an infinite loop and local denial of service. Systems running Linux 6.8 and later with XFS quotas enabled are vulnerable if a dquot is present at the maximum 32-bit ID boundary (0xFFFFFFFF). No active exploitation has been identified; patched releases 6.12.96, 6.18.39, 7.1.4, and 7.2-rc4 are available from the kernel stable tree.
Resource exhaustion via file reference leak in the Linux kernel's io_uring NOP opcode handler allows a local, low-privileged user to gradually exhaust kernel memory. The flaw occurs when a NOP submission carries the generic IOSQE_FIXED_FILE sqe flag (setting REQ_F_FIXED_FILE) but omits the NOP-specific IORING_NOP_FIXED_FILE flag in nop_flags: io_nop() acquires a real file reference via io_file_get_normal(), yet io_put_file() skips releasing it because REQ_F_FIXED_FILE is set, producing one leaked 176-byte kernel file object per operation. No public exploit has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
The Linux kernel BPF verifier incorrectly elides null-check requirements for inner array map lookups when the BPF_F_INNER_MAP flag is set, allowing a local attacker with BPF program loading privileges to trigger a null pointer dereference and crash the kernel. The flaw arises because the verifier uses the inner map template's max_entries for bounds reasoning at verification time, while the runtime helper operates against a concrete inner map that may have a larger max_entries value. A crafted BPF program exploiting the faulty nullness elision can cause a kernel denial of service. No public exploit code has been identified at time of analysis, and EPSS is low at 0.21%.
Incorrect argument passing in dwc3_ulpi_setup() causes the Linux kernel's DWC3 USB controller driver to pass a raw MMIO register pointer (dwc3->regs, typed as void __iomem *) to dwc3_readl() and dwc3_writel(), which instead expect the containing struct dwc3 * pointer. Because the register accessor functions internally dereference the struct to locate ->regs, supplying ->regs directly results in incorrect memory access during ULPI (USB Low Pin Interface) initialization - flagged by the kernel sparse checker as a type-safety violation across address spaces. The practical impact is a potential kernel panic or silent misread/miswrite of a USB control register, manifesting as an availability failure in systems using DWC3 ULPI USB controllers. No public exploit exists and the issue requires local access to trigger.
Null pointer dereference in the Linux kernel's chacha20poly1305 crypto template allows a local unprivileged user to crash the system. The flaw exists in chachapoly_create(), which passes the unvalidated return value of crypto_attr_alg_name() directly to strcmp() when the poly1305 sub-argument is absent in a malformed template string; since that function returns an ERR_PTR on failure, the subsequent strcmp() call dereferences an invalid pointer, triggering a kernel panic. Patches are available across multiple stable branches; no public exploit or active exploitation has been identified at time of analysis.
PMD-sized vmemmap pages are silently leaked in the Linux kernel's x86 memory management subsystem following a regression introduced in commit bf9e4e30f353, which replaced __free_pages() with pagetable_free() for vmemmap page freeing. Because vmemmap pages are not compound pages (outside of HVO, which does not apply here), pagetable_free() resolves compound_order() to zero and frees only the first page of a PMD-sized block, leaking the remaining pages on every memory section removal. Systems running affected kernel versions (6.18.7-6.18.38, 6.19 series through 7.1.3) that perform x86 memory hotplug operations will experience progressive physical memory loss; no public exploit has been identified and this vulnerability is not in CISA KEV.
NULL pointer dereference in the Linux kernel's `page_ext` memory iteration API crashes systems during dynamic memory hotplug operations. The `page_ext_iter_next()` function fails to enforce the PFN boundary, advancing the iterator index past `__pgcount` and calling `page_ext_lookup()` on an uninitialized memory section, triggering a kernel panic. With EPSS at 0.21% (11th percentile) and no CISA KEV listing, real-world exploitation is low-probability and operationally constrained to environments actively performing memory hotplug, such as cloud hypervisors or NUMA-heavy servers with memory ballooning.
Atomic memory reserve exhaustion in the Linux kernel's iommufd subsystem allows a local low-privileged user to trigger kernel-side memory pressure by allocating virtual event queues whose depth is fully user-controlled, potentially destabilizing the system through GFP_ATOMIC reserve depletion. The root cause is memory allocation for veventq entries occurring inside a spinlock, drawing from atomic reserves never intended for user-directed exhaustion. No active exploitation is confirmed and EPSS sits at 0.21% (11th percentile); upstream fix commits are available across the 6.18.x, 7.1.x, and 7.2-rc1 stable series.
Memory exhaustion in the Linux kernel iommufd subsystem allows a local low-privileged user to crash the system by passing an uncapped veventq_depth value to iommufd_veventq_alloc(), which previously accepted any non-zero integer up to U32_MAX without validation. Exploitation requires local access with low privileges on a system where the iommufd device is accessible, making this primarily a concern for multi-tenant or virtualization hosts. No public exploit has been identified and EPSS at 0.21% (11th percentile) reflects minimal real-world exploitation interest at time of analysis.
Infinite loop in the Linux kernel iommufd subsystem's fault read path allows a low-privileged local user to pin a CPU core at 100% utilization while holding a kernel mutex, causing a local denial of service. The flaw exists in iommufd_fault_fops_read(), where a copy_to_user() failure in the inner list traversal loop fails to propagate its error code to the outer while loop, which then re-fetches the same fault group and retries the failing operation indefinitely with fault->mutex held. No public exploit is identified at time of analysis; EPSS indicates a very low 0.21% exploitation probability, and this CVE is not listed in the CISA KEV catalog.
Null pointer dereference in the Linux kernel's KVM arm64 nested virtualization subsystem allows a local low-privileged attacker to crash the host kernel via a race condition in VNCR pseudo-TLB invalidation. The function kvm_invalidate_vncr_va() dereferences the VNCR pseudo-TLB pointer without first verifying allocation or validity, unlike its companion kvm_invalidate_vncr_ipa(). Exploitation results in a kernel panic that disrupts all virtual machines on the affected host; no public exploit has been identified at time of analysis, and EPSS of 0.21% (11th percentile) reflects minimal observed exploitation activity.
System hang vulnerability in the Linux kernel's NXP i.MX LPI2C driver arises from a race condition during suspend/resume power transitions. Specifically, periodic workqueues in I2C client drivers can fire I2C transfers between the suspend_noirq and resume_noirq phases, when clock and pinctrl resources have already been disabled or are not yet restored. Accessing I2C controller registers in this state causes the system to hang. The fix marks the adapter as suspended during noirq suspend, blocking transfers until hardware resources are fully restored. No public exploit or confirmed active exploitation (CISA KEV) has been identified at time of analysis.
Integer wrap in the FUSE subsystem's prune notification handler crashes 32-bit Linux kernels when a malicious or compromised FUSE daemon sends a crafted FUSE_NOTIFY_PRUNE message. On 32-bit platforms where size_t is 32 bits, multiplying a daemon-controlled count value of 0x20000000 by sizeof(u64) wraps to zero, causing the payload length check to pass with no actual nodeid data present; the subsequent copy loop then triggers a BUG_ON assertion, inducing a kernel panic. No public exploit has been identified at time of analysis and EPSS stands at 0.21% (11th percentile), consistent with the narrow exploitation window of 32-bit-only kernels and requiring FUSE daemon control.
Error-code mishandling in the Linux kernel fuse-uring subsystem causes a failed copy_from_user() in fuse_uring_commit to be silently treated as success, leaving callers processing uninitialized or partial output arguments. Local users with low-privilege access on kernels from 6.14 through pre-patch versions can trigger a kernel panic or crash, yielding a local denial of service. No public exploit has been identified and the EPSS score of 0.21% (11th percentile) indicates no meaningful active exploitation activity at time of analysis.
Kernel panic in the Linux kernel's fuse-uring subsystem allows a local low-privileged attacker to crash the system by triggering a NULL pointer dereference through crafted io_uring cancellation sequences against a FUSE filesystem. The root cause is that fuse_uring_cancel() moves cancelled entries with no attached requests to the ent_in_userspace list, where ent_list_request_expired() unconditionally dereferences ent->fuse_req, crashing the kernel. No public exploit code exists and EPSS sits at 0.21% (11th percentile), indicating negligible opportunistic exploitation pressure; however, the low privilege requirement and local DoS impact make it relevant for multi-tenant or shared-access Linux environments.
Resource exhaustion and denial of service in the Linux kernel's fuse-uring subsystem allows a local authenticated user to permanently hang FUSE requests and stall all background filesystem operations for the affected connection. The flaw was introduced with the fuse-uring interface in Linux 6.14 and affects stable series through 6.18.38 and 7.1.3; patched releases 6.18.39, 7.1.4, and mainline 7.2-rc1 are available. No public exploit has been identified at time of analysis (EPSS 0.21%, 11th percentile) and the vulnerability is absent from CISA KEV, indicating no confirmed active exploitation.
NULL pointer dereference in the Linux kernel's fuse-uring subsystem enables a local low-privilege attacker to crash the kernel, causing a denial of service. The flaw arises from a state management race in the fuse-uring request lifecycle: when a copy into a userspace io_uring ring buffer fails, the entry's request pointer is nullified but the entry remains on the active queue, allowing the expiration scanner to dereference the NULL pointer in a narrow race window. No public exploit has been identified and EPSS stands at 0.21% (11th percentile), indicating low likelihood of opportunistic exploitation.
NULL pointer dereference in the Linux kernel tracing subsystem (`func_set_flag()`) allows a local attacker with tracefs write access to trigger a kernel panic and crash the system. The flaw arises when a process holds an open file descriptor to a function tracer option (e.g., `func_stack_trace`) while a concurrent tracer switch sets `tr->current_trace_flags` to NULL; a subsequent write to that option file then dereferences the NULL pointer before the function tracer guard executes. No active exploitation (KEV) or public exploit code has been identified; EPSS is 0.20% at the 10th percentile, consistent with a localized, technically specific DoS condition.
NULL pointer dereference in the Linux kernel's hid_logitech_dj driver causes a kernel crash (DoS) when a crafted HID descriptor is processed during device probe. The flaw exists in logi_dj_probe(): when a Logitech Unifying receiver emulation presents report ID 0x20 with only padding output items, hid-core registers the report with rep->maxfield == 0. The error-path validation then dereferences rep->field[0]->report_count while printing a diagnostic message, triggering a KASAN-visible null-ptr-deref and kernel panic. No public exploit is identified at time of analysis, but the kernel commit descriptions include a full uhid-based reproduction method, lowering the barrier for local attackers.
NULL pointer dereference in the Linux kernel's mt76 driver for MediaTek mt7921/mt7925 WiFi chipsets causes a kernel panic (denial of service) via a race condition in Channel Switch Announcement (CSA) beacon processing. When a CSA beacon is received, cfg80211 queues a wiphy work item; if the station disconnects or the channel context is torn down before the work item executes, the driver's dev->new_ctx pointer is already NULL but dereferenced unconditionally in mt7921_channel_switch_rx_beacon() and mt7925_channel_switch_rx_beacon(). EPSS is 0.20% (10th percentile) and no public exploit or CISA KEV listing is identified at time of analysis.
KVM's SEV-SNP guest initialization path in the Linux kernel can trigger a host kernel panic when processing CPUID data backed by a read-only memory mapping. The flaw affects hypervisors running Linux 7.0.x before 7.1.4 where a local, low-privileged VMM process can cause KVM to write corrected CPUID values into a read-only source page after AMD's trusted firmware rejects the userspace-supplied data. No public exploit has been identified and EPSS sits at 0.20% (10th percentile), consistent with a niche, difficult-to-trigger local denial-of-service condition with no confirmed active exploitation.
Memory exhaustion in ImageMagick's magick CLI tool allows a local attacker to cause denial of service by repeatedly supplying malformed command-line arguments. Affects versions before 7.1.2-27. Vendor patch is available; no public exploit or active exploitation reported.
Null pointer dereference in the Linux kernel's cpufreq subsystem during system reboot allows a local attacker with low privileges to crash the kernel. The reboot path (kernel_restart() → device_shutdown() → cpufreq_suspend()) does not invoke freeze_processes() - unlike the normal suspend path - leaving CPU hotplug operations free to run concurrently and free governor_data while cpufreq_suspend() is still reading it, producing a use-after-free null pointer dereference. No public exploit exists and EPSS probability is 0.22% (13th percentile), placing this in low-urgency territory despite the ubiquitous kernel footprint.
KVM arm64 in the Linux kernel leaks a Page Frame Number reference when kvm_translate_vncr() races an MMU notifier, allowing a local low-privileged attacker to gradually exhaust kernel memory and cause a denial of service on affected arm64 hypervisor hosts. The vulnerability is specific to arm64 systems running KVM with VNCR (Virtualization Non-Cached Region) active, and requires precise race-condition timing (AC:H). No public exploit has been identified at time of analysis, and the EPSS score of 0.21% (11th percentile) confirms this remains a low-probability exploitation target.
In the Linux kernel, the following vulnerability has been resolved: iio: gyro: bmg160: bail out when bandwidth/filter is not in table bmg160_get_filter() walks bmg160_samp_freq_table[] looking for the entry matching the bw_bits value read from the chip: for (i = 0; i < ARRAY_SIZE(bmg160_samp_freq_table); ++i) { if (bmg160_samp_freq_table[i].bw_bits == bw_bits) break; } *val = bmg160_samp_freq_table[i].filter; If no entry matches, i ends up equal to the array size and the next line reads one slot past the end. bmg160_set_filter() has the same shape, driven by 'val' instead of bw_bits. smatch flags both: drivers/iio/gyro/bmg160_core.c:204 bmg160_get_filter() error: buffer overflow 'bmg160_samp_freq_table' 7 <= 7 drivers/iio/gyro/bmg160_core.c:222 bmg160_set_filter() error: buffer overflow 'bmg160_samp_freq_table' 7 <= 7 Return -EINVAL when no entry matches. The set_filter() path is reachable from userspace via the sysfs in_anglvel_filter_low_pass_3db_frequency interface, so userspace can trivially trigger the out-of-bounds read with a value that is not in bmg160_samp_freq_table[].filter.
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Unconditionally recompute CR8 intercept on PPR update The TPR_THRESHOLD field in the VMCS is used by VMX to induce VM exits when the guest's virtual TPR falls under the specified threshold, allowing KVM to inject previously masked interrupts. KVM handles these VM exits in handle_tpr_below_threshold(). Commit eb90f3417a0c ("KVM: vmx: speed up TPR below threshold vmexits") optimized this function by calling apic_update_ppr() instead of raising KVM_REQ_EVENT. apic_update_ppr() then raises KVM_REQ_EVENT if there is a pending, deliverable interrupt. However, if there are no new interrupts pending, apic_update_ppr() does not issue the request. Thus, kvm_lapic_update_cr8_intercept() and vmx_update_cr8_intercept() are not called before VM entry, which results in a high, stale TPR_THRESHOLD. This is problematic due to the following sentence in 28.2.1.1 "VM-Execution Control Fields" in the SDM: The following check is performed if the “use TPR shadow” VM-execution control is 1 and the “virtualize APIC accesses” and “virtual-interrupt delivery” VM-execution controls are both 0: the value of bits 3:0 of the TPR threshold VM-execution control field should not be greater than the value of bits 7:4 of VTPR. This error condition is typically not observed when KVM runs on a bare metal system because modern processors support APICv, which enables virtual-interrupt delivery, and which KVM uses when possible. This causes the processor to no longer generate TPR-below-threshold exits and to no longer check TPR_THRESHOLD on entry. However, when running on older platforms, or under nested virtualization on a hypervisor that does not support virtual-interrupt delivery and enforces this check (like Hyper-V) this can cause a VM entry failure with hardware error 0x7, as seen in [1]. Call kvm_lapic_update_cr8_intercept() if apic_update_ppr() does not find a deliverable interrupt (and thus does not raise KVM_REQ_EVENT). Remove calls to kvm_lapic_update_cr8_intercept() on paths that end up in apic_update_ppr(), as they now become redundant. This ensures that any path that updates the guest's PPR also figures out if KVM needs to wait for a TPR change (using TPR_THRESHOLD on VMX or CR8 intercepts on SVM).
In the Linux kernel, the following vulnerability has been resolved: userfaultfd: gate must_wait writability check on pte_present() userfaultfd_must_wait() and userfaultfd_huge_must_wait() read the PTE without taking the page table lock and then apply pte_write() / huge_pte_write() to it. Those accessors decode bits from the present encoding only; on a swap or migration entry they read the offset bits that happen to share the same position and return an undefined result. The intent of the check is "is this fault still WP-blocked?". A non-marker swap entry means the page is in transit -- the userfault context the original fault delivered against is no longer the same, and the swap-in or migration completion path will re-deliver a fresh fault if userspace still needs to handle it. Worst case under the current code the garbage write bit says "wait", and the thread stays asleep until a UFFDIO_WAKE that may never arrive. Gate the writability check on pte_present() so the lockless re-check only inspects present-PTE bits when the entry is actually present. The non-present, non-marker case returns "don't wait" and lets the fault path retry.
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: function: rndis: add length check for header Add a length check for the rndis header in rndis_rm_hdr, to ensure that MessageType, MessageLength, DataOffset, and DataLength fields are present before they are accessed.
In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: clamp the device-reported FIFO frame count __bmc150_accel_fifo_flush() copies the number of samples the device reports in its hardware FIFO into an on-stack buffer u16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3]; which is sized for at most BMC150_ACCEL_FIFO_LENGTH (32) samples. The frame count is read from the FIFO_STATUS register and only masked to its 7 valid bits: count = val & 0x7F; so it can be 0..127. The only other limit applied to it is the optional caller-supplied sample budget: if (samples && count > samples) count = samples; which does not constrain count on the flush-all path (samples == 0), and leaves it well above 32 whenever samples is larger. count samples are then transferred into buffer[]: bmc150_accel_fifo_transfer(data, (u8 *)buffer, count); bmc150_accel_fifo_transfer() reads count * 6 bytes through regmap, so a malfunctioning, malicious or counterfeit accelerometer (or an attacker tampering with the I2C/SPI bus) that reports up to 127 frames writes up to 762 bytes into the 192-byte buffer: a stack out-of-bounds write of up to 570 bytes that clobbers the stack canary, saved registers and the return address. Clamp count to BMC150_ACCEL_FIFO_LENGTH, the number of samples buffer[] is sized for, before the transfer, mirroring the watermark clamp already done in bmc150_accel_set_watermark(). A well-formed flush reports at most BMC150_ACCEL_FIFO_LENGTH frames, so legitimate devices are unaffected.
In the Linux kernel, the following vulnerability has been resolved: iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error kxsd9_write_raw() takes a runtime PM reference with pm_runtime_get_sync() but returns -EINVAL directly when a scale with a non-zero integer part is requested, skipping the matching pm_runtime_put_autosuspend(). This leaks a runtime PM usage-counter reference on every such write, after which the device can no longer autosuspend. Set the error code and fall through to the existing put instead of returning early.
In the Linux kernel, the following vulnerability has been resolved: iio: adc: lpc32xx: Initialize completion before requesting IRQ In the report from Jaeyoung Chung: "lpc32xx_adc_probe() in drivers/iio/adc/lpc32xx_adc.c registers its interrupt handler with devm_request_irq() before it initializes st->completion with init_completion(). If an interrupt arrives after devm_request_irq() and before init_completion(), the handler calls complete() on an uninitialized completion, causing a kernel panic. The probe path, in lpc32xx_adc_probe(): iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */ ... retval = devm_request_irq(&pdev->dev, irq, lpc32xx_adc_isr, 0, LPC32XXAD_NAME, st); /* register handler */ ... init_completion(&st->completion); /* initialize completion */ lpc32xx_adc_isr() calls complete(): complete(&st->completion); If the device raises an interrupt before init_completion() runs, complete() acquires the uninitialized wait.lock and walks the zeroed task_list in swake_up_locked(). The zeroed task_list makes list_empty() return false, so swake_up_locked() dereferences a NULL list entry, triggering a KASAN wild-memory-access." Fix the chance of a spurious IRQ causing an uninitialized pointer dereference by moving init_completion() above devm_request_irq().
In the Linux kernel, the following vulnerability has been resolved: iio: chemical: scd30: Cleanup initializations and fix sign-extension bug Include linux/bitfield.h for FIELD_GET(). Create new macros for bit manipulation in combination with manual bit manipulation being replaced with FIELD_GET(). The current variable declaration and initializations are barely readable and use comma separations across multiple lines. Refactor the initializations so that mantissa and exp have separate declarations and sign gets initialized later. In addition (and due to the nature of the cleanup), fix a sign-extension bug where, float32 would get bitwise anded with ~BIT(31) (which is 0xFFFFFFFF7FFFFFFF) which corrupted the exponent.
In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: fix runtime PM leak on read error gp2ap002_read_raw() calls pm_runtime_get_sync() before reading the lux value, but if gp2ap002_get_lux() fails, it returns directly. This skips the pm_runtime_put_autosuspend() call at the "out" label, permanently leaking a runtime PM reference and preventing the device from autosuspending. Replace the direct return with a "goto out" to ensure the reference is properly dropped on the error path.
In the Linux kernel, the following vulnerability has been resolved: ALSA: aoa: check snd_ctl_new1() return value snd_ctl_new1() can return NULL when memory allocation fails. In layout.c, the function does not check the return value before dereferencing ctl->id.name or passing to aoa_snd_ctl_add(), which can lead to a NULL pointer dereference. Add NULL checks after snd_ctl_new1() calls and return early if any fails.
In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input parser snd_usb_caiaq_tks4_dispatch() decodes the Traktor Kontrol S4 input stream in fixed 16-byte (TKS4_MSGBLOCK_SIZE) message blocks. On every iteration it advances buf and subtracts the block size while looping on "while (len)". len is urb->actual_length. That value is supplied by the device and is not guaranteed to be a multiple of 16. When a final short block leaves len between 1 and 15, the loop runs once more, reads up to buf[15], and then does "len -= TKS4_MSGBLOCK_SIZE". As len is unsigned this underflows to a huge value. The loop then keeps iterating and walking buf far past the end of the 512-byte ep4_in_buf, reading out of bounds until a bogus block id happens to be hit. Iterate only while a full message block is available. This stops the unsigned underflow and silently drops any trailing partial block, which carries no complete control value anyway. The sibling endpoint-4 parsers are not affected. The Traktor Kontrol X1 and Maschine arms in snd_usb_caiaq_ep4_reply_dispatch() floor urb->actual_length before dispatching.
In the Linux kernel, the following vulnerability has been resolved: ALSA: es1938: check snd_ctl_new1() return value snd_ctl_new1() can return NULL when memory allocation fails. snd_es1938_mixer() does not check the return value before dereferencing the pointer, which can lead to a NULL pointer dereference. Add a NULL check after snd_ctl_new1() and return -ENOMEM if it fails.
In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire: isight: bound the sample count to the packet payload isight_packet() takes the frame count from the device iso packet and checks it only against the device claimed iso length. count = be32_to_cpu(payload->sample_count); if (likely(count <= (length - 16) / 4)) isight_samples(isight, payload->samples, count); length is the iso header data_length. It can be up to 0xffff. So the gate allows a count up to about 16379. isight_samples() then copies count frames out of payload->samples into the PCM DMA buffer. payload->samples holds only 2 * MAX_FRAMES_PER_PACKET values. The device multiplexes two samples per frame. A count past MAX_FRAMES_PER_PACKET reads past the payload. A count past the buffer size writes past runtime->dma_area. The smallest PCM buffer is larger than MAX_FRAMES_PER_PACKET. Bounding the count to MAX_FRAMES_PER_PACKET keeps both the read and the write in range. A malicious or faulty Apple iSight on the FireWire bus reaches this during a normal capture. Add the MAX_FRAMES_PER_PACKET bound to the gate.
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: avoid kobject path lookup in DualSense match The DualSense jack-detection input handler verifies that a matching input device belongs to the same physical controller by building kobject path strings for both the input device and the USB audio device, then comparing the path prefix. This was observed when a weak physical connection caused the controller to rapidly disconnect and reconnect. During that repeated hotplug, snd_dualsense_ih_match() can run while the controller's USB device is being disconnected. kobject_get_path() walks ancestor kobjects and dereferences their names; if the USB device kobject name is no longer valid, this can fault in strlen(): RIP: 0010:strlen+0x10/0x30 Call Trace: kobject_get_path+0x34/0x150 snd_dualsense_ih_match+0x49/0xd0 [snd_usb_audio] input_register_device+0x566/0x6a0 ps_probe+0xb89/0x1590 [hid_playstation] The same ownership check can be done without building kobject path strings. The input device is parented below the HID device, USB interface and USB device, so walking the input device parent chain and comparing against the mixer USB device preserves the check without dereferencing kobject names during disconnect.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: fix use-after-free on registration failure Make sure to release the sibling interfaces in case controller registration fails to avoid use-after-free and double-free when they are eventually disconnected. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: fix use-after-free on marvell probe failure Make sure to stop any TX URBs submitted during Marvell OOB wakeup configuration on later probe failures to avoid use-after-free in the completion callback. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths.
In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix sleep in atomic context in xhci_free_streams() When a USB device with active stream endpoints is disconnected, xhci_free_streams() is called from the hub_event workqueue to free the stream resources. It calls xhci_free_stream_info() while holding xhci->lock with irqs disabled. xhci_free_stream_info() invokes xhci_free_stream_ctx(), which calls dma_free_coherent() for large stream context arrays. dma_free_coherent() can sleep (e.g. via vunmap), triggering a BUG when called from atomic context. Call trace: dma_free_attrs+0x174/0x220 xhci_free_stream_info+0xd0/0x11c xhci_free_streams+0x278/0x37c usb_free_streams+0x98/0xc0 usb_unbind_interface+0x1b8/0x2f8 device_release_driver_internal+0x1d4/0x2cc device_release_driver+0x18/0x28 bus_remove_device+0x160/0x1a4 device_del+0x1ec/0x350 usb_disable_device+0x98/0x214 usb_disconnect+0xf0/0x35c hub_event+0xab4/0x19ec process_one_work+0x278/0x63c Fix this by saving the stream_info pointers and clearing the ep references under the lock, then calling xhci_free_stream_info() outside the lock where sleeping is allowed.
In the Linux kernel, the following vulnerability has been resolved: PCI: altera: Fix resource leaks on probe failure The chained IRQ handler is set during probe, but is only removed during the driver remove(). If pci_host_probe() fails, the handler and INTx IRQ domain remain set even though the devm-managed host bridge storage containing struct altera_pcie will be released, leaving the handler with a stale data pointer. Interrupts are also enabled before pci_host_probe() is called. If probe fails after that point, the controller interrupt source should be disabled before the chained handler and INTx domain are removed. So set the chained handler only after the INTx domain has been created. Disable controller interrupts during IRQ teardown, and tear the IRQ setup down if pci_host_probe() fails. [mani: commit log]
In the Linux kernel, the following vulnerability has been resolved: USB: chaoskey: Fix slab-use-after-free in chaoskey_release() The chaoskey driver has a use-after-free bug in its release routine. If the user closes the device file after the USB device has been unplugged, a debugging log statement will try to access the usb_interface structure after it has been deallocated: BUG: KASAN: slab-use-after-free in dev_driver_string (drivers/base/core.c:2406) Read of size 8 at addr ffff888168e8a0b8 by task chaoskey_raw_re/10106 Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) dev_driver_string (drivers/base/core.c:2406) __dynamic_dev_dbg (lib/dynamic_debug.c:906) chaoskey_release (drivers/usb/misc/chaoskey.c:323) __fput (fs/file_table.c:510) fput_close_sync (fs/file_table.c:615) __x64_sys_close (fs/open.c:1507 fs/open.c:1492 fs/open.c:1492) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The driver's last reference to the interface structure is dropped in the chaoskey_free() routine, so the code must not use the interface -- even in a debugging statement -- after that routine returns. (Exception: If we know that another reference is held by someone else, such as the device core while the disconnect routine runs, there's no problem. Thanks to Johan Hovold for pointing this out.) Since the bad access is part of an unimportant debugging statement, we can fix the problem simply by removing the whole statement.
In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Suppress UBSAN warning caused by field misuse The definition of reg->access_width changes depending on the reg->space_id type. Type ACPI_ADR_SPACE_PLATFORM_COMM uses access_width to indicate the PCC region, which can result in a UBSAN if the value is greater than 4. For example: UBSAN: shift-out-of-bounds in drivers/acpi/cppc_acpi.c:1090:9 shift exponent 32 is too large for 32-bit type 'int' CPU: 61 UID: 0 PID: 1220 Comm: (udev-worker) Not tainted 7.0.10-201.fc44.aarch64 #1 PREEMPT(lazy) Hardware name: To be filled by O.E.M. Call trace: ...(trimming) ubsan_epilogue+0x10/0x48 __ubsan_handle_shift_out_of_bounds+0xdc/0x1e0 cpc_write+0x4d0/0x670 cppc_set_perf+0x18c/0x490 cppc_cpufreq_cpu_init+0x1c8/0x380 [cppc_cpufreq] ... (trimming) Lets fix this by validating the region type, as well as whether access_width has a value. Then since we are returning bit_width directly for ACPI_ADR_SPACE_PLATFORM_COMM, drop the code correcting the size.