CVE-2026-98584: net/sched: fix potential stack infoleak in em_text_dump()
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fix potential stack infoleak in emtextdump()
emtextdump() allocates struct tcfemtext on the stack without zeroing it. strscpy() writes the algorithm name and a NUL terminator into conf.algo[], leaving the remaining bytes uninitialised. nlaputnohdr() 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 RTMGETTFILTER dump:
BUG: KMSAN: kernel-infoleak in copytoiter+0x1c9/0x2620 nlaputnohdr+0x83/0x130 emtextdump+0x291/0x550 Local variable conf created at: emtextdump+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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
Zero-initialize the struct tcf_em_text allocated on the stack in em_text_dump() before copying the algorithm name, so the full struct copied by nla_put_nohdr() cannot contain uninitialized bytes.
Event History
Frequently Asked Questions
What operations have been observed to trigger the leak?
KMSAN reports were triggered by a "tc filter show" request and by a raw RTM_GETTFILTER netlink dump. Both reach em_text_dump(), which returns the affected structure in a netlink response.
What information could be disclosed?
The response can include uninitialized bytes from the kernel stack. Specifically, bytes remaining in the algorithm-name field after strscpy() are copied as part of the full struct tcf_em_text.
How can an environment identify this issue?
A KMSAN-enabled kernel can report a kernel-infoleak originating in nla_put_nohdr() through em_text_dump(), with the uninitialized local variable identified as conf. The report notes bytes 168 through 179 of the 199-byte structure as uninitialized in the observed case.
Is the practical security impact confirmed on production kernels?
The report does not confirm that sensitive data is exposed on production kernels. The finding was observed in a controlled KMSAN environment, and the leaked stack contents may or may not be sensitive in practice.