CVE-2021-47375

What it actually does

Use-after-free in blktrace: removing a trace via sysfs on one block device (after synchronize_rcu and relay_close) frees the relay buffer while an RCU reader on another device still holds a reference, causing trace_note_tsk to dereference a NULL buf->offset pointer.

Why it matters to the business

Attackers with local access can trigger a kernel NULL pointer dereference, resulting in system crashes or denial of service; the issue affects any Linux deployment using blktrace for I/O tracing and has been public for over two years with low but non-zero exploitation probability.

How an attack unfolds

An attacker sets up blktrace on two devices, starts tracing, then disables tracing on the second device to free its relay buffers while simultaneously issuing I/O on the first device; the RCU grace period expires and the buffer is freed before the first device's trace_note_tsk walks running_trace_list, leading to the NULL dereference during relay_reserve.

How to fix it

Apply the upstream fix that removes blk_trace from the running_list before calling blk_trace_free when the trace is in the Blktrace_running state; upgrade to a mainline or distribution kernel containing commit 332d2e4a83251d406ca58dd11c27c598673aa5fa or later equivalent.

How to confirm the fix worked

Confirm the running kernel contains the patch that moves the running_list removal before blk_trace_free; reproduce the original race with delayed blk_trace_free and verify no NULL dereference occurs; scan kernel source for the updated blk_trace_remove_queue logic.

Typical attack path

1. Obtain local unprivileged access on a Linux system
2. Issue BLKTRACESETUP and BLKTRACESTART ioctls on two block devices
3. Trigger sysfs trace disable on one device to enter blk_trace_free path
4. Issue SG_IO or other I/O on the second device while inside the RCU read-side critical section
5. Force the freed relay buffer to be accessed via trace_note_tsk after kfree

How to detect it

Search kernel logs for Oops messages containing trace_note.isra.0 and __blk_add_trace; inspect audit or syscall logs for sequences of BLKTRACESETUP, BLKTRACESTART, and sysfs writes to /sys/block/*/trace/enable followed by SG_IO or similar ioctls from the same process.

What your security team should do

• Prioritize patching all Linux systems that expose block devices to untrusted local users
• Disable blktrace via kernel configuration or sysfs where I/O tracing is not required
• Monitor for kernel oops involving trace_note.isra and blk_add_trace_rq as indicators of attempted exploitation