CVE-2026-74577 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
net: mpls: initialize rtm_tos in mpls_getroute()
mpls_getroute() builds the RTM_NEWROUTE reply to an RTM_GETROUTE request by filling a struct rtmsg allocated from an skb whose data area is not zeroed (alloc_skb(NLMSG_GOODSIZE, ...)). It sets every field of the header except rtm_tos:
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 rtm_tos (offset 3) is copied straight to user space on recvmsg(), leaking a byte of uninitialised heap memory. This is in contrast to mpls_dump_route(), which fills the very same header and does set rtm_tos = 0.
Initialize rtm_tos to 0, matching mpls_dump_route().
Reproduced with KMSAN by adding an MPLS route and issuing a non-RTM_F_FIB_MATCH RTM_GETROUTE for its label:
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x36c/0x33f0 _copy_to_iter+0x36c/0x33f0 __skb_datagram_iter+0x196/0x12c0 skb_copy_datagram_iter+0x5b/0x210 netlink_recvmsg+0x37b/0xef0 ... Uninit was created at: __alloc_skb+0x8ca/0x10e0 mpls_getroute+0x1280/0x3a40 rtnetlink_rcv_msg+0x1138/0x15a0 ... Byte 19 of 64 is uninitialized
(byte 19 = nlmsghdr(16) + rtmsg offset 3 = rtm_tos)
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability in question involves a memory disclosure issue within the Linux kernel's Multiprotocol Label Switching (MPLS) implementation, specifically within the mpls_getroute() function. This flaw arises from improper initialization of the rtm_tos field in the rtmsg structure when constructing RTM_NEWROUTE replies to RTM_GETROUTE requests. The root cause lies in how the kernel allocates memory for network messages using alloc_skb() without zeroing the allocated buffer, followed by partial initialization of the rtmsg header structure. The mpls_getroute() function correctly initializes all fields of the rtmsg structure except for rtm_tos, which remains uninitialized and contains arbitrary heap data from previous operations.
The technical execution of this vulnerability occurs through the network subsystem's handling of MPLS routing information. When a user-space application issues an RTM_GETROUTE request for an MPLS route, the kernel processes this request through mpls_getroute() which allocates an skb buffer and populates the rtmsg header with specific values while leaving rtm_tos unassigned. Since struct rtmsg contains no padding fields, the uninitialized byte at offset 3 (rtm_tos) gets directly copied to user space during the recvmsg() operation. This behavior differs from mpls_dump_route() which properly initializes rtm_tos to zero, creating an inconsistent state in the kernel's MPLS implementation.
The operational impact of this vulnerability constitutes a information disclosure risk where uncontrolled heap memory contents can be leaked to user-space applications. The KMSAN (Kernel Memory Sanitizer) trace confirms that byte 19 of the 64-byte response contains uninitialized data, corresponding to the rtm_tos field within the rtmsg structure. This leak could potentially expose sensitive kernel memory patterns, including cryptographic keys, session identifiers, or other confidential information stored in nearby heap locations. The vulnerability is particularly concerning as it allows attackers to gather information about kernel memory layout and internal state without requiring elevated privileges.
This issue maps to CWE-248 (Uncaught Exception) and CWE-125 (Out-of-bounds Read) within the Common Weakness Enumeration framework, representing an improper initialization that leads to information exposure. From the MITRE ATT&CK framework perspective, this vulnerability could be leveraged in initial access phases or privilege escalation techniques where adversaries seek to gather system intelligence through information gathering operations. The remediation approach involves ensuring consistent initialization practices across similar functions by explicitly setting rtm_tos = 0 in mpls_getroute() to match the behavior of mpls_dump_route(). This simple but critical fix ensures that all fields within the rtmsg structure are properly initialized before being exposed to user-space applications, thereby preventing information leakage through uninitialized memory contents.