CVE-2026-98584
N/AIn 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.
No known exploitation, public exploit, or elevated probability at this time. Track for changes.
Exploitation likelihood
0.2%chance of exploitation in 30 days · 9th percentile
Impact if exploited
—CVSS · not scored
- No impact metrics
Proof of concept & exploit code
- github-search Search GitHub for public PoC repos
Test against your own equipment
curl -s https://vulnpedia.com/cve/CVE-2026-98584/poc.jsonMachine-readable PoC index for this CVE (for automation).Listed for defensive triage, patch verification, and authorized testing on systems you own. Machine-readable: /cve/CVE-2026-98584/poc.json