linux-kernel - Re: [PATCH v1 2/2] ipv6: always accept routing headers with 0 segments left

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <0fc38c1b-1a28-4818-b2cc-a661f037999d@silabs.com>
Date: Wed, 26 Jun 2024 12:10:00 +0200
From: Mathis Marion <mathis.marion@...abs.com>
To: Alexander Aring <aahringo@...hat.com>,
        Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: alex.aring@...il.com, davem@...emloft.net, dsahern@...nel.org,
        edumazet@...gle.com, jerome.pouiller@...abs.com, kuba@...nel.org,
        kylian.balan@...abs.com, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, pabeni@...hat.com,
        Michael Richardson <mcr@...delman.ca>
Subject: Re: [PATCH v1 2/2] ipv6: always accept routing headers with 0
 segments left

On 26/06/2024 3:45 AM, Alexander Aring wrote:
> Hi,
> 
> On Tue, Jun 25, 2024 at 5:39 PM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
>>
>> From: Mathis Marion <Mathis.Marion@...abs.com>
>> Date: Mon, 24 Jun 2024 16:15:33 +0200
>>> From: Mathis Marion <mathis.marion@...abs.com>
>>>
>>> Routing headers of type 3 and 4 would be rejected even if segments left
>>> was 0, in the case that they were disabled through system configuration.
>>>
>>> RFC 8200 section 4.4 specifies:
>>>
>>>        If Segments Left is zero, the node must ignore the Routing header
>>>        and proceed to process the next header in the packet, whose type
>>>        is identified by the Next Header field in the Routing header.
>>
>> I think this part is only applied to an unrecognized Routing Type,
>> so only applied when the network stack does not know the type.
>>
>>     https://www.rfc-editor.org/rfc/rfc8200.html#section-4.4
>>
>>     If, while processing a received packet, a node encounters a Routing
>>     header with an unrecognized Routing Type value, the required behavior
>>     of the node depends on the value of the Segments Left field, as
>>     follows:
>>
>>        If Segments Left is zero, the node must ignore the Routing header
>>        and proceed to process the next header in the packet, whose type
>>        is identified by the Next Header field in the Routing header.
>>
>> That's why RPL with segment length 0 was accepted before 8610c7c6e3bd.
>>
>> But now the kernel recognizes RPL and it's intentionally disabled
>> by default with net.ipv6.conf.$DEV.rpl_seg_enabled since introduced.
>>
>> And SRv6 has been rejected since 1ababeba4a21f for the same reason.
> 
> so there might be a need to have an opt-in knob to actually tell the
> kernel ipv6 stack to recognize or not recognize a next header field
> for users wanting to bypass certain next header fields to the user
> space?
> 
> - Alex
> 

My point is that if a particular routing header support is disabled
through system configuration, it should be treated as any unrecognized
header. From my perspective, doing otherwise causes a regression every
time a new routing header is supported.