CVE-2026-80661: ufs: core: tracing: Do not dereference pointers in TP_printk()
In the Linux kernel, the following vulnerability has been resolved:
ufs: core: tracing: Do not dereference pointers in TPprintk()
The trace events in drivers/ufs/core/ufstrace.h were converted to take a pointer to the hba structure as an argument for the tracepoint and then in TPprintk() the printing of the devname from the ring buffer was converted to using the dev dereferenced pointer from the hba saved pointer.
This is not allowed as the TPprintk() is executed at the time the trace event is read from /sys/kernel/tracing/trace file. That can happen literally, seconds, minutes, hours, weeks, days, or even months later! There is no guarantee that the hba pointer will still exist by the time it is dereferenced when the "trace" file is read.
Instead, save the device name from the hba pointer at the time the tracepoint is called and place it into the ring buffer event. Then the TPprintk() can read the name directly from the ring buffer and remove the possibility that it will read a freed pointer and crash the kernel.
This was detected when testing the trace event code that looks for TPprintk() parameters doing illegal derferences[1]
[1] https://lore.kernel.org/all/20260630184836.74d477b6@gandalf.local.home/
Event History
Frequently Asked Questions
When does the unsafe access occur?
The pointer is dereferenced when trace output is read from /sys/kernel/tracing/trace, not when the trace event is recorded. A delayed read after the associated UFS host controller structure has been freed can therefore access invalid memory and crash the kernel.
What systems are exposed to this issue?
The affected code is in Linux UFS core trace events. Exposure requires those events to have recorded an HBA pointer and the trace data to be read after that pointer is no longer valid.
How can an administrator recognize a possible occurrence?
A kernel crash while reading the tracing trace file can indicate this condition, particularly if UFS trace events were recorded long before the file was read. The provided information does not identify affected kernel versions or a distinct log signature.