CVE-2023-54211

What it actually does

Mismatched calls to trace_buffered_event_enable() and trace_buffered_event_disable() cause incorrect reference counting in ftrace event handling, triggering WARN_ON_ONCE in trace_buffered_event_disable() during soft-mode transitions.

Why it matters to the business

Kernel tracing and debugging features may produce unexpected warnings or behave inconsistently on affected Linux systems, potentially complicating performance analysis and monitoring without broader system compromise.

How an attack unfolds

An attacker with local access crafts ftrace filter commands and event enable/disable sequences to imbalance the buffered event reference count, reproducing the warning condition through repeated soft-disable and enable operations.

How to fix it

Apply the upstream fix in commit 1488d782c9e43087a3f341b8186cd25f3cf75583 or equivalent backports; update to a kernel build containing this change. For packaged distributions, install the corrected version such as krb5 1.20.1-2+deb12u2-e2 where applicable.

How to confirm the fix worked

Confirm the presence of the fix commit in the running kernel source or binary; attempt reproduction of the provided ftrace filter/enable sequence and verify absence of the WARN_ON_ONCE.

Typical attack path

1. Write a disable_event command to set_ftrace_filter to set SOFT_DISABLED_BIT and call trace_buffered_event_enable()
2. Enable the target event to clear the bit and invoke trace_buffered_event_disable() once
3. Trigger the hooked function to re-set the bit
4. Unregister the filter command to invoke trace_buffered_event_disable() a second time, hitting the warning

How to detect it

Review kernel logs for the specific WARN_ON_ONCE trace_buffered_event_disable warning and associated call traces involving __ftrace_event_enable_disable or ftrace_filter_write; inspect audit logs for unusual writes to set_ftrace_filter by non-administrative processes.

What your security team should do

• Prioritize kernel updates on systems using ftrace or event tracing for debugging or observability
• Monitor vendor advisories for backported fixes in distribution kernels
• Restrict unprivileged access to /sys/kernel/tracing and ftrace interfaces where possible