netdev - Re: [PATCH net-next v5 6/7] ipv6: Enforce Extension Header ordering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2745371a-8ea2-44c3-9238-93560fcdbb77@gmail.com>
Date: Thu, 29 Jan 2026 21:13:02 +0100
From: Justin Iurman <justin.iurman@...il.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>,
 Tom Herbert <tom@...bertland.com>, davem@...emloft.net, kuba@...nel.org,
 netdev@...r.kernel.org
Subject: Re: [PATCH net-next v5 6/7] ipv6: Enforce Extension Header ordering

On 1/29/26 20:05, Willem de Bruijn wrote:
> Justin Iurman wrote:
>> On 1/29/26 06:18, Willem de Bruijn wrote:
>>> Tom Herbert wrote:
>>>> RFC8200 highly recommends that different Extension Headers be send in
>>>> a prescibed order and all Extension Header types occur at most once
>>>> in a packet with the exception of Destination Options that may
>>>> occur twice. This patch enforces the ordering be folowed in received
>>>> packets.
>>>>
>>>> The allowed order of Extension Headers is:
>>>>
>>>>       IPv6 header
>>>>       Hop-by-Hop Options header
>>>>       Destination Options before the Routing Header
>>>>       Routing header
>>>>       Fragment header
>>>>       Authentication header
>>>>       Encapsulating Security Payload header
>>>>       Destination Options header
>>>>       Upper-Layer header
>>>>
>>>> Each Extension Header may be present only once in a packet.
>>>>
>>>> net.ipv6.enforce_ext_hdr_order is a sysctl to enable or disable
>>>> enforcement of xtension Header order. If it is set to zero then
>>>
>>> [e]xtension. There are a few more typos in the various commit
>>> messages.
>>>
>>>> Extension Header order and number of occurences is not checked
>>>> in receive processeing (except for Hop-by-Hop Options that
>>>> must be the first Extension Header and can only occur once in
>>>> a packet.
>>>
>>> RFC 8200 also states
>>>
>>>      "IPv6 nodes must accept and attempt to process extension headers in
>>>      any order and occurring any number of times in the same packet,
>>>      except for the Hop-by-Hop Options header, which is restricted to
>>>      appear immediately after an IPv6 header only. Nonetheless, it is
>>>      strongly advised that sources of IPv6 packets adhere to the above
>>>      recommended order until and unless subsequent specifications revise
>>>      that recommendation."
>>>
>>> A case of be strict in what you send, liberal in what you accept.
>>>
>>> This new sysctl has a chance of breaking existing users.
>>
>> Willem,
>>
>> Note that RFC8200 does not use normative language, which is part of the
>> problem. It could theoretically break existing users, but I don't think
>> it will in reality. For that, you would need users to beginning with
>> (joke aside, I like EHs). Anyway, if the order is enforced at sending,
>> why would any receiver accept a different order? In this case, being
>> liberal in what we accept might be a security risk (see below).
>>
>>> The series as a whole is framed as a security improvement. Does
>>> enforcing order help with that?
>>
>> IMHO, any packet with EHs in a different order than the one specified in
>> RFC8200 looks suspicious. So, yes.
> 
> Looks suspicious. But does not introduce concrete new risks?
> 
> The main risk I understand around IPv6 extension headers is the risk
> common to all untrusted network input: bugs in parsing code. Bugs can
> cause crashes, infinite loops, or worse subtle effects. This is why we
> introduced the BPF flow dissector, for instance.
> 
> I don't immediately see how different order of headers increases
> parsing risk. Nor, btw, that reducing max number of headers from 8 to
> 2 significantly mitigates a real risk.
> 
> No objections necessarily. But I don't fully understand the argument.

Enforcing the order kills two birds with one stone as it also allows to 
automatically limit the number of DestOpts in general. This is a gap 
introduced by RFC8200, where you "must" accept EHs in any order and 
occurring any number of times in the same packet (even though it says 
that there might be two DestOpts max). The wording is ambiguous and 
non-normative. Since the DestOpt can contain a certain amount of 
options, then you theoretically end up with a nice attack vector.

Regarding why "reducing max number of headers from 8 to 2 significantly 
mitigates a real risk", it's not about the number of EHs, here this is 
about the number of options inside a Hop-by-Hop or Destination Option 
header specifically. Therefore, you further reduce the attack vector.