The root cause of the problem is that multiple different tasks initiate NETROM_NODE commands to add new routes, there is no lock between them to protect the same nr_neigh. Task0 may add the nr_neigh.refcount value of 1 on Task1 to routes[2]. When Task3 executes nr_neigh_put(nr_node->routes[2].neighbour), it will release the neighbour because its refcount value is 1. In this case, the following situation causes a UAF: Task0 Task1 ===== ===== nr_add_node() nr_neigh_get_dev() nr_add_node() nr_node->routes[2].neighbour->count-- nr_neigh_put(nr_node->routes[2].neighbour); nr_remove_neigh(nr_node->routes[2].neighbour) nr_node->routes[2].neighbour = nr_neigh nr_neigh_hold(nr_neigh); The solution to the problem is to use a lock to synchronize each add a route to node. syzbot reported: BUG: KASAN: slab-use-after-free in nr_add_node+0x25db/0x2c00 net/netrom/nr_route.c:248 Read of size 4 at addr ffff888051e6e9b0 by task syz.1.2539/8741 Call Trace: nr_add_node+0x25db/0x2c00 net/netrom/nr_route.c:248 Reported-by: syzbot+2860e75836a08b172755@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2860e75836a08b172755 Signed-off-by: Lizhi Xu --- net/netrom/nr_route.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c index b94cb2ffbaf8..ae1e5ee1f52f 100644 --- a/net/netrom/nr_route.c +++ b/net/netrom/nr_route.c @@ -102,7 +102,9 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic, struct nr_neigh *nr_neigh; int i, found; struct net_device *odev; + static DEFINE_MUTEX(add_node_lock); + guard(mutex)(&add_node_lock); if ((odev=nr_dev_get(nr)) != NULL) { /* Can't add routes to ourself */ dev_put(odev); return -EINVAL; -- 2.43.0