Root Cause Analysis

1. Synopsis and Involved Entities

• Source File: kernel/trace/blktrace.c
• Functions: __blk_add_trace(), record_blktrace_event(), record_blktrace_event2(), print_one_line()
• Structures & Data: struct blk_io_trace (v1 format), struct blk_io_trace2 (v2 format), what2act[] array, enum blktrace_act (include/uapi/linux/blktrace_api.h)

2. Mechanism and Lifecycle Violation

There are two interconnected defects in kernel/trace/blktrace.c that combine to cause this crash:

1. Format Mismatch in the ftrace Ring Buffer:

   • When tracing is enabled on a block device using the legacy BLKTRACESETUP or BLKTRACESETUP32 ioctls (blk_trace_ioctl() $\to$ blk_trace_setup()), the block trace structure is initialized with bt->version = 1.
   • When the blk tracer is enabled via ftrace (blk_tracer_init(), setting blk_tracer_enabled = true), block I/O operations trigger tracepoint handlers which invoke __blk_add_trace().
   • In __blk_add_trace(), switch (bt->version) contains a case 1: branch (lines 389 and 422) that allocates sizeof(struct blk_io_trace) (48 bytes) and calls record_blktrace_event() (v1 layout) instead of record_blktrace_event2() (v2 layout).
   • However, the ftrace printing pipeline (te_blk_io_trace()) assumes that all TRACE_BLK entries in the ring buffer conform to struct blk_io_trace2 (v2 layout).
   • In struct blk_io_trace (v1), the 32-bit pid is placed at offset 32 and device is placed at offset 36.
   • In struct blk_io_trace2 (v2), the 64-bit action field is placed at offset 32, while pid is at offset 28.
   • When reading the trace (e.g., through /sys/kernel/tracing/trace or trace_pipe), print_one_line() casts iter->ent to const struct blk_io_trace2 *t and evaluates:

     what = (t->action & ((1 << BLK_TC_SHIFT) - 1)) & ~__BLK_TA_CGROUP;
     

     Because of the layout mismatch, t->action reads the bytes from v1's pid field (offset 32). If the process PID satisfies (pid & 0xFFFF) == 14, what is evaluated as 14.

2. Unchecked Function Pointer Call on Uninitialized Array Slot:

   • what2act[] is defined using designated initializers up to [__BLK_TA_REMAP] = 15, making ARRAY_SIZE(what2act) == 16:

     static const struct {
         const char *act[2];
         void (*print)(struct trace_seq *s, const struct trace_entry *ent, bool has_cg);
     } what2act[] = {
         [__BLK_TA_QUEUE]       = {{ "Q", "queue" },       blk_log_generic },
         ...
         [__BLK_TA_SPLIT]       = {{ "X", "split" },       blk_log_split },
         [__BLK_TA_REMAP]       = {{ "A", "remap" },       blk_log_remap },
     };
     

   • In enum blktrace_act, index 14 is __BLK_TA_BOUNCE (/* unused, was: bio was bounced */). It is completely omitted in what2act[], leaving what2act[14].act = {NULL, NULL} and what2act[14].print = NULL.
   • In print_one_line():

     if (unlikely(what == 0 || what >= ARRAY_SIZE(what2act)))
         trace_seq_printf(s, "Unknown action %x\n", what);
     else {
         log_action(iter, what2act[what].act[long_act], has_cg);
         what2act[what].print(s, iter->ent, has_cg);
     }
     

   • When what == 14, the check what == 0 || what >= ARRAY_SIZE(what2act) evaluates to false (14 < 16).
   • print_one_line() fails to check whether what2act[what].print is non-NULL.
   • It attempts to call what2act[14].print(...) (NULL), triggering an instruction fetch page fault at RIP: 0x0 in kernel mode (#PF: supervisor instruction fetch in kernel mode).

Runtime Impact and Classification

• Memory Corruption (MemoryCorruption: false): The crash occurs directly from calling an uninitialized NULL function pointer (RIP: 0010:0x0), not a wild or corrupted pointer. In production builds without debugging sanitizers, this is a pure NULL pointer dereference and instruction fetch fault; it does not corrupt kernel memory or hijack control flow to attacker-chosen payload addresses.
• Information Leak (InfoLeak: "none"): No kernel heap/stack data or pointers are leaked to userspace; the read operation immediately faults and crashes.
• Denial of Service (RawDenialOfService: true): Dereferencing the NULL pointer causes an immediate kernel oops/panic during standard read() operations on the trace file, halting the calling process or the entire system depending on panic_on_oops configuration.
• Candidate Subsystems (IsNetCandidate: false, IsKVMCandidate: false): The issue is entirely within the block tracing subsystem (blktrace) and generic tracing infrastructure (ftrace).