PT-2026-116803 · Linux · Linux

CVE-2026-98584

·

Published

2026-10-18

·

Updated

2026-10-18

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-98584

Affected Products

Linux