VYPR
Unrated severityNVD Advisory· Published Oct 18, 2025· Updated Apr 15, 2026

CVE-2025-40001

CVE-2025-40001

Description

In the Linux kernel, the following vulnerability has been resolved:

scsi: mvsas: Fix use-after-free bugs in mvs_work_queue

During the detaching of Marvell's SAS/SATA controller, the original code calls cancel_delayed_work() in mvs_free() to cancel the delayed work item mwq->work_q. However, if mwq->work_q is already running, the cancel_delayed_work() may fail to cancel it. This can lead to use-after-free scenarios where mvs_free() frees the mvs_info while mvs_work_queue() is still executing and attempts to access the already-freed mvs_info.

A typical race condition is illustrated below:

CPU 0 (remove) | CPU 1 (delayed work callback) mvs_pci_remove() | mvs_free() | mvs_work_queue() cancel_delayed_work() | kfree(mvi) | | mvi-> // UAF

Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled and any executing delayed work item completes before the mvs_info is deallocated.

This bug was found by static analysis.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

A use-after-free vulnerability in the Linux kernel's mvsas driver can be triggered during controller detach if a delayed work item races with resource cleanup.

Root

Cause

The vulnerability resides in the mvsas driver for Marvell SAS/SATA controllers. During device removal, the function mvs_free() calls cancel_delayed_work() to stop a delayed work item (mwq->work_q). However, if that work item is already running on another CPU, cancel_delayed_work() may return before the work function completes. This creates a race condition where mvs_free() can kfree the mvs_info structure while mvs_work_queue() is still executing and subsequently accesses freed memory [CVE description].

Exploitation

Prerequisites

Exploitation requires the attacker to have the ability to trigger a device detach (e.g., via hot-unplug or PCI removal) while the delayed work is executing. No special privileges beyond local access are needed, as the race can be induced through normal device removal operations. The vulnerability was found through static analysis, indicating it is a real but potentially difficult race to trigger in practice [CVE description].

Impact

If the race is won, an attacker can cause a use-after-free condition. This can lead to memory corruption, system crash (denial of service), or, in theory, arbitrary code execution if the freed memory is repurposed with controlled data. The risk is heightened in multi-core environments where the work queue can execute concurrently with the removal path [CVE description].

Mitigation

The fix replaces cancel_delayed_work() with cancel_delayed_work_sync(), which waits for any currently executing work item to finish before returning. This ensures that the mvs_info structure is not freed while the work function is still active. The patch has been applied to the stable kernel tree [1][2][3][4]. Users should update to a kernel containing the fix to prevent this vulnerability.

AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

1

Patches

8

Vulnerability mechanics

Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

8

News mentions

0

No linked articles in our index yet.