CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-53198 – xen: Fix the issue of resource not being properly released in xenbus_dev_probe()
https://notcve.org/view.php?id=CVE-2024-53198
In the Linux kernel, the following vulnerability has been resolved: xen: Fix the issue of resource not being properly released in xenbus_dev_probe() This patch fixes an issue in the function xenbus_dev_probe(). In the xenbus_dev_probe() function, within the if (err) branch at line 313, the program incorrectly returns err directly without releasing the resources allocated by err = drv->probe(dev, id). As the return value is non-zero, the upper layers assume the processing logic has failed. However, the probe operation was performed earlier without a corresponding remove operation. Since the probe actually allocates resources, failing to perform the remove operation could lead to problems. To fix this issue, we followed the resource release logic of the xenbus_dev_remove() function by adding a new block fail_remove before the fail_put block. After entering the branch if (err) at line 313, the function will use a goto statement to jump to the fail_remove block, ensuring that the previously acquired resources are correctly released, thus preventing the reference count leak. This bug was identified by an experimental static analysis tool developed by our team. • https://git.kernel.org/stable/c/4bac07c993d03434ea902d3d4290d9e45944b66c https://git.kernel.org/stable/c/87106169b4ce26f85561f953d13d1fd86d99b612 https://git.kernel.org/stable/c/0aa9e30b5b4af5dd504801689d6d84c584290a45 https://git.kernel.org/stable/c/e8823e6ff313465910edea07581627d85e68d9fd https://git.kernel.org/stable/c/3fc0996d2fefe61219375fd650601724b8cf2d30 https://git.kernel.org/stable/c/804b96f8d0a02fa10b92f28b2e042f9128ed3ffc https://git.kernel.org/stable/c/217bdce88b104269b73603b84d0ab4dd04f481bc https://git.kernel.org/stable/c/2f977a4c82d35d063f5fe198bbc501c4b •
CVSS: -EPSS: 0%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: 0%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: 0%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: 0%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 •