Re: [PATCH net v2] ipv6: Implement limits on extension header parsing

[Justin Iurman <justin.iurman@gmail.com>]

On 4/26/26 15:17, Ido Schimmel wrote:
> On Sun, Apr 26, 2026 at 12:38:31PM +0200, Daniel Borkmann wrote:
>> On 4/25/26 12:19 PM, Justin Iurman wrote:
>>> I've given it a lot of thought. I came to the conclusion that we
>>> should use a hard-coded value here as well (just like we did for
>>> 076b8cad77aa, with the same logic), not a sysctl. IMO, the main
>>> reason is that it provides as is a suitable security fix to be
>>> backported, i.e., the max value is the max number of EHs allowed by
>>> RFC 8200, Section 4.1. Also, we remain consistent with
>>> draft-iurman-6man-eh-occurrences (I think Tom is about to send a
>>> revision of the series soon for net-next). What this series does is
>>> not only enforcing ordering, but also verifying the specific number
>>> of occurrences for each type of Extension Header. Which is totally
>>> compatible with what this patch does, i.e., limiting the total
>>> number of Extension Headers (regardless of their types) to 8. I
>>> guess what I'm trying to say is that it seems like a good
>>> plan/compromise and that the aforementioned series would build
>>> perfectly on top of this fix.
>>
>> Initially, I had a hard-coded constant (when it was still 32), but Eric's comment
>> was to rather go with a sysctl, such that if someone unexpectedly complains, then
>> there is still a chance for that person to fix it up via sysctl without having to
>> rebuild the kernel. I'm okay either way, but presumably given we're now being more
>> "aggressive" into lowering the default to 8 rather than 32 then having such a fall-
>> back is probably better.
> 
> I also think that 32 without a sysctl knob is fine (just so that we have
> some upper bound), but if we go with a sysctl then let's make sure that
> it's compatible with Tom's series [1] (I assume he is going to send a
> new version).
> 
> AFAICT it's possible to create conflicting configuration with both
> sysctls (e.g., "enforce_ext_hdr_order" is set to 1 and
> "max_ext_hdrs_number" configured to less than 8). The documentation
> should make the relation between both sysctls clear to users. It can
> also mention that "max_ext_hdrs_number" might be useful when users are
> forced to turn "enforce_ext_hdr_order" off when dealing with hosts that
> send extension headers in an unexpected order. That way, they still have
> an upper bound on the maximum number of extension headers.
> 
> [1] https://lore.kernel.org/netdev/20260314175124.47010-1-tom@herbertland.com/

Ido, Daniel,

As I said, my vote would definitely go to the solution without a sysctl 
for the very reason Ido mentioned. Note that an upper bound of 32 is 
kind of unrealistic, although super (SUPER!) safe. Sending more than 8 
Extension Headers (assuming a different type for each) is not standard 
behavior and would make you non-RFC-compliant anyway. But I'm happy with 
32, as long as we don't define a sysctl for that.