CVE-2026-98584 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fix potential stack infoleak in em_text_dump()
em_text_dump() allocates struct tcf_em_text on the stack without zeroing it. strscpy() writes the algorithm name and a NUL terminator into conf.algo[], leaving the remaining bytes uninitialised. nla_put_nohdr()
then copies the full struct to the netlink response.
KMSAN on Linux 7.2-rc6 reports two kernel-infoleak splats from this path, one triggered via "tc filter show" and one via a raw RTM_GETTFILTER dump:
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x1c9/0x2620 nla_put_nohdr+0x83/0x130 em_text_dump+0x291/0x550 Local variable conf created at: em_text_dump+0x5d/0x550 Bytes 168-179 of 199 are uninitialized
I am not certain whether this constitutes a real security problem in practice: the test was conducted in a controlled KMSAN environment and the leaked stack bytes may or may not carry sensitive data on actual production kernels. I am reporting it because KMSAN flagged it as a kernel-infoleak and the fix is straightforward. I can provide a userspace reproducer on request.
The original code used strncpy() which zero-pads to the destination size. Commit b04202d6065c ("net/sched: replace strncpy with strscpy") replaced it with strscpy(), which does not pad, creating this condition. Zero-initialising the struct closes it.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel networking subsystem contains a vulnerability within the traffic control module that results in an information leak of uninitialized stack memory to user space. This flaw resides specifically in the em_text_dump function, which is responsible for serializing text-based classifier configuration data into netlink messages for retrieval by userspace tools such as tc filter show or via raw RTM_GETTFILTER requests. The root cause stems from a recent code refactoring where the strncpy function was replaced with strscpy to improve safety and performance. While strncpy automatically pads the destination buffer with null bytes up to its allocated size, strscpy only writes the source string and a single NUL terminator without zeroing out the remainder of the target structure. Consequently, when em_text_dump allocates an instance of struct tcf_em_text on the stack, it fails to initialize the entire memory region before use.
The technical mechanism of this vulnerability involves the partial initialization of the configuration structure. The strscpy function writes the algorithm name and its terminating null byte into the conf.algo array within the structure. However, any bytes in that array beyond the length of the string plus the terminator remain uninitialized, retaining whatever data was previously present on the kernel stack at that memory location. Subsequently, the nla_put_nohdr function copies the entire struct tcf_em_text to the netlink response buffer without checking for or clearing these remaining uninitialised bytes. This results in a direct leakage of up to approximately twelve bytes of sensitive kernel stack data into user space every time this specific traffic control filter configuration is queried.
The operational impact of this vulnerability allows local users with access to network namespace management capabilities, such as the ability to inspect traffic control filters, to read arbitrary kernel memory contents. Although the leaked data size is small and potentially limited in scope depending on what other variables reside adjacent to the structure on the stack at runtime, it constitutes a classic information disclosure flaw that can aid attackers in bypassing security mitigations like ASLR or extracting cryptographic keys if they are present in nearby stack frames. The vulnerability was identified using Kernel Memory Sanitizer (KMSAN), which flagged two distinct instances of kernel-infoleak splats during controlled testing environments involving both tc filter show commands and raw netlink dumps, confirming the reproducibility of the issue across different access vectors within the same subsystem.
From a classification perspective, this flaw aligns with CWE-200: Information Exposure and CWE-1341: Out-of-bounds Read, as it involves reading uninitialized memory that was not intended for public consumption. In terms of attack patterns, it relates to ATT&CK technique T1087: Account Discovery or more broadly information gathering through local privilege escalation vectors if the leaking process has elevated privileges, though primarily it serves as a reconnaissance tool for gaining insight into kernel state. The vulnerability is strictly limited in its exploitation complexity because it requires specific access to netlink sockets and traffic control configuration interfaces, which are typically restricted to users with CAP_NET_ADMIN capabilities or root access on Linux systems.
The recommended mitigation involves modifying the em_text_dump function to explicitly zero-initialize the struct tcf_em_text instance before any data is written into it. This can be achieved by using memset to clear the entire structure memory space prior to calling strscpy, ensuring that all bytes in conf.algo are set to null regardless of the string length provided. Alternatively, declaring the variable with an initializer such as struct tcf_em_text conf = {0} achieves the same effect at compile time or runtime depending on compiler optimizations. This fix is straightforward and restores the security posture equivalent to the previous strncpy implementation while maintaining the benefits of using strscpy for bounds checking during string copying operations. System administrators should apply kernel updates that include this patch immediately to prevent potential information leakage through traffic control inspection tools.