From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oo1-f70.google.com (mail-oo1-f70.google.com [209.85.161.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 10A74175A66 for ; Sun, 21 Jun 2026 23:50:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.70 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782085852; cv=none; b=QcIi94hnowGKxuUiWBzDPZ0bkCQhNikAdI2J/F+lnY0PjgbIFxmQntNl32S/GYqgbjz0PNDOiMZa+4CCuGJEGsDlRqg3jTTVLiADP71fbKFl3cabGlqFYjRNSVIG466ENHs4S0R4bvWMRalv1XBae/UtPy9moJ2U9aJgSQaxslE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782085852; c=relaxed/simple; bh=WGVHvaEJeJHLPDkdgJw2Eae0hgSnHYiEKxcuPkJBxk8=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To: Content-Type; b=abaBsySafEtQsCS7h8tD4nJKKxPx3qvlisnwf2lVeX2Fphp5lFYdF1dDPs0mmEg8GUFTzGjCTb0a9gabqpF5KdROkgLRBiXi8cb5r05vghjIIdpWFU1YtSikpEeFqGZ95C99XVtYp/81u06sqVZ1yVcg6YvJY5VjG0tuXttcQKg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com; arc=none smtp.client-ip=209.85.161.70 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com Received: by mail-oo1-f70.google.com with SMTP id 006d021491bc7-6a0c7849525so4822245eaf.2 for ; Sun, 21 Jun 2026 16:50:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782085850; x=1782690650; h=to:from:subject:message-id:in-reply-to:date:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lxlQcONlZ8bVqBDKpHb23c2ee08wUpQ8ix+l50mzU9k=; b=lK784s6Pw+kJbd1rCRR5RPSce2a/dADWLfSZctqYzj22PbwQJ+jmqVNopajtr882r+ FVWjNt98reTFr2fSbg2umXBs/a8JAkRKjoGGuVCE2OFLXN3GGaOUNJAQVeRjo5p6ljtJ ZMNWWVBLFIRgw5UE7IK/2bc89VCNgmbspaBaB39mxOZqFLEGgdxxLbDSr8E0LzoQpHP5 EUxKXYKUqlXA6xG17MwMS9HAUkJSjjQu00dBkVi3E0DyJiuCJHMlDrwLfK2mM1hyBj9x eFTF2lDmduH5/CBpVHATnIP0XPyuk+npfK5AIUA8SrZKWqvtTyBfU9W2YiGBCxCXyICy 8NNQ== X-Gm-Message-State: AOJu0Yxdv34uw6byHdqYQ7XUrlnusXaELYhZrMTYt7S7aMj2rXAf5NUW LQjRN+5iBQgUVc4PQctNEAzD44zO6+ROmc+tBW/1KmgR8j3xDoInooDSR/ErpiLJdHAAbAn6+W9 8QkZKxkmvhD7fWw0og7dV4VylBiHDTqFb9ylvwdb7E+YrW4TT80lHPiahgY0= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Received: by 2002:a05:6808:d4a:b0:464:5f3:ed1 with SMTP id 5614622812f47-489b0983fe2mr8725829b6e.26.1782085849914; Sun, 21 Jun 2026 16:50:49 -0700 (PDT) Date: Sun, 21 Jun 2026 16:50:49 -0700 In-Reply-To: <6a378362.5c48295d.477b4.003e.GAE@google.com> X-Google-Appengine-App-Id: s~syzkaller X-Google-Appengine-App-Id-Alias: syzkaller Message-ID: <6a3878d9.8ae01289.3f93.0028.GAE@google.com> Subject: Forwarded: [PATCH] nbd: don't warn when reclassifying a busy socket lock From: syzbot To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" For archival purposes, forwarding an incoming command email to linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com. *** Subject: [PATCH] nbd: don't warn when reclassifying a busy socket lock Author: kartikey406@gmail.com #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master nbd_reclassify_socket() warns via WARN_ON_ONCE() if the socket lock is held at the point of reclassification. That assertion was copied from nvme-tcp, where the socket is created internally by the kernel (sock_create_kern()) and is never visible to user space, so the lock is guaranteed to be free. NBD is different: the socket is looked up from a user-supplied fd in nbd_get_socket(), and user space retains that fd. A concurrent syscall on the same socket (or softirq processing taking bh_lock_sock() on a connected TCP socket) can legitimately hold the lock at the instant NBD reclassifies it. sock_allow_reclassification() then returns false and the WARN_ON_ONCE() fires, which turns into a crash under panic_on_warn. This is reachable by simply racing NBD_CMD_CONNECT against socket activity on the same fd, as reported by syzbot. Hitting a held lock here is expected for an externally owned socket and is not a kernel bug, so skip reclassification silently instead of warning. Reclassification is a lockdep-only annotation, so skipping it in the rare racing case is harmless. Reported-by: syzbot+6b85d1e39a5b8ed9a954@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6b85d1e39a5b8ed9a954 Fixes: d532cddb6c60 ("nbd: Reclassify sockets to avoid lockdep circular dependency") Signed-off-by: Deepanshu Kartikey --- drivers/block/nbd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c index 3a585a0c882a..8f10762e90ef 100644 --- a/drivers/block/nbd.c +++ b/drivers/block/nbd.c @@ -1246,7 +1246,7 @@ static void nbd_reclassify_socket(struct socket *sock) { struct sock *sk = sock->sk; - if (WARN_ON_ONCE(!sock_allow_reclassification(sk))) + if (!sock_allow_reclassification(sk)) return; switch (sk->sk_family) { -- 2.43.0