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-next>] [day] [month] [year] [list]
Message-ID: <20251201185817.1003392-1-tom@herbertland.com>
Date: Mon,  1 Dec 2025 10:55:29 -0800
From: Tom Herbert <tom@...bertland.com>
To: tom@...bertland.com,
	davem@...emloft.net,
	kuba@...nel.org,
	netdev@...r.kernel.org
Subject: [PATCH net-next 0/5] ipv6: Disable IPv6 Destination Options RX processing by default

This patchset set changes the interpretation of the Destination Options
and Hop-by-Hop Options sysctl limits, net.ipv6.max_dst_opts_number and
net.ipv6.max_dst_opts_number to mean that when the sysctl is zero
processing of the associated extension header is disabled such that
packets received with the extension header are dropped.

This patch sets the default limit for Destination Options to zero
meaning that packets with Destination Options are dropped by default.
The rationale for this is that Destinations Options extension header
can be used in an effective Denial of Service attack, and Destination
Options have very little or possibly no deployed use cases anywhere
on the planet.

The Denial of Service attack goes like this: All an attacker needs to
do is create and MTU size packet filled  with 8 bytes DestinationOptions
Extension Headers. Each Destination EH simply contains a single padding
option with six bytes of zeroes. In a 1500 byte MTU size packet, 182 of
these dummy Destination Options headers can be placed in a packet. Per
RFC8200, a host must accept and process a packet with any number of
Destination Options extension headers. So when the stack processes such
a packet is a lot of work and CPU cycles that yield zero benefit.
The packet can be designed such that every byte after the IP header
requires a conditional check and branch prediction can be rendered
useless for that. This also may mean over twenty cache misses per
packet. In other words, these packets filled with dummy Destination
Options extension headers are the basis for what would be an effective
DoS attack.
    
Disabling Destination Options is not a major issue for the following
reasons:

* Linux kernel only supports one Destination Option (Home Address
  Option). There is no evidence this has seen any real world use

* On the Internet packets with Destination Options are dropped with
  a high enough rate such that use of Destination Options is not
  feasible

* It is unknown however quite possible that no one anywhere is using
  Destination Options for anything but experiments, class projects,
  or DoS. If someone is using them in their private network then
  it's easy enough to configure a non-zero limit for their use case
Additionally, this patch set sets the default limit of number of
Hop-by-Hop options to one. The rationale is similar to disabling
Destination options on RX however unlike Destination options
Hop-by-Hop options have one common use case in the Router
Alert option. 

Tom Herbert (5):
  ipv6: Check of max HBH or DestOp sysctl is zero and drop if it is
  ipv6: Disable IPv6 Destination Options RX processing by default
  ipv6: Set Hop-by-Hop options limit to 1
  ipv6: Document default of zero for max_dst_opts_number
  ipv6: Document default of one for max_hbh_opts_number

 Documentation/networking/ip-sysctl.rst | 38 ++++++++++++++++++--------
 include/net/ipv6.h                     |  9 ++++--
 net/ipv6/exthdrs.c                     |  6 ++--
 3 files changed, 37 insertions(+), 16 deletions(-)

-- 
2.43.0


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ