Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix null check for pipe_ctx-&gt;plane_state in hwss_setup_dpp<br /> <br /> This commit addresses a null pointer dereference issue in<br /> hwss_setup_dpp(). The issue could occur when pipe_ctx-&gt;plane_state is<br /> null. The fix adds a check to ensure `pipe_ctx-&gt;plane_state` is not null<br /> before accessing. This prevents a null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: imx-audmix: Add NULL check in imx_audmix_probe<br /> <br /> devm_kasprintf() can return a NULL pointer on failure,but this<br /> returned value in imx_audmix_probe() is not checked.<br /> Add NULL check in imx_audmix_probe(), to handle kernel NULL<br /> pointer dereference error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware_loader: Fix possible resource leak in fw_log_firmware_info()<br /> <br /> The alg instance should be released under the exception path, otherwise<br /> there may be resource leak here.<br /> <br /> To mitigate this, free the alg instance with crypto_free_shash when kmalloc<br /> fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Get rid of userspace_irqchip_in_use<br /> <br /> Improper use of userspace_irqchip_in_use led to syzbot hitting the<br /> following WARN_ON() in kvm_timer_update_irq():<br /> <br /> WARNING: CPU: 0 PID: 3281 at arch/arm64/kvm/arch_timer.c:459<br /> kvm_timer_update_irq+0x21c/0x394<br /> Call trace:<br /> kvm_timer_update_irq+0x21c/0x394 arch/arm64/kvm/arch_timer.c:459<br /> kvm_timer_vcpu_reset+0x158/0x684 arch/arm64/kvm/arch_timer.c:968<br /> kvm_reset_vcpu+0x3b4/0x560 arch/arm64/kvm/reset.c:264<br /> kvm_vcpu_set_target arch/arm64/kvm/arm.c:1553 [inline]<br /> kvm_arch_vcpu_ioctl_vcpu_init arch/arm64/kvm/arm.c:1573 [inline]<br /> kvm_arch_vcpu_ioctl+0x112c/0x1b3c arch/arm64/kvm/arm.c:1695<br /> kvm_vcpu_ioctl+0x4ec/0xf74 virt/kvm/kvm_main.c:4658<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl fs/ioctl.c:893 [inline]<br /> __arm64_sys_ioctl+0x108/0x184 fs/ioctl.c:893<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x78/0x1b8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0xe8/0x1b0 arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x40/0x50 arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x54/0x14c arch/arm64/kernel/entry-common.c:712<br /> el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730<br /> el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598<br /> <br /> The following sequence led to the scenario:<br /> - Userspace creates a VM and a vCPU.<br /> - The vCPU is initialized with KVM_ARM_VCPU_PMU_V3 during<br /> KVM_ARM_VCPU_INIT.<br /> - Without any other setup, such as vGIC or vPMU, userspace issues<br /> KVM_RUN on the vCPU. Since the vPMU is requested, but not setup,<br /> kvm_arm_pmu_v3_enable() fails in kvm_arch_vcpu_run_pid_change().<br /> As a result, KVM_RUN returns after enabling the timer, but before<br /> incrementing &amp;#39;userspace_irqchip_in_use&amp;#39;:<br /> kvm_arch_vcpu_run_pid_change()<br /> ret = kvm_arm_pmu_v3_enable()<br /> if (!vcpu-&gt;arch.pmu.created)<br /> return -EINVAL;<br /> if (ret)<br /> return ret;<br /> [...]<br /> if (!irqchip_in_kernel(kvm))<br /> static_branch_inc(&amp;userspace_irqchip_in_use);<br /> - Userspace ignores the error and issues KVM_ARM_VCPU_INIT again.<br /> Since the timer is already enabled, control moves through the<br /> following flow, ultimately hitting the WARN_ON():<br /> kvm_timer_vcpu_reset()<br /> if (timer-&gt;enabled)<br /> kvm_timer_update_irq()<br /> if (!userspace_irqchip())<br /> ret = kvm_vgic_inject_irq()<br /> ret = vgic_lazy_init()<br /> if (unlikely(!vgic_initialized(kvm)))<br /> if (kvm-&gt;arch.vgic.vgic_model !=<br /> KVM_DEV_TYPE_ARM_VGIC_V2)<br /> return -EBUSY;<br /> WARN_ON(ret);<br /> <br /> Theoretically, since userspace_irqchip_in_use&amp;#39;s functionality can be<br /> simply replaced by &amp;#39;!irqchip_in_kernel()&amp;#39;, get rid of the static key<br /> to avoid the mismanagement, which also helps with the syzbot issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Don&amp;#39;t retire aborted MMIO instruction<br /> <br /> Returning an abort to the guest for an unsupported MMIO access is a<br /> documented feature of the KVM UAPI. Nevertheless, it&amp;#39;s clear that this<br /> plumbing has seen limited testing, since userspace can trivially cause a<br /> WARN in the MMIO return:<br /> <br /> 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<br /> Call trace:<br /> kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536<br /> kvm_arch_vcpu_ioctl_run+0x98/0x15b4 arch/arm64/kvm/arm.c:1133<br /> kvm_vcpu_ioctl+0x75c/0xa78 virt/kvm/kvm_main.c:4487<br /> __do_sys_ioctl fs/ioctl.c:51 [inline]<br /> __se_sys_ioctl fs/ioctl.c:893 [inline]<br /> __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0x1e0/0x23c arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712<br /> el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730<br /> el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598<br /> <br /> The splat is complaining that KVM is advancing PC while an exception is<br /> pending, i.e. that KVM is retiring the MMIO instruction despite a<br /> pending synchronous external abort. Womp womp.<br /> <br /> Fix the glaring UAPI bug by skipping over all the MMIO emulation in<br /> case there is a pending synchronous exception. Note that while userspace<br /> is capable of pending an asynchronous exception (SError, IRQ, or FIQ),<br /> it is still safe to retire the MMIO instruction in this case as (1) they<br /> are by definition asynchronous, and (2) KVM relies on hardware support<br /> for pending/delivering these exceptions instead of the software state<br /> machine for advancing PC.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen: Fix the issue of resource not being properly released in xenbus_dev_probe()<br /> <br /> This patch fixes an issue in the function xenbus_dev_probe(). In the<br /> xenbus_dev_probe() function, within the if (err) branch at line 313, the<br /> program incorrectly returns err directly without releasing the resources<br /> allocated by err = drv-&gt;probe(dev, id). As the return value is non-zero,<br /> the upper layers assume the processing logic has failed. However, the probe<br /> operation was performed earlier without a corresponding remove operation.<br /> Since the probe actually allocates resources, failing to perform the remove<br /> operation could lead to problems.<br /> <br /> To fix this issue, we followed the resource release logic of the<br /> xenbus_dev_remove() function by adding a new block fail_remove before the<br /> fail_put block. After entering the branch if (err) at line 313, the<br /> function will use a goto statement to jump to the fail_remove block,<br /> ensuring that the previously acquired resources are correctly released,<br /> thus preventing the reference count leak.<br /> <br /> This bug was identified by an experimental static analysis tool developed<br /> by our team. The tool specializes in analyzing reference count operations<br /> and detecting potential issues where resources are not properly managed.<br /> In this case, the tool flagged the missing release operation as a<br /> potential problem, which led to the development of this patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Fix use-after-free of slot-&gt;bus on hot remove<br /> <br /> Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock.<br /> <br /> Since commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") and<br /> commit 59a54c5f3dbd ("thunderbolt: Reset topology created by the boot<br /> firmware"), USB4 v2 and v1 Host Routers are reset on probe of the<br /> thunderbolt driver.<br /> <br /> The reset clears the Presence Detect State and Data Link Layer Link Active<br /> bits at the USB4 Host Router&amp;#39;s Root Port and thus causes hot removal of the<br /> dock.<br /> <br /> The crash occurs when pciehp is unbound from one of the dock&amp;#39;s Downstream<br /> Ports: pciehp creates a pci_slot on bind and destroys it on unbind. The<br /> pci_slot contains a pointer to the pci_bus below the Downstream Port, but<br /> a reference on that pci_bus is never acquired. The pci_bus is destroyed<br /> before the pci_slot, so a use-after-free ensues when pci_slot_release()<br /> accesses slot-&gt;bus.<br /> <br /> In principle this should not happen because pci_stop_bus_device() unbinds<br /> pciehp (and therefore destroys the pci_slot) before the pci_bus is<br /> destroyed by pci_remove_bus_device().<br /> <br /> However the stacktrace provided by Dennis shows that pciehp is unbound from<br /> pci_remove_bus_device() instead of pci_stop_bus_device(). To understand<br /> the significance of this, one needs to know that the PCI core uses a two<br /> step process to remove a portion of the hierarchy: It first unbinds all<br /> drivers in the sub-hierarchy in pci_stop_bus_device() and then actually<br /> removes the devices in pci_remove_bus_device(). There is no precaution to<br /> prevent driver binding in-between pci_stop_bus_device() and<br /> pci_remove_bus_device().<br /> <br /> In Dennis&amp;#39; case, it seems removal of the hierarchy by pciehp races with<br /> driver binding by pci_bus_add_devices(). pciehp is bound to the<br /> Downstream Port after pci_stop_bus_device() has run, so it is unbound by<br /> pci_remove_bus_device() instead of pci_stop_bus_device(). Because the<br /> pci_bus has already been destroyed at that point, accesses to it result in<br /> a use-after-free.<br /> <br /> One might conclude that driver binding needs to be prevented after<br /> pci_stop_bus_device() has run. However it seems risky that pci_slot points<br /> to pci_bus without holding a reference. Solely relying on correct ordering<br /> of driver unbind versus pci_bus destruction is certainly not defensive<br /> programming.<br /> <br /> If pci_slot has a need to access data in pci_bus, it ought to acquire a<br /> reference. Amend pci_create_slot() accordingly. Dennis reports that the<br /> crash is not reproducible with this change.<br /> <br /> Abridged stacktrace:<br /> <br /> pcieport 0000:00:07.0: PME: Signaling with IRQ 156<br /> pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+<br /> pci_bus 0000:20: dev 00, created physical slot 12<br /> pcieport 0000:00:07.0: pciehp: Slot(12): Card not present<br /> ...<br /> pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0<br /> Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1<br /> RIP: 0010:dev_driver_string+0x12/0x40<br /> pci_destroy_slot<br /> pciehp_remove<br /> pcie_port_remove_service<br /> device_release_driver_internal<br /> bus_remove_device<br /> device_del<br /> device_unregister<br /> remove_iter<br /> device_for_each_child<br /> pcie_portdrv_remove<br /> pci_device_remove<br /> device_release_driver_internal<br /> bus_remove_device<br /> device_del<br /> pci_remove_bus_device (recursive invocation)<br /> pci_remove_bus_device<br /> pciehp_unconfigure_device<br /> pciehp_disable_slot<br /> pciehp_handle_presence_or_link_change<br /> pciehp_ist

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices<br /> <br /> A bogus device can provide a bNumConfigurations value that exceeds the<br /> initial value used in usb_get_configuration for allocating dev-&gt;config.<br /> <br /> This can lead to out-of-bounds accesses later, e.g. in<br /> usb_destroy_configuration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix warning when unbinding<br /> <br /> If there is an error during some initialization related to firmware,<br /> the buffers dp-&gt;tx_ring[i].tx_status are released.<br /> However this is released again when the device is unbinded (ath12k_pci),<br /> and we get:<br /> WARNING: CPU: 0 PID: 2098 at mm/slub.c:4689 free_large_kmalloc+0x4d/0x80<br /> Call Trace:<br /> free_large_kmalloc<br /> ath12k_dp_free<br /> ath12k_core_deinit<br /> ath12k_pci_remove<br /> ...<br /> <br /> The issue is always reproducible from a VM because the MSI addressing<br /> initialization is failing.<br /> <br /> In order to fix the issue, just set the buffers to NULL after releasing in<br /> order to avoid the double free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix crash when unbinding<br /> <br /> If there is an error during some initialization related to firmware,<br /> the function ath12k_dp_cc_cleanup is called to release resources.<br /> However this is released again when the device is unbinded (ath12k_pci),<br /> and we get:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> at RIP: 0010:ath12k_dp_cc_cleanup.part.0+0xb6/0x500 [ath12k]<br /> Call Trace:<br /> ath12k_dp_cc_cleanup<br /> ath12k_dp_free<br /> ath12k_core_deinit<br /> ath12k_pci_remove<br /> ...<br /> <br /> The issue is always reproducible from a VM because the MSI addressing<br /> initialization is failing.<br /> <br /> In order to fix the issue, just set to NULL the released structure in<br /> ath12k_dp_cc_cleanup at the end.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: check for overflows in io_pin_pages<br /> <br /> WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144<br /> CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0<br /> Call Trace:<br /> <br /> __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183<br /> io_rings_map io_uring/io_uring.c:2611 [inline]<br /> io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470<br /> io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692<br /> io_uring_setup io_uring/io_uring.c:3781 [inline]<br /> ...<br /> <br /> <br /> io_pin_pages()&amp;#39;s uaddr parameter came directly from the user and can be<br /> garbage. Don&amp;#39;t just add size to it as it can overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan<br /> <br /> The channels array in the cfg80211_scan_request has a __counted_by<br /> attribute attached to it, which points to the n_channels variable. This<br /> attribute is used in bounds checking, and if it is not set before the<br /> array is filled, then the bounds sanitizer will issue a warning or a<br /> kernel panic if CONFIG_UBSAN_TRAP is set.<br /> <br /> This patch sets the size of allocated memory as the initial value for<br /> n_channels. It is updated with the actual number of added elements after<br /> the array is filled.