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: <50e99bc2-b0ca-1e83-004d-ca550294cc95@kernel.org>
Date:   Thu, 17 Mar 2022 12:40:23 -0600
From:   David Ahern <dsahern@...nel.org>
To:     Guillaume Nault <gnault@...hat.com>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>
Cc:     netdev@...r.kernel.org,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        Shuah Khan <shuah@...nel.org>, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net v2 1/2] ipv4: Fix route lookups when handling ICMP
 redirects and PMTU updates

On 3/17/22 6:45 AM, Guillaume Nault wrote:
> The PMTU update and ICMP redirect helper functions initialise their fl4
> variable with either __build_flow_key() or build_sk_flow_key(). These
> initialisation functions always set ->flowi4_scope with
> RT_SCOPE_UNIVERSE and might set the ECN bits of ->flowi4_tos. This is
> not a problem when the route lookup is later done via
> ip_route_output_key_hash(), which properly clears the ECN bits from
> ->flowi4_tos and initialises ->flowi4_scope based on the RTO_ONLINK
> flag. However, some helpers call fib_lookup() directly, without
> sanitising the tos and scope fields, so the route lookup can fail and,
> as a result, the ICMP redirect or PMTU update aren't taken into
> account.
> 
> Fix this by extracting the ->flowi4_tos and ->flowi4_scope sanitisation
> code into ip_rt_fix_tos(), then use this function in handlers that call
> fib_lookup() directly.
> 
> Note 1: We can't sanitise ->flowi4_tos and ->flowi4_scope in a central
> place (like __build_flow_key() or flowi4_init_output()), because
> ip_route_output_key_hash() expects non-sanitised values. When called
> with sanitised values, it can erroneously overwrite RT_SCOPE_LINK with
> RT_SCOPE_UNIVERSE in ->flowi4_scope. Therefore we have to be careful to
> sanitise the values only for those paths that don't call
> ip_route_output_key_hash().
> 
> Note 2: The problem is mostly about sanitising ->flowi4_tos. Having
> ->flowi4_scope initialised with RT_SCOPE_UNIVERSE instead of
> RT_SCOPE_LINK probably wasn't really a problem: sockets with the
> SOCK_LOCALROUTE flag set (those that'd result in RTO_ONLINK being set)
> normally shouldn't receive ICMP redirects or PMTU updates.
> 
> Fixes: 4895c771c7f0 ("ipv4: Add FIB nexthop exceptions.")
> Signed-off-by: Guillaume Nault <gnault@...hat.com>
> ---
>  net/ipv4/route.c | 18 ++++++++++++++----
>  1 file changed, 14 insertions(+), 4 deletions(-)
> 

Reviewed-by: David Ahern <dsahern@...nel.org>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ