Look up another CVE · open CVE-2026-80661 in the interactive tracker
CVE-2026-80661
ufs: core: tracing: Do not dereference pointers in TP_printk()
Published 2026-08-28 (2 months ago) by the Linux kernel CNA. Subsystem drivers/ufs. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-80661 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
The trace events in drivers/ufs/core/ufs_trace.h were converted to take a pointer to the hba structure as an argument for the tracepoint and then in TP_printk() the printing of the dev_name from the ring buffer was converted to using the dev dereferenced pointer from the hba saved pointer. This is not allowed as the TP_printk() 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 TP_printk() 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 TP_printk() parameters doing illegal derferences[1] [1] https://lore.kernel.org/all/20260630184836.74d477b6@gandalf.local.home/
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/ufs/core/ufs_trace.h
- What this is
- UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVERMAINTAINERS section matched on drivers/ufs/core/ · linux-scsi@vger.kernel.org · Supported
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS
Signals
- Published
- 2026-08-28 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/ufs
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.15 | 6.18.40 | e497fef9ad7e |
| 6.15 | 7.1.5 | 2510434307a2 |
| 6.15 | 7.2 | 535fcf4b8a26 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The UAF fires only when a local actor reads formatted UFS trace events from tracefs (/sys/kernel/tracing/trace or trace_pipe); UFS I/O merely records ring-buffer entries and provides no network, adjacent-radio, or physical-device entry to TP_printk().
- AC:LAttack complexity, low
- An attacker with tracefs access controls the full sequence—enable ufs trace events, generate UFS storage I/O to record hba/sdev pointers, unbind/remove the UFS host driver so those objects are freed, then read trace to deterministically hit the stale dereference without uncontrollable races.
- PR:LPrivileges required, low
- Exploitation requires local tracefs read/write to enable ufs events and read formatted output; tracing_check_open_get_tr() enforces only LOCKDOWN_TRACEFS and DAC (no capable()), and tracing-gid delegation on Android eng/atrace, ChromeOS, and developer kernels grants this to non-root accounts, matching prior TP_printk UAF CVEs.
- UI:NUser interaction, none
- No victim interaction is required; the attacker (or same debug account) enables UFS tracing, exercises or waits for UFS activity, triggers or observes driver teardown, and reads the trace buffer themselves to invoke the vulnerable TP_printk() formatting path.
- S:UScope, unchanged
- Impact is confined to kernel memory corruption, information disclosure, and denial of service within the host OS; this is standard local kernel privilege/availability impact with no VM escape, IOMMU bypass, or other cross-security-authority boundary crossing.
- C:HConfidentiality impact, high
- TP_printk() dereferences freed hba->dev or sdev->sdev_dev via dev_name() when formatting trace output, reading stale/reused slab memory into the userspace-visible trace buffer; per kernel CNA guidance, this deferred UAF read path warrants High confidentiality impact.
- I:HIntegrity impact, high
- The bug is a use-after-free on kernel heap objects (ufs_hba/scsi_device) whose freed memory can be attacker-influenced through driver teardown and reallocations before trace read, enabling heap grooming and potential write/control-flow primitives beyond a read-only format string, not merely a benign crash.
- A:HAvailability impact, high
- Dereferencing freed hba or scsi_device structures during trace formatting causes kernel paging faults/oopses and can panic the system; the fix explicitly states this illegal TP_printk() dereference can crash the kernel when the trace file is read after device removal.