CVE-2024-57930

What it actually does

The process_string() check in kernel tracing falsely flagged safe array-indexed string references (such as xe_mem_type_to_name[]) in TP_printk() as potential use-after-free risks, allowing an address of a freed string to be stored in the ring buffer and later dereferenced during event printing.

Why it matters to the business

Kernel tracing events could trigger crashes, memory corruption, or information disclosure on affected Linux systems; organizations running older kernels face elevated operational risk until upgraded, especially given the high prevalence of the Linux kernel in servers and cloud infrastructure.

How an attack unfolds

An attacker registers a trace event that stores a pointer to a short-lived allocated string in TP_fast_assign() and references it via %s in TP_printk(); the flawed check previously accepted certain array patterns, so the event is enabled; hours later when the original string is freed, printing the event dereferences the dangling pointer, leading to use-after-free.

How to fix it

Upgrade the Linux kernel to version 6.1.124 or later, or apply the commit 3bcdc9039a6e9e6e47ed689a37b8d57894a3c571; for Red Hat Enterprise Linux AUS 6.5 systems update glibc packages to 0:2.12-1.132.el6_5.8 or newer; rebuild and reload any custom trace events after the update.

How to confirm the fix worked

Confirm the running kernel reports version 6.1.124 or newer; verify the git commit 3bcdc9039a6e9e6e47ed689a37b8d57894a3c571 is present in the tracing code; re-run test_event_printk() on affected events and ensure array references to xe_mem_type_to_name[] and similar are no longer rejected.

Typical attack path

1. Identify or create a trace event using TP_fast_assign() to store an allocated string address
2. Reference the string via %s in TP_printk() using an array of pointers indexed by a record field
3. Enable the event so it is validated by test_event_printk()
4. Trigger the event after the original string buffer has been freed
5. Cause the kernel to execute TP_printk() and dereference the dangling pointer

How to detect it

Search kernel logs and audit trails for trace event registration failures or warnings from test_event_printk(); inspect ring buffer usage around events that reference string pointers; look for crashes with stack traces involving TP_printk() and freed string buffers.

What your security team should do

• Prioritize kernel upgrades on all production systems within the next maintenance window
• Audit custom tracepoints for TP_fast_assign()/TP_printk() string usage and replace any direct pointer stores with safe alternatives
• Monitor EPSS and KEV feeds for any future increase in exploit maturity
• Test tracing functionality in staging after applying the fix to ensure events continue to work