CVE-2026-53082: Linux Kernel Use-After-Free Vulnerability

CVE-2026-53082 Overview

CVE-2026-53082 is a Linux kernel vulnerability in the net/hamradio/6pack driver. The sixpack_receive_buf() function does not properly skip bytes flagged with TTY errors. Its while loop iterates the flags buffer but never advances the data pointer (cp), and forwards the original byte count (including error bytes) to sixpack_decode(). The TTY layer does not guarantee cp[i] holds a meaningful value when fp[i] is set, so KMSAN reports an uninitialized value read. The fix processes bytes one at a time, advances cp per iteration, and only passes valid (non-error) bytes to sixpack_decode(), matching the pattern used by slip_receive_buf() and mkiss_receive_buf().

Critical Impact
Uninitialized kernel memory may be processed by the 6pack decoder, potentially leaking stale stack or heap contents into protocol handling and producing undefined behavior on systems using 6pack HamRadio TTY line discipline.

Affected Products

Linux kernel mainline tree (net/hamradio/6pack driver)
Linux stable branches receiving the referenced backports
Distributions shipping kernels with the 6pack line discipline enabled

Discovery Timeline

2026-06-24 - CVE-2026-53082 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-53082

Vulnerability Analysis

The defect lives in the 6pack HamRadio TTY line discipline receive path. When the TTY layer hands buffered bytes to sixpack_receive_buf(), each byte is paired with a flag in the fp array indicating parity, framing, overrun, or break errors. The original implementation iterated those flags but did not advance the character pointer cp, and it passed the full unfiltered count to sixpack_decode(). Bytes corresponding to error positions therefore reached the decoder even though their contents are not guaranteed to be initialized. KMSAN flagged the resulting read as an uninitialized value access in kernel space. While the immediate symptom is undefined decoder behavior, uninitialized memory reads in network-adjacent kernel paths can lead to information leakage and inconsistent protocol state.

Root Cause

The root cause is incorrect handling of the TTY error flags array. The receive loop advanced only the flag index i while leaving the data pointer fixed, and it deferred all decoding to a single bulk sixpack_decode() call that received the original count. There was no per-byte gating on fp[i], so error-marked positions were never skipped before consumption. This is a classic uninitialized memory use [CWE-908] pattern in a TTY consumer driver.

Attack Vector

Reaching the vulnerable path requires the 6pack line discipline to be attached to a TTY device. Local attackers or faulty hardware that can induce TTY error flags (parity, framing, overrun, break) on an attached serial device can cause the kernel to process uninitialized buffer positions. Exploitation is constrained by the need for local TTY access and the relatively narrow deployment of HamRadio drivers, but the bug is reachable on any system where an unprivileged or hardware-driven path can trigger TTY errors on a N_6PACK discipline.

The vulnerability is described in prose only; refer to the upstream commits for the exact diff. See the Kernel Git Commit history for the corrected loop structure.

Detection Methods for CVE-2026-53082

Indicators of Compromise

KMSAN or KASAN reports referencing sixpack_receive_buf or sixpack_decode in kernel logs.
Unexpected attachment of the N_6PACK line discipline on systems that do not use HamRadio hardware.
Repeated TTY error flag events (parity, framing, overrun) on serial devices bound to 6pack.

Detection Strategies

Inventory running kernels and compare against the fixed stable releases referenced in the upstream commits.
Audit loaded kernel modules for 6pack and verify whether the line discipline is required on the host.
Monitor dmesg for kernel sanitizer warnings or oops messages referencing the hamradio receive path.

Monitoring Recommendations

Collect kernel logs centrally and alert on stack traces involving sixpack_receive_buf.
Track ioctl(TIOCSETD, N_6PACK) calls via auditd or eBPF tracing on production hosts.
Baseline which endpoints legitimately load 6pack.ko and flag deviations.

How to Mitigate CVE-2026-53082

Immediate Actions Required

Apply the upstream stable kernel update that contains the sixpack_receive_buf() fix on all affected branches.
Where patching is not immediately possible, unload the 6pack module on systems that do not require HamRadio support.
Restrict the ability of unprivileged users to attach arbitrary TTY line disciplines.

Patch Information

The fix has been merged across multiple Linux stable branches. Relevant commits include 1d3abf0c3dde, 2951656b0de0, 578f3aba427c, 987af7625ceb, bf9a38803b26, d4cceb518453, d9ce2a4b6791, and e9cf4018d742. Rebuild and redeploy kernels from these branches, then reboot affected hosts.

Workarounds

Blacklist the 6pack kernel module on systems that do not require the HamRadio line discipline.
Limit CAP_NET_ADMIN and TTY device access to trusted users to reduce who can attach line disciplines.
Disable serial ports that are not in use to remove the hardware-level trigger surface.

bash

# Configuration example: blacklist the 6pack module on hosts that do not need it
echo 'blacklist 6pack' | sudo tee /etc/modprobe.d/blacklist-6pack.conf
sudo rmmod 6pack 2>/dev/null || true
sudo update-initramfs -u