In the Linux kernel, the following vulnerability has been resolved:
net: mpls: initialize rtmtos in mplsgetroute()
mplsgetroute() builds the RTMNEWROUTE reply to an RTMGETROUTE request by filling a struct rtmsg allocated from an skb whose data area is not zeroed (allocskb(NLMSGGOODSIZE, ...)). It sets every field of the header except rtmtos:
r = nlmsg_data(nlh);
r->rtm_family = AF_MPLS;
r->rtm_dst_len = 20;
r->rtm_src_len = 0;
r->rtm_table = RT_TABLE_MAIN;
r->rtm_type = RTN_UNICAST;
r->rtm_scope = RT_SCOPE_UNIVERSE;
r->rtm_protocol = rt->rt_protocol;
r->rtm_flags = 0;
struct rtmsg has no padding, so the one uninitialised byte rtmtos (offset 3) is copied straight to user space on recvmsg(), leaking a byte of uninitialised heap memory. This is in contrast to mplsdumproute(), which fills the very same header and does set rtmtos = 0.
Initialize rtmtos to 0, matching mplsdump_route().
Reproduced with KMSAN by adding an MPLS route and issuing a non-RTMFFIBMATCH RTMGETROUTE for its label:
BUG: KMSAN: kernel-infoleak in copytoiter+0x36c/0x33f0 copytoiter+0x36c/0x33f0 __skbdatagramiter+0x196/0x12c0 skbcopydatagramiter+0x5b/0x210 netlinkrecvmsg+0x37b/0xef0 ... Uninit was created at: __allocskb+0x8ca/0x10e0 mplsgetroute+0x1280/0x3a40 rtnetlinkrcvmsg+0x1138/0x15a0 ... Byte 19 of 64 is uninitialized
(byte 19 = nlmsghdr(16) + rtmsg offset 3 = rtm_tos)
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/74xxx/CVE-2026-74577.json"
}