Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3586202pxb; Mon, 24 Jan 2022 12:53:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJyngRHnGrW3rtPCGs0dB9LcCdmiVm+fpSRythaM3PZbpWHeZMkLprg5Rn4GLwBN/07N2IS9 X-Received: by 2002:a17:902:7287:b0:14a:b594:7fa1 with SMTP id d7-20020a170902728700b0014ab5947fa1mr15481114pll.117.1643057597675; Mon, 24 Jan 2022 12:53:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643057597; cv=none; d=google.com; s=arc-20160816; b=Dg4ljQM5/nAeYhgszvFemageuWtjMZ71WcAcxXzb+sBpDKEBUxSsV4DoDjW40qRqSz CUI/B6x2XhxYTzp52R3mqBpEfEdDZiHgZ0W4y0UCXZNIl1ENQab6yh3BuMBI5P1Iv2i5 WEedFZb4ZesYsEq0o/k6jWlOj4bq5hwrbYjMurlEmoyqC0eq4ekrpm0j8UXHNcuMKWw3 G0JJAGm1v67oIwXtoQpl8F9RIIOlZUfqf1/x/YJ2WNoCF9I+i8AYKAYtycrHZheZJapY DUDnrB/af9ESmFkONTWro0rxQQ3OSE8P80+VY82ALOum5cP6qbiQtMLxGrZDaqyYouFl ULmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=Z+oM0jApQQMP924dGWqTRlQVyjC9+WoM780yK47lmRg=; b=pt/m2eWOTEhU50c0F+agMi0oO7gNiH/EHE8BZWfQ9a4dxZcVmtKppJsbBzTPsoFwOm 0M81/nTXk5LGpJs7UW98WGVqb1ysrPOQxXydH4s0tp9+tPhJHvSEAGGiCkFMF7likS2T yp+iKD+G1TQI+g6yuabdV3f3OQOBRbo0Udidfvv3MzDltMHzFJahzaBOt/Kdq4r7GWcE QPusQO8zhI124+hzylU9tM6yyUoxda2qD5IyMpdh8tx7CRYEiOIlaNUpqHl12emSkp/n nxW1V/aXXXhz3eQKEZ0SHmQgxs4KiuBYS2BKZFWDpkYiT1Td/laMIG9PzO/m+0OhCqy+ rotQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Hd46jcAe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o3si3216659pfu.335.2022.01.24.12.53.05; Mon, 24 Jan 2022 12:53:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Hd46jcAe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379124AbiAXUKX (ORCPT + 99 others); Mon, 24 Jan 2022 15:10:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58058 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352168AbiAXTwp (ORCPT ); Mon, 24 Jan 2022 14:52:45 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D558C06138E; Mon, 24 Jan 2022 11:25:44 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E93746148B; Mon, 24 Jan 2022 19:25:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CB115C340E5; Mon, 24 Jan 2022 19:25:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643052343; bh=DJ/cYkr8MzqT7hAfv92BLVMqYFrXoXo4x8FHMhWFLhY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Hd46jcAe/bMRU6y1iTVNEYlRGlbSkIamwpta2/28D0aA7CeE6ak9r1QR4fzYQ8oK8 9kmlYBy+pHVQsVRLgF58RQC4jWOYufYIr0bloFn+kYYqIPylkN4xzUcQVZ6mUibahC JTthaUJooCqKq3DLTz3xoszrcNJzKGWY1GtYbKV4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Krzysztof Kozlowski , "David S. Miller" , syzbot+7f23bcddf626e0593a39@syzkaller.appspotmail.com Subject: [PATCH 5.4 006/320] nfc: llcp: fix NULL error pointer dereference on sendmsg() after failed bind() Date: Mon, 24 Jan 2022 19:39:50 +0100 Message-Id: <20220124183953.977141470@linuxfoundation.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220124183953.750177707@linuxfoundation.org> References: <20220124183953.750177707@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Krzysztof Kozlowski commit dded08927ca3c31a5c37f8e7f95fe98770475dd4 upstream. Syzbot detected a NULL pointer dereference of nfc_llcp_sock->dev pointer (which is a 'struct nfc_dev *') with calls to llcp_sock_sendmsg() after a failed llcp_sock_bind(). The message being sent is a SOCK_DGRAM. KASAN report: BUG: KASAN: null-ptr-deref in nfc_alloc_send_skb+0x2d/0xc0 Read of size 4 at addr 00000000000005c8 by task llcp_sock_nfc_a/899 CPU: 5 PID: 899 Comm: llcp_sock_nfc_a Not tainted 5.16.0-rc6-next-20211224-00001-gc6437fbf18b0 #125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: dump_stack_lvl+0x45/0x59 ? nfc_alloc_send_skb+0x2d/0xc0 __kasan_report.cold+0x117/0x11c ? mark_lock+0x480/0x4f0 ? nfc_alloc_send_skb+0x2d/0xc0 kasan_report+0x38/0x50 nfc_alloc_send_skb+0x2d/0xc0 nfc_llcp_send_ui_frame+0x18c/0x2a0 ? nfc_llcp_send_i_frame+0x230/0x230 ? __local_bh_enable_ip+0x86/0xe0 ? llcp_sock_connect+0x470/0x470 ? llcp_sock_connect+0x470/0x470 sock_sendmsg+0x8e/0xa0 ____sys_sendmsg+0x253/0x3f0 ... The issue was visible only with multiple simultaneous calls to bind() and sendmsg(), which resulted in most of the bind() calls to fail. The bind() was failing on checking if there is available WKS/SDP/SAP (respective bit in 'struct nfc_llcp_local' fields). When there was no available WKS/SDP/SAP, the bind returned error but the sendmsg() to such socket was able to trigger mentioned NULL pointer dereference of nfc_llcp_sock->dev. The code looks simply racy and currently it protects several paths against race with checks for (!nfc_llcp_sock->local) which is NULL-ified in error paths of bind(). The llcp_sock_sendmsg() did not have such check but called function nfc_llcp_send_ui_frame() had, although not protected with lock_sock(). Therefore the race could look like (same socket is used all the time): CPU0 CPU1 ==== ==== llcp_sock_bind() - lock_sock() - success - release_sock() - return 0 llcp_sock_sendmsg() - lock_sock() - release_sock() llcp_sock_bind(), same socket - lock_sock() - error - nfc_llcp_send_ui_frame() - if (!llcp_sock->local) - llcp_sock->local = NULL - nfc_put_device(dev) - dereference llcp_sock->dev - release_sock() - return -ERRNO The nfc_llcp_send_ui_frame() checked llcp_sock->local outside of the lock, which is racy and ineffective check. Instead, its caller llcp_sock_sendmsg(), should perform the check inside lock_sock(). Reported-and-tested-by: syzbot+7f23bcddf626e0593a39@syzkaller.appspotmail.com Fixes: b874dec21d1c ("NFC: Implement LLCP connection less Tx path") Cc: Signed-off-by: Krzysztof Kozlowski Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/nfc/llcp_sock.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/net/nfc/llcp_sock.c +++ b/net/nfc/llcp_sock.c @@ -789,6 +789,11 @@ static int llcp_sock_sendmsg(struct sock lock_sock(sk); + if (!llcp_sock->local) { + release_sock(sk); + return -ENODEV; + } + if (sk->sk_type == SOCK_DGRAM) { DECLARE_SOCKADDR(struct sockaddr_nfc_llcp *, addr, msg->msg_name);