Search

Search Results (412530 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-64103 1 Linux 1 Linux Kernel 2026-08-12 7.8 High
In the Linux kernel, the following vulnerability has been resolved: scsi: isci: Fix use-after-free in device removal path The ISCI completion tasklet is initialized in isci_host_alloc() (drivers/scsi/isci/init.c:496) and scheduled from both MSI-X and legacy interrupt handlers (drivers/scsi/isci/host.c:223,613). isci_host_deinit() stops the controller and waits for stop completion, but it never kills completion_tasklet before teardown continues. A top-of-function tasklet_kill() is not sufficient here: interrupts are only disabled when isci_host_stop_complete() runs, so until wait_for_stop() returns the IRQ handlers can still requeue the tasklet. The tasklet callback also re-enables interrupts after draining completions, so killing the tasklet before the source is quiesced leaves the same race open. Once wait_for_stop() returns, no further IRQ-driven scheduling can occur. Kill completion_tasklet there so teardown cannot race a queued tasklet running on a dead ihost. On remove or unload, the stale callback can otherwise dereference ihost and touch ihost->smu_registers after the host lifetime ends. A UML + KASAN analogue reproduced the failure class both with no tasklet_kill() and with tasklet_kill() placed before source quiesce, and stayed clean once the kill happened after quiescing the scheduling source. This mirrors commit f6ab594672d4 ("scsi: aic94xx: fix use-after-free in device removal path"), but ISCI needs the kill after wait_for_stop().
CVE-2026-64105 1 Linux 1 Linux Kernel 2026-08-12 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Free private_irqs when init fails after allocation Companion to commit 250f25367b58 ("KVM: arm64: Tear down vGIC on failed vCPU creation"), which added the missing kvm_vgic_vcpu_destroy() call to the kvm_share_hyp() failure path in kvm_arch_vcpu_create(). The kvm_vgic_vcpu_init() failure path immediately above it has the same shape and still needs the same cleanup. Call kvm_vgic_vcpu_destroy() when kvm_vgic_vcpu_init() fails so private IRQs allocated before a redistributor iodev registration failure are released before the failed vCPU is freed.
CVE-2026-64104 1 Linux 1 Linux Kernel 2026-08-12 8.7 High
In the Linux kernel, the following vulnerability has been resolved: virt: sev-guest: Explicitly leak pages in unknown state When set_memory_{encrypted,decrypted}() fail, the user cannot know at which point the function failed, meaning that the pages are left in an unknown state from the point of view of the caller. Since the pages may be left in an unencrypted state, they are not suitable for general use, and cannot be returned safely to the buddy allocator. Avoid the issue by never freeing the pages, and then do the proper accounting by calling snp_leak_pages().
CVE-2025-32087 2026-08-12 N/A
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused
CVE-2025-27245 2026-08-12 N/A
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused
CVE-2025-31943 2026-08-12 N/A
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused
CVE-2025-35977 2026-08-12 N/A
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused
CVE-2025-32737 2026-08-12 N/A
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused
CVE-2025-20020 2026-08-12 N/A
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused
CVE-2025-32084 2026-08-12 N/A
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused
CVE-2022-45899 1 Nokia 1 Broadcast Message Center 2026-08-12 6.5 Medium
Nokia Broadcast Message Center (BMC) before 13.1 allows an unauthenticated remote attacker to do OS command injection as root via shell metacharacters in the Log Scanner Search Pattern field.
CVE-2025-24837 2026-08-12 N/A
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused
CVE-2025-35988 2026-08-12 N/A
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused
CVE-2025-25275 2026-08-12 N/A
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused
CVE-2025-24488 2026-08-12 N/A
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused
CVE-2025-27570 2026-08-12 N/A
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused
CVE-2025-30178 2026-08-12 N/A
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused
CVE-2026-64179 1 Linux 1 Linux Kernel 2026-08-12 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: net: wwan: iosm: fix potential memory leaks in ipc_imem_init() The memory allocated in ipc_protocol_init() is not freed on the error paths that follow in ipc_imem_init(). Fix that by calling the corresponding release function ipc_protocol_deinit() in the error path.
CVE-2026-64180 1 Linux 1 Linux Kernel 2026-08-12 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: mm/memory_hotplug: fix memory block reference leak on remove Patch series "mm: Fix memory block leaks and locking", v2. This series fixes two memory block device reference leaks and one locking issue around the per-memory_block hwpoison counter. This patch (of 2): remove_memory_blocks_and_altmaps() looks up each memory block with find_memory_block(), which acquires a reference to the memory block device. That reference is never dropped on this path, resulting in a leaked device reference when removing memory blocks and their altmaps. Drop the reference after retrieving mem->altmap and clearing mem->altmap, before removing the memory block device.
CVE-2026-8982 1 Autel 2 Maxicharger Single Charger, Maxicharger Single Charger Firmware 2026-08-12 8.1 High
Two undocumented privileged accounts exist in Autel Maxi Charger Single firmware through V1.03.51. The accounts use vendor-defined password derivation mechanisms based on device-specific values, allowing an attacker with knowledge of the algorithm and required inputs to authenticate to the web management interface with administrative privileges.