CVE-2026-74598 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix Route Information option length validation
rt6_route_rcv() validates the Route Information option (RFC 4191) length against the prefix length, but both checks are off by one.
rinfo->length is the ND option length in units of 8 octets and it *includes* the 8-byte option header, so an option carrying N bytes of prefix has length == 1 + N/8. RFC 4191 section 2.3 requires length 3 when Prefix Length is greater than 64, and 2 or 3 when it is greater than 0. The code accepts length >= 2 and length >= 1 respectively.
ipv6_addr_prefix() then copies prefix_len/8 bytes out of rinfo->prefix, so a Router Advertisement with (prefix_len=128, length=2) or (prefix_len=64, length=1) makes the kernel read up to 8 bytes past the end of the option. Those bytes end up in the prefix of the route that gets installed, so they are visible to userspace:
# RA with a Route Information option (prefix_len=128, length=2) # followed by a source link-layer address option, 01 01 de ad be ef ca fe $ ip -6 route show 2001:db8:dead:beef:101:dead:beef:cafe via fe80::1234 dev veth0 proto ra ^^^^^^^^^^^^^^^^^^ the next option, read out of bounds
When the Route Information option is the last one in the packet, those eight bytes come from the skb tail room instead.
Reject the option lengths RFC 4191 does not allow.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel contained an off-by-one validation error within the IPv6 Router Advertisement processing logic, specifically affecting the Route Information Option as defined in RFC 4191. The function rt6_route_rcv is responsible for validating incoming Neighbor Discovery messages to ensure they conform to protocol specifications before installing routes into the routing table. In this instance, the code incorrectly validated the length field of the Route Information option against the prefix length. According to RFC 4191 section 2.3, a Route Information Option with a prefix length greater than sixty-four bits must have an option length of three units of eight octets, while options for prefixes longer than zero but not exceeding sixty-four bits require a minimum length of two or three units depending on specific conditions. The vulnerable implementation accepted lengths that were one unit too small, effectively allowing malformed packets to bypass strict boundary checks. This discrepancy arises because the length field represents the total option size in eight-octet blocks including the header, and the validation logic failed to account for this structure correctly when comparing against the prefix data requirements.
This validation flaw leads directly to a heap-based out-of-bounds read vulnerability with significant information disclosure potential. When an attacker crafts a Router Advertisement containing a Route Information Option where the declared length is insufficient for the specified prefix length, such as setting the prefix length to one hundred twenty-eight bits while declaring a length of two units or setting it to sixty-four bits with a length of one unit, the kernel proceeds to process the option. The function ipv6_addr_prefix subsequently copies data from the rinfo->prefix buffer based on the declared prefix length divided by eight. Due to the insufficient validation, this operation reads up to eight bytes beyond the allocated boundaries of the Route Information Option structure. These out-of-bounds bytes are then incorporated into the IPv6 route entry that is installed in the kernel routing table and subsequently exposed to user-space applications through standard networking interfaces like ip -6 route show.
The impact of this vulnerability extends beyond simple memory corruption, as it facilitates sensitive information leakage from the kernel heap or socket buffer tail room directly into network configuration data visible to local users. If the malformed Route Information Option is followed by other Neighbor Discovery options in the packet, such as a Source Link-Layer Address option containing arbitrary data like 01 01 de ad be ef ca fe, those bytes are read and appended to the route prefix. This allows an attacker on the same network segment to inject specific byte sequences into kernel memory structures that are then reflected back through standard system commands. If the Route Information Option is positioned at the end of the packet with no subsequent options, the out-of-bounds read pulls data from the skb tail room, potentially exposing other internal kernel state or random heap contents. This behavior classifies as an improper input validation failure leading to information exposure, aligning with CWE-20 and CWE-134 respectively in terms of root cause and impact classification.
From a threat modeling perspective using the MITRE ATT&CK framework, this vulnerability supports reconnaissance activities by allowing local or network-based attackers to gather system-specific data that could aid in further exploitation attempts. The ability to read arbitrary kernel memory via standard routing table queries provides an attacker with valuable intelligence regarding internal IP configurations and potentially other sensitive structures residing near the affected buffer in memory layout. To mitigate this risk, it is imperative to apply vendor-provided security patches that correct the length validation logic in rt6_route_rcv. Administrators should ensure their systems are updated to versions where the Route Information Option length strictly adheres to RFC 4191 requirements before processing Neighbor Discovery messages. Additionally, deploying network intrusion detection systems capable of identifying malformed IPv6 Router Advertisements with suspicious option lengths can provide an additional layer of defense against exploitation attempts in untrusted network environments until patches are fully deployed across all endpoints.