CVSS: -EPSS: %CPEs: 9EXPL: 0CVE-2024-53197 – ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices
https://notcve.org/view.php?id=CVE-2024-53197
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices A bogus device can provide a bNumConfigurations value that exceeds the initial value used in usb_get_configuration for allocating dev->config. This can lead to out-of-bounds accesses later, e.g. in usb_destroy_configuration. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/0b4ea4bfe16566b84645ded1403756a2dc4e0f19 https://git.kernel.org/stable/c/9b8460a2a7ce478e0b625af7c56d444dc24190f7 https://git.kernel.org/stable/c/62dc01c83fa71e10446ee4c31e0e3d5d1291e865 https://git.kernel.org/stable/c/9887d859cd60727432a01564e8f91302d361b72b https://git.kernel.org/stable/c/920a369a9f014f10ec282fd298d0666129379f1b https://git.kernel.org/stable/c/b8f8b81dabe52b413fe9e062e8a852c48dd0680d https://git.kernel.org/stable/c/379d3b9799d9da953391e973b934764f0 •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2024-53196 – KVM: arm64: Don't retire aborted MMIO instruction
https://notcve.org/view.php?id=CVE-2024-53196
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Don't retire aborted MMIO instruction Returning an abort to the guest for an unsupported MMIO access is a documented feature of the KVM UAPI. Nevertheless, it's clear that this plumbing has seen limited testing, since userspace can trivially cause a WARN in the MMIO return: WARNING: CPU: 0 PID: 30558 at arch/arm64/include/asm/kvm_emulate.h:536 kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 Call trace: kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 kvm_arch_vcpu_ioctl_run+0x98/0x15b4 arch/arm64/kvm/arm.c:1133 kvm_vcpu_ioctl+0x75c/0xa78 virt/kvm/kvm_main.c:4487 __do_sys_ioctl fs/ioctl.c:51 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x1e0/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 The splat is complaining that KVM is advancing PC while an exception is pending, i.e. that KVM is retiring the MMIO instruction despite a pending synchronous external abort. Womp womp. Fix the glaring UAPI bug by skipping over all the MMIO emulation in case there is a pending synchronous exception. Note that while userspace is capable of pending an asynchronous exception (SError, IRQ, or FIQ), it is still safe to retire the MMIO instruction in this case as (1) they are by definition asynchronous, and (2) KVM relies on hardware support for pending/delivering these exceptions instead of the software state machine for advancing PC. • https://git.kernel.org/stable/c/da345174ceca052469e4775e4ae263b5f27a9355 https://git.kernel.org/stable/c/6af853cf5f897d55f42e9166f4db50e84e404fb3 https://git.kernel.org/stable/c/ea6b5d98fea4ee8cb443ea98fda520909e90d30e https://git.kernel.org/stable/c/1e46460efe1ef9a31748de7675ff8fe0d8601af2 https://git.kernel.org/stable/c/d0571c3add987bcb69c2ffd7a70c998bf8ce60fb https://git.kernel.org/stable/c/e735a5da64420a86be370b216c269b5dd8e830e2 •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2024-53195 – KVM: arm64: Get rid of userspace_irqchip_in_use
https://notcve.org/view.php?id=CVE-2024-53195
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Get rid of userspace_irqchip_in_use Improper use of userspace_irqchip_in_use led to syzbot hitting the following WARN_ON() in kvm_timer_update_irq(): WARNING: CPU: 0 PID: 3281 at arch/arm64/kvm/arch_timer.c:459 kvm_timer_update_irq+0x21c/0x394 Call trace: kvm_timer_update_irq+0x21c/0x394 arch/arm64/kvm/arch_timer.c:459 kvm_timer_vcpu_reset+0x158/0x684 arch/arm64/kvm/arch_timer.c:968 kvm_reset_vcpu+0x3b4/0x560 arch/arm64/kvm/reset.c:264 kvm_vcpu_set_target arch/arm64/kvm/arm.c:1553 [inline] kvm_arch_vcpu_ioctl_vcpu_init arch/arm64/kvm/arm.c:1573 [inline] kvm_arch_vcpu_ioctl+0x112c/0x1b3c arch/arm64/kvm/arm.c:1695 kvm_vcpu_ioctl+0x4ec/0xf74 virt/kvm/kvm_main.c:4658 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __arm64_sys_ioctl+0x108/0x184 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x78/0x1b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0xe8/0x1b0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x40/0x50 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x14c arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 The following sequence led to the scenario: - Userspace creates a VM and a vCPU. - The vCPU is initialized with KVM_ARM_VCPU_PMU_V3 during KVM_ARM_VCPU_INIT. - Without any other setup, such as vGIC or vPMU, userspace issues KVM_RUN on the vCPU. Since the vPMU is requested, but not setup, kvm_arm_pmu_v3_enable() fails in kvm_arch_vcpu_run_pid_change(). As a result, KVM_RUN returns after enabling the timer, but before incrementing 'userspace_irqchip_in_use': kvm_arch_vcpu_run_pid_change() ret = kvm_arm_pmu_v3_enable() if (!vcpu->arch.pmu.created) return -EINVAL; if (ret) return ret; [...] if (!irqchip_in_kernel(kvm)) static_branch_inc(&userspace_irqchip_in_use); - Userspace ignores the error and issues KVM_ARM_VCPU_INIT again. Since the timer is already enabled, control moves through the following flow, ultimately hitting the WARN_ON(): kvm_timer_vcpu_reset() if (timer->enabled) kvm_timer_update_irq() if (!userspace_irqchip()) ret = kvm_vgic_inject_irq() ret = vgic_lazy_init() if (unlikely(! • https://git.kernel.org/stable/c/dd2f9861f27571d47998d71e7516bf7216db0b52 https://git.kernel.org/stable/c/c16e2dba39ff6ae84bb8dc9c8e0fb21d9b2f6f5c https://git.kernel.org/stable/c/fe425d5239a28c21e0c83ee7a8f4cb210d29fdb4 https://git.kernel.org/stable/c/38d7aacca09230fdb98a34194fec2af597e8e20d •
CVSS: -EPSS: %CPEs: 9EXPL: 0CVE-2024-53194 – PCI: Fix use-after-free of slot->bus on hot remove
https://notcve.org/view.php?id=CVE-2024-53194
In the Linux kernel, the following vulnerability has been resolved: PCI: Fix use-after-free of slot->bus on hot remove Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock. Since commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") and commit 59a54c5f3dbd ("thunderbolt: Reset topology created by the boot firmware"), USB4 v2 and v1 Host Routers are reset on probe of the thunderbolt driver. The reset clears the Presence Detect State and Data Link Layer Link Active bits at the USB4 Host Router's Root Port and thus causes hot removal of the dock. The crash occurs when pciehp is unbound from one of the dock's Downstream Ports: pciehp creates a pci_slot on bind and destroys it on unbind. The pci_slot contains a pointer to the pci_bus below the Downstream Port, but a reference on that pci_bus is never acquired. The pci_bus is destroyed before the pci_slot, so a use-after-free ensues when pci_slot_release() accesses slot->bus. In principle this should not happen because pci_stop_bus_device() unbinds pciehp (and therefore destroys the pci_slot) before the pci_bus is destroyed by pci_remove_bus_device(). However the stacktrace provided by Dennis shows that pciehp is unbound from pci_remove_bus_device() instead of pci_stop_bus_device(). To understand the significance of this, one needs to know that the PCI core uses a two step process to remove a portion of the hierarchy: It first unbinds all drivers in the sub-hierarchy in pci_stop_bus_device() and then actually removes the devices in pci_remove_bus_device(). There is no precaution to prevent driver binding in-between pci_stop_bus_device() and pci_remove_bus_device(). In Dennis' case, it seems removal of the hierarchy by pciehp races with driver binding by pci_bus_add_devices(). • https://git.kernel.org/stable/c/50473dd3b2a08601a078f852ea05572de9b1f86c https://git.kernel.org/stable/c/d0ddd2c92b75a19a37c887154223372b600fed37 https://git.kernel.org/stable/c/da6e6ff1f6c57f16e07af955e0e997fc90dd1e75 https://git.kernel.org/stable/c/41bbb1eb996be1435815aa1fbcc9ffc45b84cc12 https://git.kernel.org/stable/c/20502f0b3f3acd6bee300257556c27a867f80c8b https://git.kernel.org/stable/c/e5d5c04aac71bf1476dc44b56f2206a4c2facca8 https://git.kernel.org/stable/c/c8266ab8e7ccd1d1f5a9c8b29eb2020175048134 https://git.kernel.org/stable/c/69d2ceac11acf8579d58d55c9c5b65fb6 •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2024-53193 – clk: clk-loongson2: Fix memory corruption bug in struct loongson2_clk_provider
https://notcve.org/view.php?id=CVE-2024-53193
In the Linux kernel, the following vulnerability has been resolved: clk: clk-loongson2: Fix memory corruption bug in struct loongson2_clk_provider Some heap space is allocated for the flexible structure `struct clk_hw_onecell_data` and its flexible-array member `hws` through the composite structure `struct loongson2_clk_provider` in function `loongson2_clk_probe()`, as shown below: 289 struct loongson2_clk_provider *clp; ... 296 for (p = data; p->name; p++) 297 clks_num++; 298 299 clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num), 300 GFP_KERNEL); Then some data is written into the flexible array: 350 clp->clk_data.hws[p->id] = hw; This corrupts `clk_lock`, which is the spinlock variable immediately following the `clk_data` member in `struct loongson2_clk_provider`: struct loongson2_clk_provider { void __iomem *base; struct device *dev; struct clk_hw_onecell_data clk_data; spinlock_t clk_lock; /* protect access to DIV registers */ }; The problem is that the flexible structure is currently placed in the middle of `struct loongson2_clk_provider` instead of at the end. Fix this by moving `struct clk_hw_onecell_data clk_data;` to the end of `struct loongson2_clk_provider`. Also, add a code comment to help prevent this from happening again in case new members are added to the structure in the future. This change also fixes the following -Wflex-array-member-not-at-end warning: drivers/clk/clk-loongson2.c:32:36: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] • https://git.kernel.org/stable/c/9796ec0bd04bb0e70487127d44949ca0554df5d3 https://git.kernel.org/stable/c/76918202615f2ba7deda14901d9fff528a180099 https://git.kernel.org/stable/c/145de18065b9840687d9b4e63746238c1da25d22 https://git.kernel.org/stable/c/6e4bf018bb040955da53dae9f8628ef8fcec2dbe •