Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ture 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] Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/76918202615f2ba7deda14901d9fff528a
Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/76918202615f2ba7deda14901d9fff528a180099 - https://git.kernel.org/stable/c/145de18065b9840687d9b4e63746238c1da25d22 - https://git.kernel.org/stable/c/6e4bf018bb040955da53dae9f8628ef8fcec2dbe
CVE ID: CVE-2024-53194 State: PUBLISHED Published: 2024-12-27T13:49:36.534Z Last Updated: 2025-11-03T20:47:25.631Z Vendors: Linux Products: Linux Description: 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 th
e 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_rem
se 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 t
vent 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(). pciehp is bound to the Downstream Port after pci_stop_bus_device() has run, so it is unbound by pci_remove_bus_device() instead of pci_stop_bus_device(). Because the pci_bus has already been destroyed at that point, accesses to it result in a use-after-free. One might conclude that driver binding needs to be prevented after pci_stop_bus_device() has run. However it seems risky that pci_slot points to pci_bus without holding a reference. Solely relying on correct ordering of driver unbind versus pci_b
pci_slot points to pci_bus without holding a reference. Solely relying on correct ordering of driver unbind versus pci_bus destruction is certainly not defensive programming. If pci_slot has a need to access data in pci_bus, it ought to acquire a reference. Amend pci_create_slot() accordingly. Dennis reports that the crash is not reproducible with this change. Abridged stacktrace: pcieport 0000:00:07.0: PME: Signaling with IRQ 156 pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ pci_bus 0000:20: dev 00, created physical slot 12 pcieport 0000:00:07.0: pciehp: Slot(12): Card not present ... pcieport 0000
us 0000:20: dev 00, created physical slot 12 pcieport 0000:00:07.0: pciehp: Slot(12): Card not present ... pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0 Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1 RIP: 0010:dev_driver_string+0x12/0x40 pci_destroy_slot pciehp_remove pcie_port_remove_service device_release_driver_internal bus_remove_device device_del device_unregister remove_iter device_for_each_child pcie_portdrv_remove pci_device_remove device_release_driver_internal bus_remove_device device_del pci_remove_bus_dev
ild pcie_portdrv_remove pci_device_remove device_release_driver_internal bus_remove_device device_del pci_remove_bus_device (recursive invocation) pci_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - 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/20502f0b3f3acd
ttps://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/69d2ceac11acf8579d58d55c9c5b65fb658f916e - https://git.kernel.org/stable/c/c7acef99642b763ba585f4a43af999fcdbcc3dc4
CVE ID: CVE-2024-53195 State: PUBLISHED Published: 2024-12-27T13:49:37.514Z Last Updated: 2025-05-04T09:55:29.159Z Vendors: Linux Products: Linux Description: 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 a
+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/sy
/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
ted, 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() re
m_timer_vcpu_reset() if (timer->enabled) kvm_timer_update_irq() if (!userspace_irqchip()) ret = kvm_vgic_inject_irq() ret = vgic_lazy_init() if (unlikely(!vgic_initialized(kvm))) if (kvm->arch.vgic.vgic_model != KVM_DEV_TYPE_ARM_VGIC_V2) return -EBUSY; WARN_ON(ret); Theoretically, since userspace_irqchip_in_use's functionality can be simply replaced by '!irqchip_in_kernel()', get rid of the static key to avoid the mismanagement, which also helps with the syzbot issue. References: - https://git.kernel.org/stable/c/dd2f9861f27571d47998d71e7516bf7216db0b52 - https://git.kernel.org/stable/c/c16e2dba39ff6ae84bb8dc9c8e0fb21d9b2f6f5c - https://git.kernel.org/stable/c/fe425d5239a28c21e0c83ee7a8f4cb2
.org/stable/c/c16e2dba39ff6ae84bb8dc9c8e0fb21d9b2f6f5c - https://git.kernel.org/stable/c/fe425d5239a28c21e0c83ee7a8f4cb210d29fdb4 - https://git.kernel.org/stable/c/38d7aacca09230fdb98a34194fec2af597e8e20d
CVE ID: CVE-2024-53196 State: PUBLISHED Published: 2024-12-27T13:49:38.501Z Last Updated: 2025-11-03T20:47:27.048Z Vendors: Linux Products: Linux Description: 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+0x46
: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_h
_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 a
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. Additional Analyst Notes: - CVE Program Container: References: - 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/e735a5da64420a86b
s://git.kernel.org/stable/c/d0571c3add987bcb69c2ffd7a70c998bf8ce60fb - https://git.kernel.org/stable/c/e735a5da64420a86be370b216c269b5dd8e830e2
CVE ID: CVE-2024-53197 State: PUBLISHED Published: 2024-12-27T13:49:39.260Z Last Updated: 2025-11-03T20:47:29.910Z Vendors: Linux Products: Linux Description: 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. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/0b4ea4bfe16566b84645ded1403756a2dc4e0f19 - ht
nt: - CVE Program Container: References: - 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/379d3b9799d9da953391e973b934764f01e03960 - https://git.kernel.org/stable/c/b521b53ac6eb04e41c03f46f7fe452e4d8e9bcca - https://git.kernel.org/stable/c/b909df18ce2a998afef81d58b
kernel.org/stable/c/b521b53ac6eb04e41c03f46f7fe452e4d8e9bcca - https://git.kernel.org/stable/c/b909df18ce2a998afef81d58bbd1a05dc0788c40
CVE ID: CVE-2024-53198 State: PUBLISHED Published: 2024-12-27T13:49:40.339Z Last Updated: 2025-11-03T20:47:32.708Z Vendors: Linux Products: Linux Description: 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 earl
ue 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 expe
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. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/87106169b4ce26f85561f953d13d1fd86d99b612 - https://git.kernel.org/stable/c/0aa9e30b5b4af5dd504801689d6d84c584290a45 - https://git.kernel.org/s
53d13d1fd86d99b612 - 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/2f977a4c82d35d063f5fe198bbc501c4b1c5ea0e - https://git.kernel.org/stable/c/afc545da381ba0c651b2658966ac737032676f01
CVE ID: CVE-2024-53199 State: PUBLISHED Published: 2024-12-27T13:49:41.237Z Last Updated: 2025-10-01T20:07:20.463Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: imx-audmix: Add NULL check in imx_audmix_probe devm_kasprintf() can return a NULL pointer on failure,but this returned value in imx_audmix_probe() is not checked. Add NULL check in imx_audmix_probe(), to handle kernel NULL pointer dereference error. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/c040cbe2e13da6454ae4748e04e53d885e1c9603 - https://git.kernel.org/stable/c/dc5aa71f39b44d8117b2417dafd0e2884a75dd37 - ht
c040cbe2e13da6454ae4748e04e53d885e1c9603 - https://git.kernel.org/stable/c/dc5aa71f39b44d8117b2417dafd0e2884a75dd37 - https://git.kernel.org/stable/c/e038f43edaf0083f6aa7c9415d86cf28dfd152f9
CVE ID: CVE-2024-53200 State: PUBLISHED Published: 2024-12-27T13:49:42.064Z Last Updated: 2025-10-01T20:07:20.303Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix null check for pipe_ctx->plane_state in hwss_setup_dpp This commit addresses a null pointer dereference issue in hwss_setup_dpp(). The issue could occur when pipe_ctx->plane_state is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/020002c76147ecfdafe95c44abd3240e216b631
st Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/020002c76147ecfdafe95c44abd3240e216b6316 - https://git.kernel.org/stable/c/0dd3d1de7a5957804ccd58c1b252f9e34710e3f6 - https://git.kernel.org/stable/c/95792a18da0795300e15075ac05d1915e9066999 - https://git.kernel.org/stable/c/2bc96c95070571c6c824e0d4c7783bee25a37876
CVE ID: CVE-2024-53201 State: PUBLISHED Published: 2024-12-27T13:49:42.960Z Last Updated: 2025-10-01T20:07:20.167Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in dcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ("drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe") partially fixed the null pointer dereference issue. However, in dcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, and plane_state is accessed again through pipe_ctx. Multiple if statem
dchubp_dpp(), the variable pipe_ctx is passed in, and plane_state is accessed again through pipe_ctx. Multiple if statements directly call attributes of plane_state, leading to potential null pointer dereference issues. This patch adds necessary null checks to ensure stability. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/6b4ee2560d4d8de2688da68cd9581177035e0876 - https://git.kernel.org/stable/c/3609259326171cd5b98462636580fb2ae5c87d40 - https://git.kernel.org/stable/c/6a057072ddd127255350357dd880903e8fa23f36
CVE ID: CVE-2024-53202 State: PUBLISHED Published: 2024-12-27T13:49:48.678Z Last Updated: 2025-10-01T20:07:20.042Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Fix possible resource leak in fw_log_firmware_info() The alg instance should be released under the exception path, otherwise there may be resource leak here. To mitigate this, free the alg instance with crypto_free_shash when kmalloc fails. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/789a72498d32f88d24371c10985aceb46397056c - https://git.kernel.org/stable/c/eb5d67d00ad17a5bd0920f455160dc2ccbd2dc78 -
c/789a72498d32f88d24371c10985aceb46397056c - https://git.kernel.org/stable/c/eb5d67d00ad17a5bd0920f455160dc2ccbd2dc78 - https://git.kernel.org/stable/c/f380f895dbb2a11d62ca6df9e82d995f4bc26b84 - https://git.kernel.org/stable/c/369a9c046c2fdfe037f05b43b84c386bdbccc103
CVE ID: CVE-2024-53203 State: PUBLISHED Published: 2024-12-27T13:49:49.484Z Last Updated: 2025-11-03T19:32:02.153Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential array underflow in ucsi_ccg_sync_control() The "command" variable can be controlled by the user via debugfs. The worry is that if con_index is zero then "&uc->ucsi->connector[con_index - 1]" would be an array underflow. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/627c2a5056aba42a8a96a8fffe8996aeccf919a9 - https://git.kernel.org/stable/c/e15fd96c0b701c53f9006bcc836eaeb35a05a023 - https://git.
aba42a8a96a8fffe8996aeccf919a9 - https://git.kernel.org/stable/c/e15fd96c0b701c53f9006bcc836eaeb35a05a023 - https://git.kernel.org/stable/c/e44189455c62469eb91d383ce9103d54c1f807a3 - https://git.kernel.org/stable/c/0e66fd8e5a2e45c7dacfc9178ba702153f4a61a8 - https://git.kernel.org/stable/c/ef92cd55289a282910575c5b9d87f646f2d39b38 - https://git.kernel.org/stable/c/56971710cd541f2f05160a84b3183477d34a1be9 - https://git.kernel.org/stable/c/e56aac6e5a25630645607b6856d4b2a17b2311a5
CVE ID: CVE-2024-53204 State: PUBLISHED Published: 2024-12-27T13:49:50.268Z Last Updated: 2025-05-04T09:55:44.800Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: phy: realtek: usb: fix NULL deref in rtk_usb3phy_probe In rtk_usb3phy_probe() devm_kzalloc() may return NULL but this returned value is not checked. References: - https://git.kernel.org/stable/c/e27877990e54bfe4246dd850f7ec8646c999ce58 - https://git.kernel.org/stable/c/258ea41c926b7b3a16d0d7aa210a1401c4a1601b - https://git.kernel.org/stable/c/48d52d3168749e10c1c37cd4ceccd18625851741 - https://git.kernel.org/stable/c/776f13ad1f88485206f1dca5ef138553106950e5 - https://gi
68749e10c1c37cd4ceccd18625851741 - https://git.kernel.org/stable/c/776f13ad1f88485206f1dca5ef138553106950e5 - https://git.kernel.org/stable/c/bf373d2919d98f3d1fe1b19a0304f72fe74386d9
CVE ID: CVE-2024-53205 State: PUBLISHED Published: 2024-12-27T13:49:51.353Z Last Updated: 2025-05-04T09:55:46.420Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: phy: realtek: usb: fix NULL deref in rtk_usb2phy_probe In rtk_usb2phy_probe() devm_kzalloc() may return NULL but this returned value is not checked. References: - https://git.kernel.org/stable/c/7e2cde1813418b39b5e95d86e10d6701dccf18af - https://git.kernel.org/stable/c/7a784bcdd7e54f0599da3b2360e472238412623e - https://git.kernel.org/stable/c/0b398b6b6c94315fd2ce3658e3cee96539dbd7b7 - https://git.kernel.org/stable/c/fb83c9a08324e37f321ffb400809aa4310387d65 - https://gi
6c94315fd2ce3658e3cee96539dbd7b7 - https://git.kernel.org/stable/c/fb83c9a08324e37f321ffb400809aa4310387d65 - https://git.kernel.org/stable/c/04e3e9188291a183b27306ddb833722c0d083d6a