CVE-2024-35955 in Linux
Summary
by MITRE • 05/20/2024
In the Linux kernel, the following vulnerability has been resolved:
kprobes: Fix possible use-after-free issue on kprobe registration
When unloading a module, its state is changing MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will take a time. `is_module_text_address()` and `__module_text_address()` works with MODULE_STATE_LIVE and MODULE_STATE_GOING. If we use `is_module_text_address()` and `__module_text_address()` separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULE_STATE_UNFORMED between those operations.
In `check_kprobe_address_safe()`, if the second `__module_text_address()` is failed, that is ignored because it expected a kernel_text address. But it may have failed simply because module->state has been changed to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify non-exist module text address (use-after-free).
To fix this problem, we should not use separated `is_module_text_address()` and `__module_text_address()`, but use only `__module_text_address()` once and do `try_module_get(module)` which is only available with MODULE_STATE_LIVE.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 05/24/2026
The vulnerability CVE-2024-35955 resides within the Linux kernel's kprobes subsystem, specifically addressing a use-after-free condition that can occur during module unloading operations. This flaw represents a critical security concern as it potentially allows for arbitrary code execution or system instability when kernel modules are being removed from memory. The issue stems from the improper handling of module state transitions during the kprobe registration process, creating a temporal window where module metadata becomes inconsistent and leads to dangerous memory access patterns.
The technical root cause involves the interaction between module state management and kprobe address validation functions within the kernel's module loading subsystem. During module unloading, the kernel transitions a module through several states: MODULE_STATE_LIVE, MODULE_STATE_GOING, and MODULE_STATE_UNFORMED, with each transition requiring time to complete. The functions is_module_text_address() and __module_text_address() are designed to work with MODULE_STATE_LIVE and MODULE_STATE_GOING states, but when these functions are called separately in the check_kprobe_address_safe() routine, a race condition can occur. Specifically, the first function call may succeed while the second fails because the module's state has transitioned to MODULE_STATE_UNFORMED between the two operations, creating a scenario where memory that should no longer be accessible is still being referenced.
This vulnerability directly maps to CWE-416, which describes the use of memory after it has been freed, and can be categorized under ATT&CK technique T1059.006 for execution through kernel modules. The operational impact of this flaw extends beyond simple memory corruption as it can enable attackers to manipulate kernel memory structures, potentially leading to privilege escalation or complete system compromise. When arm_kprobe() attempts to modify a non-existent module text address due to the failed __module_text_address() call, the system experiences undefined behavior that can be exploited to execute arbitrary code with kernel privileges.
The fix implemented addresses this vulnerability by modifying the check_kprobe_address_safe() function to use __module_text_address() only once and incorporate try_module_get(module) which is specifically designed to work only with MODULE_STATE_LIVE. This approach eliminates the race condition by ensuring that module state validation and reference counting occur atomically, preventing the use-after-free scenario entirely. The solution aligns with kernel security best practices by reducing temporal dependencies in critical code paths and ensuring proper module lifecycle management. This mitigation strategy follows established patterns for preventing race conditions in kernel subsystems and demonstrates the importance of atomic operations when dealing with shared kernel resources. The fix ensures that kprobe registration operations maintain consistency with module state transitions while preserving the intended functionality of the kprobes subsystem for legitimate debugging and monitoring purposes.