CVE-2024-49981 in Linux
Summary
by MITRE • 10/21/2024
In the Linux kernel, the following vulnerability has been resolved:
media: venus: fix use after free bug in venus_remove due to race condition
in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify.
If we call venus_remove, there might be an unfished work. The possible sequence is as follows:
CPU0 CPU1
|venus_sys_error_handler venus_remove | hfi_destroy | venus_hfi_destroy | kfree(hdev); | |hfi_reinit |venus_hfi_queues_reinit |//use hdev
Fix it by canceling the work in venus_remove.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 03/21/2026
The vulnerability described in CVE-2024-49981 represents a critical use-after-free condition within the Linux kernel's venus media driver subsystem, specifically affecting the Qualcomm Venus video codec driver used in mobile devices and embedded systems. This flaw manifests as a race condition during the device removal process, where the kernel's media subsystem fails to properly synchronize asynchronous work operations before freeing critical memory resources. The venus driver is responsible for handling video encoding and decoding operations on Qualcomm SoCs, making this vulnerability particularly concerning for mobile and embedded platforms where these codecs are extensively utilized.
The technical implementation of this vulnerability stems from improper synchronization mechanisms within the venus driver's error handling framework. During normal operation, the venus_probe function establishes a work queue structure bound to the venus_sys_error_handler callback function, which serves as the primary error handling mechanism for the driver. The driver utilizes core->sys_err_done as a synchronization primitive to manage the completion of error handling operations, while core->work represents the asynchronous work item that processes system errors. The work queue is initiated through venus_event_notify, creating a complex interaction pattern between device initialization, error handling, and resource management operations.
The race condition occurs specifically during the venus_remove function execution, where the driver attempts to clean up resources while asynchronous error handling work items may still be in progress or pending execution. The problematic execution sequence demonstrates how CPU0 can initiate venus_remove while CPU1 executes venus_sys_error_handler, leading to a scenario where hfi_destroy operations complete and hdev memory is freed, but subsequent error handler execution attempts to access the already-freed hdev structure. This creates a classic use-after-free vulnerability that can lead to memory corruption, potential privilege escalation, or system instability, as the error handler function venus_hfi_queues_reinit attempts to access the freed hdev structure during hfi_reinit operations.
The vulnerability directly maps to CWE-416, which describes the use of freed memory condition, and represents a failure in proper resource management and synchronization protocols within kernel space code. From an operational perspective, this vulnerability can be exploited by malicious actors to gain unauthorized access to system resources or cause denial of service conditions, particularly affecting devices running Android or other Linux-based systems that utilize Qualcomm's Venus video codecs. The ATT&CK framework categorizes this vulnerability under privilege escalation and denial of service techniques, as successful exploitation could allow attackers to execute arbitrary code with kernel privileges or disrupt video processing functionality.
Mitigation strategies for this vulnerability require immediate application of kernel patches that properly cancel pending work items before resource cleanup operations commence. The fix implemented in the resolution involves adding explicit work cancellation mechanisms within venus_remove to ensure all pending error handling operations complete or are canceled before hdev memory is freed. System administrators should prioritize applying the latest kernel updates from their respective distributions, particularly focusing on kernel versions containing the specific venus driver patches. Additionally, monitoring systems should be configured to detect unusual error handling patterns or device removal sequences that might indicate exploitation attempts. The vulnerability highlights the importance of proper asynchronous work queue management in kernel drivers and the critical need for race condition prevention mechanisms in concurrent system programming environments.