CVE-2024-43891 in Linux
Summary
by MITRE • 08/26/2024
In the Linux kernel, the following vulnerability has been resolved:
tracing: Have format file honor EVENT_FILE_FL_FREED
When eventfs was introduced, special care had to be done to coordinate the freeing of the file meta data with the files that are exposed to user space. The file meta data would have a ref count that is set when the file is created and would be decremented and freed after the last user that opened the file closed it. When the file meta data was to be freed, it would set a flag (EVENT_FILE_FL_FREED) to denote that the file is freed, and any new references made (like new opens or reads) would fail as it is marked freed. This allowed other meta data to be freed after this flag was set (under the event_mutex).
All the files that were dynamically created in the events directory had a pointer to the file meta data and would call event_release() when the last reference to the user space file was closed. This would be the time that it is safe to free the file meta data.
A shortcut was made for the "format" file. It's i_private would point to the "call" entry directly and not point to the file's meta data. This is because all format files are the same for the same "call", so it was thought there was no reason to differentiate them. The other files maintain state (like the "enable", "trigger", etc). But this meant if the file were to disappear, the "format" file would be unaware of it.
This caused a race that could be trigger via the user_events test (that would create dynamic events and free them), and running a loop that would read the user_events format files:
In one console run:
# cd tools/testing/selftests/user_events # while true; do ./ftrace_test; done
And in another console run:
# cd /sys/kernel/tracing/ # while true; do cat events/user_events/__test_event/format; done 2>/dev/null
With KASAN memory checking, it would trigger a use-after-free bug report (which was a real bug). This was because the format file was not checking the file's meta data flag "EVENT_FILE_FL_FREED", so it would access the event that the file meta data pointed to after the event was freed.
After inspection, there are other locations that were found to not check the EVENT_FILE_FL_FREED flag when accessing the trace_event_file. Add a new helper function: event_file_file() that will make sure that the event_mutex is held, and will return NULL if the trace_event_file has the EVENT_FILE_FL_FREED flag set. Have the first reference of the struct file pointer use event_file_file() and check for NULL. Later uses can still use the event_file_data() helper function if the event_mutex is still held and was not released since the event_file_file() call.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2025
The vulnerability described in CVE-2024-43891 affects the Linux kernel's tracing subsystem, specifically within the event file handling mechanism. This issue stems from an improper implementation of file metadata management for dynamically created trace events, particularly impacting the format files that are exposed through the user_events interface. The core problem manifests as a race condition that can lead to use-after-free vulnerabilities when the system attempts to access freed memory structures during concurrent operations.
The technical flaw originates from a design shortcut taken during the implementation of eventfs functionality where format files were optimized by pointing directly to the call entry rather than maintaining separate file metadata references. This optimization was intended to reduce memory overhead since all format files for the same call are identical. However, this approach created a critical inconsistency where the format file's i_private pointer bypassed the normal metadata reference counting mechanism. While other event files properly maintain state through the event_mutex and EVENT_FILE_FL_FREED flag mechanism, the format file remained unaware of when its underlying event data was freed, creating a dangerous window where stale pointers could be dereferenced.
The operational impact of this vulnerability is significant as it can be triggered through normal system operations involving dynamic event creation and deletion, particularly when user_events test cases are executed alongside concurrent format file reading operations. The race condition becomes exploitable when the user_events test creates and destroys dynamic events in rapid succession while simultaneously reading the format files from another process. This scenario causes KASAN memory checking to detect actual use-after-free bugs, demonstrating that the vulnerability is not merely theoretical but can result in system instability, potential privilege escalation, or denial of service conditions. The vulnerability aligns with CWE-416, which addresses use-after-free conditions, and represents a classic example of improper resource management in kernel space.
The fix implemented addresses this issue by introducing a new helper function called event_file_file() that ensures proper synchronization through the event_mutex and explicitly checks for the EVENT_FILE_FL_FREED flag before returning file references. This approach follows established kernel patterns for safe resource access and prevents the dereferencing of freed memory structures. The solution maintains the performance optimization for format files while ensuring thread safety through proper locking mechanisms. The mitigation strategy requires that the first reference to the struct file pointer uses this new helper function with NULL checking, while subsequent accesses can utilize the existing event_file_data() function when the event_mutex is still held, thus providing a robust solution that preserves system functionality while eliminating the race condition. This remediation aligns with ATT&CK technique T1068, which involves exploiting local privilege escalation opportunities through kernel vulnerabilities, and demonstrates the critical importance of proper synchronization in kernel-level memory management.