CVE Vulnerability Catalog

In the Linux kernel, the qcom_battmgr driver's qcom_battmgr_sc8280xp_strcpy() copies firmware strings without guaranteeing a terminator when the firmware does not use Pascal-style strings. Fields model_number, serial_number, and oem_info may lack a null terminator, causing out-of-bounds reads when printed to userspace.

In the Linux kernel, the rt9455 power supply driver contains a use-after-free bug. During driver removal (rt9455_remove), delayed works are cancelled in the wrong order — batt_presence_work can queue max_charging_time_work after it has been cancelled, causing a dereference of the freed rt9455_info structure. The issue also occurs in the probe error path when rt9455_hw_init() fails after the IRQ has been requested.

In the Linux kernel, the twl4030_charger driver has a use-after-free. twl4030_bci_remove() does not cancel two workers (bci->work and bci->current_worker) that dereference the devm-allocated bci structure, potentially accessing freed memory after device removal.

In the Linux kernel, the ucs1002 driver has a use-after-free on removal. The driver has no remove callback, so unbind runs through devm, but devm frees the alert IRQ without cancelling the health_poll delayed work, which can then run after driver data is freed.

In the Linux kernel, the max17040 driver's max17040_get_vcell() and max17040_get_soc() ignore errors from regmap_read(). When an I2C transfer fails, the uninitialized register value is converted and reported to userspace as valid voltage or state of charge, and the polling worker can replace the cached state with a bogus value.

In the Linux kernel, the max17040 driver has a work cancellation synchronization issue on suspend. max17040_work() requeues itself after every poll, and cancel_delayed_work() does not wait for an already running callback, potentially continuing to access the fuel gauge after suspend completes.

In the Linux kernel on s390, a vulnerability in the cpum_cf (CPU performance counter) subsystem causes a kernel panic when a CPU is brought online during a perf stat run. The per-CPU data structure is not initialized if the CPU was offline when the perf event was created, leading to a NULL pointer dereference in cpumf_pmu_add().

In the Linux kernel on s390, the MVIY_PERCPU() macro generates an assembler macro invocation with whitespace-separated quoted arguments, which older binutils (before 2.39) misparse, skipping the mviy instruction. As a result, the interrupted per-CPU sequence is not marked in lowcore and the exception return path cannot repair the per-CPU address register after migration.

In the Linux kernel, the s390/dasd driver's dasd_int_handler() marked an NRF read of an unallocated ESE track as successful (DASD_CQR_SUCCESS) without checking the return value of ese_read(). When dasd_eckd_ese_read() returned an error before zeroing the destination buffer, the block layer received stale, uninitialized memory instead of zeros.

In the Linux kernel, several s390/dasd sysfs show/store handlers call a discipline callback that dereferences device->private. During dasd_generic_set_online() the discipline is assigned before check_device() allocates device->private, so an unprivileged read of one of these world-readable attributes in that window dereferences a NULL pointer and panics the kernel.

In the Linux kernel, the s390/dasd driver's dasd_default_erp_postaction() copies timing and device state from the finished ERP request back to the original request but drops proc_bytes. A partially completed request (an ESE read of a not-yet-allocated track returns fewer bytes than requested) that is then recovered through the ERP chain loses its partial-completion length, so __dasd_cleanup_cqr() sees proc_bytes == 0 and completes the whole request instead of requeueing the remainder, silently returning zeroed data for the part that was never read.

In the Linux kernel, the PCI plda driver's plda_pcie_irq_domain_deinit() removes pcie->event_domain via irq_domain_remove(), but the per-event IRQs mapped from that domain are requested with devm_request_irq() in plda_init_interrupts(). The actual free_irq() for a devm-managed IRQ is deferred by devres until after the calling probe()/remove() returns, so irq_domain_remove() can free the domain's internal data before the deferred free_irq() for IRQs still mapped into it has run, leading to a use-after-free of the already-freed domain.

In the Linux kernel, the PCI plda driver's plda_init_interrupts() initializes IRQ domains and creates IRQ mappings but does not unwind them when a later step fails. If platform_get_irq() or either irq_create_mapping() fails, the domains are never deinitialized and port->intx_irq stays initialized, leading to IRQ domain leaks.

In the Linux kernel, the iommu/amd driver's iommu_call_iopf_notifier() looks up the requester with pci_get_domain_bus_and_slot(), which returns a PCI device with its reference count incremented. Neither the successful iommu_report_device_fault() path nor the abort path drops that reference, so every handled PPR request leaks a PCI device reference.

In the Linux kernel, the iommu/msm driver's msm_iommu_probe() adds its devm-managed IOMMU object to qcom_iommu_devices before adding the IOMMU sysfs device and registering it with the IOMMU core. If iommu_device_sysfs_add() or iommu_device_register() fails, the object remains on qcom_iommu_devices while the driver core releases the devm allocation, leaving a dangling list entry that later list walks may dereference.

In the Linux kernel, the iommu/sva driver's iommu_attach_device_pasid() installs the new SVA attach handle in the group PASID lookup before iommu_sva_bind_device() returns. A concurrent bind can therefore find and reuse the same handle after iommu_sva_lock is dropped. handle->dev was initialized after dropping iommu_sva_lock, leaving a window where a racing bind can return a handle whose dev pointer is still NULL, and a subsequent iommu_sva_unbind_device() can dereference it via handle->dev->iommu_group.

In the Linux kernel, the iommu/tegra241-cmdqv driver's tegra241_vintf_init_vsid() programs the guest-provided vSID into SID_MATCH, whose VIRT_SID field spans bits [20:1] with bit 0 as the match-enable flag, so the hardware matches only a 20-bit Stream ID. The bound check rejects only virt_sid > UINT_MAX, admitting a value far wider than the field; the write "virt_sid << 1 | 0x1" then drops every bit above 20, so a virt_sid of 0x80000000 lands as SID_MATCH = 0x1, a valid match on vSID 0, aliasing the wrong Stream ID. Because vdev->virt_id is guest-controlled, a VMM can trigger it.

A memory leak exists in the Linux kernel's iommu_mock_device_add() function. When the subsequent device_add() call fails, the error path only frees fwspec but leaves the dev->iommu structure allocated. The fix replaces iommu_fwspec_free() with dev_iommu_free() in the failure path.

In the Linux kernel, detect_intel_iommu() did not include tboot in the conditions for requesting ACS, potentially causing a misconfiguration with ACS disabled while IOMMU is later forced on by tboot_force_iommu(). The fix adds a tboot check in detect_intel_iommu().

In the Linux kernel, iommufd_access_notify_unmap() skips internal accesses but calls iommufd_lock_obj() first; on success the loop skips the matching iommufd_put_object(), leaking the object reference. The fix checks for internal accesses before locking.