linux-kernel - Re: [PATCH] netrom: fix possible deadlock between nr_rt_ioctl() and nr_rt_device

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: <29f61bac-ec6a-447d-a2f4-89328eaba688@redhat.com>
Date: Tue, 2 Dec 2025 12:02:02 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Junjie Cao <junjie.cao@...el.com>, davem@...emloft.net,
 edumazet@...gle.com, kuba@...nel.org,
 syzbot+14afda08dc3484d5db82@...kaller.appspotmail.com
Cc: horms@...nel.org, linux-hams@...r.kernel.org, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
 stable@...r.kernel.org
Subject: Re: [PATCH] netrom: fix possible deadlock between nr_rt_ioctl() and
 nr_rt_device_down()

On 11/27/25 9:41 AM, Junjie Cao wrote:
> syzbot reported a circular locking dependency involving
> nr_neigh_list_lock, nr_node_list_lock and nr_node->node_lock in the
> NET/ROM routing code [1].
> 
> One of the problematic scenarios looks like this:
> 
>   CPU0                               CPU1
>   ----                               ----
>   nr_rt_device_down()                nr_rt_ioctl()
>     lock(nr_neigh_list_lock);          nr_del_node()
>     ...                                  lock(nr_node_list_lock);
>     lock(nr_node_list_lock);            nr_remove_neigh();
>                                           lock(nr_neigh_list_lock);
> 
> This creates the following lock chain:
> 
>   nr_neigh_list_lock -> nr_node_list_lock -> &nr_node->node_lock
> 
> while the ioctl path may acquire the locks in the opposite order via
> nr_dec_obs()/nr_del_node(), which makes lockdep complain about a
> possible deadlock.
> 
> Refactor nr_rt_device_down() to avoid nested locking of
> nr_neigh_list_lock and nr_node_list_lock.  The function now performs
> two separate passes: one that walks all nodes under nr_node_list_lock
> and drops routes / reference counts, and a second one that removes
> unused neighbours under nr_neigh_list_lock.
> 
> This also fixes a reference count leak of nr_neigh in the node route
> removal path.

Please don't mix separate fixes; the latter need to go in a different
patch to help reviewers. Also both of them need a suitable Fixes tag.

Thanks,

Paolo