CVE-2026-53082

What it actually does

This flaw affects the Linux kernel 6pack amateur-radio line discipline receive path. When bytes received from the TTY layer are marked with TTY error flags, the vulnerable receive routine does not correctly advance the data pointer or exclude those error-marked bytes before decoding. Because the TTY layer does not guarantee that data bytes corresponding to error flags contain initialized or meaningful data, the decoder may read uninitialized kernel memory. The primary technical impact is an information disclosure-style uninitialized memory read within the kernel receive path, observable by kernel memory sanitizers and potentially capable of exposing unintended data through dependent behavior, crashes, diagnostics, or packet processing side effects. Exploitation requires access to the affected 6pack/TTY code path and the ability to supply or influence malformed/error-marked TTY input.

Why it matters to the business

Organizations using Linux systems with the hamradio 6pack line discipline enabled or available may face risk of kernel memory exposure, instability, or diagnostic crashes in specialized networking or embedded environments. The practical exposure is likely limited because 6pack is a niche amateur-radio protocol, the issue is not listed in the Known Exploited Vulnerabilities catalog, no ransomware use is reported, exploit maturity is listed as none, and the EPSS probability is very low. However, kernel vulnerabilities should still be remediated through normal kernel update processes because the affected code may be present even on systems that do not intentionally use amateur-radio networking features.

How an attack unfolds

An attacker would need a path to interact with the Linux TTY interface configured for the 6pack line discipline, such as a local user, attached serial/TTY device, or other component able to feed data into that receive path. The attacker sends input where selected bytes are accompanied by TTY error flags. In the vulnerable implementation, the receive loop checks the flags buffer but fails to correctly advance the corresponding data pointer and passes the original byte count to the 6pack decoder. As a result, bytes that should have been skipped because they are invalid or undefined are processed by the decoder. This can trigger reads of uninitialized kernel memory and may lead to information disclosure symptoms, sanitizer reports, unexpected packet decoding behavior, or kernel instability depending on build configuration and runtime conditions. There is currently no indication of public weaponized exploitation or named threat actor use.

How to fix it

Apply the Linux kernel update provided by the operating system or kernel vendor that includes the fix for the 6pack receive-buffer handling issue. Because no specific affected product list or fixed package versions were provided, use vendor advisories and package metadata to identify the corrected kernel release for each distribution or appliance. Where immediate patching is not possible, reduce exposure by disabling or preventing use of the hamradio 6pack line discipline and related kernel modules where they are not required, restricting local access to TTY/serial devices, and limiting permissions that allow users or services to configure line disciplines. For custom kernels, incorporate the upstream fix that processes TTY bytes one at a time, advances the data pointer on every iteration, and passes only non-error bytes to sixpack_decode().

How to confirm the fix worked

Confirm that systems are running a vendor kernel build containing the 6pack receive-buffer fix. Validate through package manager records, kernel changelogs, vendor security advisories, or source inspection showing that sixpack_receive_buf() advances the data pointer per byte and only decodes bytes without TTY error flags. On Linux systems, verify the running kernel version with uname and compare it against the vendor-fixed release rather than relying only on upstream version numbers. Where feasible, confirm that 6pack functionality is not loaded or used on systems that do not require it. For source-based builds, confirm that drivers/net/hamradio/6pack.c contains the corrected receive loop behavior. In test environments with sanitizer-enabled kernels, reproduce attempts should no longer produce KMSAN uninitialized-value reports in sixpack_receive_buf() or sixpack_decode().

Typical attack path

1. Gain the ability to interact with a Linux TTY path that can be configured for or is already using the 6pack line discipline.
2. Feed crafted TTY input containing bytes associated with TTY error flags.
3. Cause the vulnerable sixpack_receive_buf() logic to process error-marked bytes instead of skipping them.
4. Trigger sixpack_decode() to read data that the TTY layer did not guarantee was initialized or valid.
5. Leverage resulting behavior for information disclosure, fault generation, or kernel diagnostic evidence, depending on system configuration.

How to detect it

To determine whether this issue was already exercised, review kernel logs and crash/sanitizer telemetry for evidence of uninitialized memory reads involving the 6pack hamradio driver. Relevant log sources include journalctl/kern.log/dmesg, crash dumps, KMSAN or syzkaller outputs, kernel oops reports, and endpoint telemetry showing kernel module loading or TTY line discipline configuration. Look for references to sixpack_receive_buf(), sixpack_decode(), drivers/net/hamradio/6pack.c, or the 6pack module around times when serial or TTY devices received malformed input. Also review audit logs or command history for attempts to load 6pack-related modules or configure unusual TTY line disciplines. Because the described issue is an uninitialized read in a kernel receive path, there may be no reliable network-only indicator, and absence of logs does not prove non-exploitation unless kernel diagnostics and audit coverage were enabled.

• sixpack_receive_buf
• sixpack_decode
• drivers/net/hamradio/6pack.c
• KMSAN: uninit-value
• uninit-value in sixpack_receive_buf
• uninitialized-value in sixpack_receive_buf
• BUG: KMSAN: uninit-value
• 6pack
• mkiss
• modprobe 6pack
• sixpack.ko
• /lib/modules/*/kernel/drivers/net/hamradio/6pack.ko
• /dev/tty

What your security team should do

• Inventory Linux systems and appliances that include or enable hamradio/6pack kernel functionality, prioritizing embedded, serial-connected, and specialized networking systems.
• Patch affected kernels using the relevant vendor-supported update channel during the next appropriate maintenance window; accelerate patching for systems where untrusted users or devices can access TTY interfaces.
• Disable or blacklist the 6pack module/line discipline where amateur-radio packet networking is not required.
• Restrict permissions to TTY and serial devices and review which users or services can configure line disciplines.
• Monitor kernel logs for sanitizer, uninitialized memory, or 6pack-related errors until remediation is complete.
• Track vendor advisories because exact fixed package versions vary by distribution and were not provided in the input.
• Treat this as lower urgency than actively exploited remote kernel vulnerabilities, but do not ignore it on multi-user or device-facing Linux systems.