CVE-2026-74577

CVE CVE-2026-74577EUVD EUVD-2026-59642Published 2026-08-15T12:28:14.000ZLast changed 2026-08-19T16:39:14.000Z

What the advisory describes

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)

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux patch: 7.2; patch: 6.6.151; 397fc9e5cefee0c33b86811fbddb0decb7288c52 <ba56f88aab18d982f2a21f11390f4d8a8897782a; patch: 5.10.265; patch: 0; patch: 6.1.183; patch: 6.12.103; patch: 5.15.216; 397fc9e5cefee0c33b86811fbddb0decb7288c52 <2dc2fffc704a4365cae1aae078ba62223aaeff93; 397fc9e5cefee0c33b86811fbddb0decb7288c52 <248718fd88b146d8bdc7610ecd1eb4cd16e0b5a1; 397fc9e5cefee0c33b86811fbddb0decb7288c52 <295dd295e2137e10e9a5b1891d97e0f08de76f03; patch: 7.1.8; 397fc9e5cefee0c33b86811fbddb0decb7288c52 <95651461cf77cc6590fa08c87667717e5dcfa55d; 4.13; 397fc9e5cefee0c33b86811fbddb0decb7288c52 <1fea5ff0eb4aa7e951bb3d380248566c473aa377; 397fc9e5cefee0c33b86811fbddb0decb7288c52 <a5cdd2407dd890f741f59b8367e4c6c101cce154; patch: 6.18.44; 397fc9e5cefee0c33b86811fbddb0decb7288c52 <466b474a8deb0c93b5280c6d261e5eda6482eca7

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.