Received: by 2002:ac0:cd04:0:0:0:0:0 with SMTP id w4csp598493imn; Sat, 2 Jul 2022 01:38:42 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tIHgkaDZXzQrTBKFJdkpfGad+YqgEyYRm1qZyCPouyKLf6B7t0rHtRGy6zSs8VYnm6lRon X-Received: by 2002:a17:90b:388b:b0:1ed:406:492c with SMTP id mu11-20020a17090b388b00b001ed0406492cmr21883636pjb.31.1656751122143; Sat, 02 Jul 2022 01:38:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656751122; cv=none; d=google.com; s=arc-20160816; b=wvuYRPQQp5NlD+QttFNqK2y6W4rlXdk15861sJAIDlAAqBGJiDycBz5He1WGR77jlv NxTAbzEsUharIXA7npyXSi/DgfymtlfTogytpX/vzR5nurE45Y1k1LJww5nvkZJMeo+m RaGymsJBcO0frcgeOITxC91okp0+AWy+5v1jRWc9nZ5iipTRrz25QgtiHBHeIDSBMBE3 SewqFvQfmC1U/FZiFi+P+VOiWo6GjaOLwbonDAfLdRPZrl/wvAwCJKP6Uzq9DPgfbpZA QP9kYBKLFNW9NRNJgHwdg0QjFn7hmoI0Xil4L1N6c36j1X/B8WutgLlDiie2t/8z1UFU x+1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from; bh=MynKp/DtV6g7k0Te2uX/hZuSPm3zLrlVMBMWwcHJXGM=; b=H/vGhDFJDUJocD+inp/UcAzYh/24J97k50IlJbzX2FG6B89g3Cl9mwISAeGbj9SKaG VTN5UhAs7mGeb/yXepJynQAxbdPftGtt8a262zH6u7193V0gP0Ql/vjeLiQVrytybySO BtWNq///N0Idtfh+YFJjoCTUgSr98kdX16L6qswboyHSfubR1NMMlUZXqocdYCG/zg8Z AmAtdLPi6K95B6/K3nHSeBWo6rpAKsEyuxGkYUKIzdD7eLEG5La1r5gVrIhKwuK08Mk4 MCoN2iERkiYLPTso1rChl814nTkPPYk1DNz/d3spv3M/Veo8cenRjr4Q0FiqF/79XFhz +mkw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h189-20020a6383c6000000b003f6230458ebsi31403115pge.412.2022.07.02.01.38.27; Sat, 02 Jul 2022 01:38:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231926AbiGBH5s (ORCPT + 99 others); Sat, 2 Jul 2022 03:57:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52206 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229446AbiGBH5p (ORCPT ); Sat, 2 Jul 2022 03:57:45 -0400 Received: from zju.edu.cn (mail.zju.edu.cn [61.164.42.155]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 744EF21E05; Sat, 2 Jul 2022 00:57:42 -0700 (PDT) Received: from ubuntu.localdomain (unknown [10.190.66.153]) by mail-app2 (Coremail) with SMTP id by_KCgC3v4tf+r9i+PABAw--.43154S2; Sat, 02 Jul 2022 15:57:28 +0800 (CST) From: Duoming Zhou To: linux-hams@vger.kernel.org Cc: ralf@linux-mips.org, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Duoming Zhou Subject: [PATCH net v5] net: rose: fix null-ptr-deref caused by rose_kill_by_neigh Date: Sat, 2 Jul 2022 15:57:18 +0800 Message-Id: <20220702075718.25121-1-duoming@zju.edu.cn> X-Mailer: git-send-email 2.17.1 X-CM-TRANSID: by_KCgC3v4tf+r9i+PABAw--.43154S2 X-Coremail-Antispam: 1UD129KBjvJXoWxJw1fGr1kXFyrXw4fAFWfGrg_yoW5KF4rpF 9xKFW3Grs7Jw4DWFsrJF1UZr4FvF1v9F9rWrWF9F9Fy3Z8GrWjvrykKFWUWr15XFsrGFya gF1UG34ayrnrAw7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUka1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AE w4v_Jr0_Jr4l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2 IY67AKxVWDJVCq3wA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8Jr0_Cr1UM28EF7xvwVC2 z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcV Aq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j 6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64 vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7MxAIw28IcxkI7VAKI48JMxAIw28IcVCjz48v 1sIEY20_GFWkJr1UJwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r 18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vI r41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr 1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvE x4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x0JUdHUDUUUUU= X-CM-SenderInfo: qssqjiasttq6lmxovvfxof0/1tbiAg4TAVZdtaf41gAGsv X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When the link layer connection is broken, the rose->neighbour is set to null. But rose->neighbour could be used by rose_connection() and rose_release() later, because there is no synchronization among them. As a result, the null-ptr-deref bugs will happen. One of the null-ptr-deref bugs is shown below: (thread 1) | (thread 2) | rose_connect rose_kill_by_neigh | lock_sock(sk) spin_lock_bh(&rose_list_lock) | if (!rose->neighbour) rose->neighbour = NULL;//(1) | | rose->neighbour->use++;//(2) The rose->neighbour is set to null in position (1) and dereferenced in position (2). The KASAN report triggered by POC is shown below: KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] ... RIP: 0010:rose_connect+0x6c2/0xf30 RSP: 0018:ffff88800ab47d60 EFLAGS: 00000206 RAX: 0000000000000005 RBX: 000000000000002a RCX: 0000000000000000 RDX: ffff88800ab38000 RSI: ffff88800ab47e48 RDI: ffff88800ab38309 RBP: dffffc0000000000 R08: 0000000000000000 R09: ffffed1001567062 R10: dfffe91001567063 R11: 1ffff11001567061 R12: 1ffff11000d17cd0 R13: ffff8880068be680 R14: 0000000000000002 R15: 1ffff11000d17cd0 ... Call Trace: ? __local_bh_enable_ip+0x54/0x80 ? selinux_netlbl_socket_connect+0x26/0x30 ? rose_bind+0x5b0/0x5b0 __sys_connect+0x216/0x280 __x64_sys_connect+0x71/0x80 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 This patch adds lock_sock() in rose_kill_by_neigh() in order to synchronize with rose_connect() and rose_release(). Meanwhile, this patch adds sock_hold() protected by rose_list_lock that could synchronize with rose_remove_socket() in order to mitigate UAF bug caused by lock_sock() we add. What's more, there is no need using rose_neigh_list_lock to protect rose_kill_by_neigh(). Because we have already used rose_neigh_list_lock to protect the state change of rose_neigh in rose_link_failed(), which is well synchronized. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Duoming Zhou --- Changes in v5: - v5: Use socket lock to protect comparison in rose_kill_by_neigh. net/rose/af_rose.c | 12 ++++++++++++ net/rose/rose_route.c | 2 ++ 2 files changed, 14 insertions(+) diff --git a/net/rose/af_rose.c b/net/rose/af_rose.c index bf2d986a6bc..6d5088b030a 100644 --- a/net/rose/af_rose.c +++ b/net/rose/af_rose.c @@ -165,14 +165,26 @@ void rose_kill_by_neigh(struct rose_neigh *neigh) struct sock *s; spin_lock_bh(&rose_list_lock); +again: sk_for_each(s, &rose_list) { struct rose_sock *rose = rose_sk(s); + sock_hold(s); + spin_unlock_bh(&rose_list_lock); + lock_sock(s); if (rose->neighbour == neigh) { rose_disconnect(s, ENETUNREACH, ROSE_OUT_OF_ORDER, 0); rose->neighbour->use--; rose->neighbour = NULL; + release_sock(s); + sock_put(s); + spin_lock_bh(&rose_list_lock); + goto again; } + release_sock(s); + sock_put(s); + spin_lock_bh(&rose_list_lock); + goto again; } spin_unlock_bh(&rose_list_lock); } diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c index fee6409c2bb..b116828b422 100644 --- a/net/rose/rose_route.c +++ b/net/rose/rose_route.c @@ -827,7 +827,9 @@ void rose_link_failed(ax25_cb *ax25, int reason) ax25_cb_put(ax25); rose_del_route_by_neigh(rose_neigh); + spin_unlock_bh(&rose_neigh_list_lock); rose_kill_by_neigh(rose_neigh); + return; } spin_unlock_bh(&rose_neigh_list_lock); } -- 2.17.1