netdev - Re: [BUG nexthop] refcount leak in "struct nexthop" handling

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: <aUbnn0uZ3BW997Mx@shredder>
Date: Sat, 20 Dec 2025 20:14:55 +0200
From: Ido Schimmel <idosch@...sch.org>
To: David Ahern <dsahern@...nel.org>
Cc: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	"David S. Miller" <davem@...emloft.net>,
	Kuniyuki Iwashima <kuniyu@...gle.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>,
	Network Development <netdev@...r.kernel.org>
Subject: Re: [BUG nexthop] refcount leak in "struct nexthop" handling

On Sat, Dec 20, 2025 at 10:54:27AM -0700, David Ahern wrote:
> On 12/20/25 7:57 AM, Tetsuo Handa wrote:
> > syzbot is reporting refcount leak in "struct nexthop" handling
> > which manifests as a hung up with below message.
> > 
> 
> ...
> 
> > 
> > Commit ab84be7e54fc ("net: Initial nexthop code") says
> > 
> >   Nexthop notifications are sent when a nexthop is added or deleted,
> >   but NOT if the delete is due to a device event or network namespace
> >   teardown (which also involves device events).
> > 
> > which I guess that it is an intended behavior that
> > nexthop_notify(RTM_DELNEXTHOP) is not called from remove_nexthop() from
> > flush_all_nexthops() from nexthop_net_exit_rtnl() from ops_undo_list()
> >  from cleanup_net() because remove_nexthop() passes nlinfo == NULL.
> > 
> > However, like the attached reproducer demonstrates, it is inevitable that
> > a userspace process terminates and network namespace teardown automatically
> > happens without explicitly invoking RTM_DELNEXTHOP request. The kernel is
> > not currently prepared for such scenario. How to fix this problem?
> > 
> > Link: https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84
> 
> thanks for the report and a reproducer. I am about to go offline for a
> week, so I will not have time to take a look until the last few days of
> December. Adding Ido in case he has time between now and then.

Thanks for the detailed report. The following is derived from the C
reproducer and works for me:

ip netns add ns1
ip -n ns1 -6 nexthop add id 1 blackhole
ip -n ns1 route add blackhole 0.0.0.0/0 nhid 1
ip netns del ns1

Nexthops are flushed when the network namespace is dismantled, but the
error route that is using the nexthop does not release its reference
from the nexthop. Therefore, the nexthop is not deleted and does not
release the reference from its nexthop device (lo in this case).

The following fixes the issue for me:

diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 59a6f0a9638f..7e2c17fec3fc 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -2053,10 +2053,11 @@ int fib_table_flush(struct net *net, struct fib_table *tb, bool flush_all)
 				continue;
 			}
 
-			/* Do not flush error routes if network namespace is
-			 * not being dismantled
+			/* When not flushing the entire table, skip error
+			 * routes that are not marked for deletion.
 			 */
-			if (!flush_all && fib_props[fa->fa_type].error) {
+			if (!flush_all && fib_props[fa->fa_type].error &&
+			    !(fi->fib_flags & RTNH_F_DEAD)) {
 				slen = fa->fa_slen;
 				continue;
 			}

Will post it later this week assuming I don't find problems with it.