Re: [PATCH net] seg6: fix HMAC validation when an extension header precedes the SRHA

[Andrea Mayer]

On Wed, 23 Sep 2026 13:51:37 +0900
Yuya Kusakabe <yuya.kusakabe@xxxxxxxxx> wrote:

> seg6_hmac_validate_skb() derived the SRH from skb_transport_header().
> That only holds while the two coincide, which is not true on the
> seg6_local input path.
> 
> ip6_rcv_core() leaves the transport header just past the IPv6 header.
> A Hop-by-Hop options header is consumed before the route lookup and
> advances it, but a Destination Options header is not: the seg6_local
> lwtunnel is entered through an input redirect from the route lookup,
> which bypasses the extension header handlers. The transport header
> then still points at the Destination Options header while
> seg6_get_srh() has located the real SRH further down the chain.
> 
> The HMAC is therefore computed over the Destination Options header,
> and a packet carrying a valid HMAC TLV is dropped when
> seg6_require_hmac is set. Such a packet is legitimate: RFC 8200 allows
> Destination Options before a routing header, and get_srh() has walked
> the header chain since commit 5829d70b0b6c ("ipv6: sr: fix get_srh() to
> comply with IPv6 standard "RFC 8200""). The misread header is covered
> by the pskb_may_pull() in seg6_get_srh(), so the result is a wrong
> verdict, not an out-of-bounds access.

Thanks for the patch.

This patch also closes an out-of-bounds read that the commit message
does not mention. The commit says the misread gives a wrong verdict,
not an out-of-bounds access. That holds for Destination Options, which
has the same length encoding as the SRH. A Fragment or an Authentication
header is encoded differently, and a forged packet can put one before
the SRH. The old code read that header at skb_transport_header() as an
SRH, and seg6_get_tlv_hmac() computed the TLV pointer from its second
byte. The pull in seg6_get_srh() covers only the bytes up to the end of
the real SRH, and the TLV pointer can land past them. This runs before
seg6_require_hmac is read, and the default configuration reaches it.

Before this patch, a forged Fragment before the SRH toward an End SID
faults in that read (KASAN, DEBUG_PAGEALLOC):

  BUG: unable to handle page fault for address: ffff888106304078
  RIP: seg6_hmac_validate_skb (net/ipv6/seg6_hmac.c:91 net/ipv6/seg6_hmac.c:192)
   input_action_end_core.isra.0 (net/ipv6/seg6_local.c:225 net/ipv6/seg6_local.c:413)
   seg6_local_input_core (net/ipv6/seg6_local.c:1640)
   seg6_local_input (net/ipv6/seg6_local.c:1662)
  Kernel panic - not syncing: Fatal exception in interrupt

Could the commit message also mention the out-of-bounds read?

Ciao,
Andrea