linux-kernel - Re: [PATCH] net: ipv6: Fix NULL dereference in ipv6_route_check

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: <4e52b966-308d-41b2-ae60-d8f4b8b1cdd5@kernel.org>
Date: Thu, 27 Mar 2025 09:41:33 -0400
From: David Ahern <dsahern@...nel.org>
To: Sabrina Dubroca <sd@...asysnail.net>,
 Purva Yeshi <purvayeshi550@...il.com>
Cc: "David S . Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: ipv6: Fix NULL dereference in ipv6_route_check_nh

On 3/26/25 6:57 AM, Sabrina Dubroca wrote:
> 2025-03-26, 16:22:15 +0530, Purva Yeshi wrote:
>> Fix Smatch-detected error:
>> net/ipv6/route.c:3427 ip6_route_check_nh() error:
>> we previously assumed '_dev' could be null
> 
> I don't think this can actually happen. ip6_route_check_nh only gets
> called via fib6_nh_init -> ip6_validate_gw -> ip6_route_check_nh, and
> ip6_validate_gw unconditionally does dev = *_dev. Which is fine,
> because its only caller (fib6_nh_init) passes &dev, so that can't be
> NULL (and same for idev).

And fib6_nh_init has:

        struct net_device *dev = NULL;
        struct inet6_dev *idev = NULL;

> 
>> Ensure _dev and idev are checked for NULL before dereferencing in
>> ip6_route_check_nh. Assign NULL explicitly when fib_nh_dev is NULL
>> to prevent unintended dereferences.
> 
> That's a separate issue (if it's really possible - I haven't checked)
> than the smatch report you're quoting above. And if it is, it would
> deserve a Fixes tag for the commit introducing this code.

I do not believe it is a problem.