CVE-2024-35955

What it actually does

Race between is_module_text_address and __module_text_address during kprobe registration allows arm_kprobe to write to module text after the module has transitioned to MODULE_STATE_UNFORMED, producing a use-after-free write in kernel memory.

Why it matters to the business

Linux systems may experience kernel crashes, memory corruption, or local privilege escalation that disrupts services, requires emergency patching, and increases operational risk for servers and embedded devices running affected kernels.

How an attack unfolds

An attacker with the ability to load and unload kernel modules times a kprobe registration against a target module so that the first address check succeeds while the module state advances to UNFORMED before the second address lookup, causing arm_kprobe to dereference and modify freed module text.

How to fix it

Upgrade the Linux kernel to the commit 3d7cb6b04c3f3115719235cc6866b10326de34cd or any later mainline or distribution backport that replaces the separate is_module_text_address/__module_text_address calls with a single __module_text_address followed by try_module_get.

How to confirm the fix worked

Verify the running kernel contains commit 3d7cb6b04c3f3115719235cc6866b10326de34cd; confirm absence of the vulnerable check_kprobe_address_safe pattern in kernel source; test kprobe registration against a module being unloaded under load.

Typical attack path

1. Obtain local code execution or module-loading capability on target system
2. Load a kernel module containing the desired probe address
3. Register a kprobe on that address while concurrently unloading the module
4. Trigger the state transition to MODULE_STATE_UNFORMED between the two address checks
5. arm_kprobe performs write on the now-freed module text, corrupting kernel memory

How to detect it

Review kernel logs for oops or warning messages referencing check_kprobe_address_safe or kprobe registration failures during module unload; inspect audit logs for sequences of module load/unload paired with kprobe syscalls.

What your security team should do

• Prioritize kernel upgrades on all systems that permit module loading or use kprobes
• Apply the fixed commit or distribution equivalent within the next maintenance window
• Restrict unprivileged module loading via kernel configuration or LSM policy until patched
• Monitor kernel mailing lists and distribution advisories for backported fixes