Live › vulnerability › CVE-2026-98584
Go to dashboardThe tc classifier text-match dump path copies a stack struct that was not zeroed, so a few uninitialised kernel stack bytes go into the netlink reply. The reporter notes the leaked bytes may not carry sensitive data on production kernels.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with the net/sched text-match (ematch) classifier path present, where local users can issue traffic-control filter dump requests. Hosts that do not use tc filters with ematch rules or restrict netlink access to privileged users have a much smaller exposure. The sources do not say which kernel versions are affected beyond the report from a development build.
No product ranges from the sources yet.
uname -r and compare against the fixed kernel release in your distribution's advisory (unknown from these sources)tc filter show is reachable by untrusted local users (unknown from these sources)Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-98584")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.