Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp353195imm; Thu, 10 May 2018 22:21:38 -0700 (PDT) X-Google-Smtp-Source: AB8JxZofMYAq1i5aflYk1O1TPO7iUpAMsYrAmQ2PPHpEjgRotkZC9V3Kg2WUUPtVKqeKFqqWjIyc X-Received: by 2002:a17:902:b702:: with SMTP id d2-v6mr4057034pls.228.1526016098463; Thu, 10 May 2018 22:21:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526016098; cv=none; d=google.com; s=arc-20160816; b=CuIQFeJ6SlUfF85JNMb3DjbHnJDL4wXWl2qRX/lXziTW5U5BzA4YVK+bR65Wd+xE3S 4MvA8eAN57m7IuUIwQdy6jp2HIBheQ5S//gnb9Xgufe1qjHXO2DEG/YRBA3lsaNAkKBL qhjDoZeWi3vfWdd/2ey2arYYs2acybaUsPWJTniluuLsGmWj63NHOvXA9VTvQhxuPBaa nbSej6YSHOLLgHYIkVIN8SieSdGCDyiod/E4HQ4SUHxwWYI3GESPoWlzkbUxpkO32zgd knaYf9Dap6VGWd4eopLC9Iml1ZRGwS05c8MozW4Qrx3+ktEV+ZhYIx8jobu7aPQ1/CFJ bg+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:content-disposition :mime-version:message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=TJ22fkqtLUydFxUtOpTFe9NOHR9oS+BYeaFI4oAHitI=; b=ENkOASI9Ss+haFzTXAYjjfpfT1WwbN2Z31XNckStAo3ED3hSrYxFjILjeQddvxdSy9 FQBrcq1ME8yMmi2ApiEOflNhjkRCk2Ubde62aFMb+IPvcVK2pvIR8Gi8ZwkyOiXhnK/G fM1UcS8TwIxWzqMwD4wEef9wPYaOO+SaDkO2YHQM7vcFxICxz0n11JqZX6FH0nLXeWHx zVt6T3M9QGgws4T7VnRf3fmcLEJfcCCETfcc2Y/nEPf63YvTa386PWlOgoT69WExMKI8 ii3xlb24AFfabEg4tb+v6WRsqi1MBXom6EYdCYQJqtaSqleOxwd8Fc4xmUeQC5bziFRK zXKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dzZEYpVM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 127-v6si2547489pfe.49.2018.05.10.22.21.24; Thu, 10 May 2018 22:21:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dzZEYpVM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752191AbeEKFVI (ORCPT + 99 others); Fri, 11 May 2018 01:21:08 -0400 Received: from mail-pl0-f68.google.com ([209.85.160.68]:38560 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751352AbeEKFVG (ORCPT ); Fri, 11 May 2018 01:21:06 -0400 Received: by mail-pl0-f68.google.com with SMTP id c11-v6so2625610plr.5; Thu, 10 May 2018 22:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=TJ22fkqtLUydFxUtOpTFe9NOHR9oS+BYeaFI4oAHitI=; b=dzZEYpVMv0N+3RILXcQHDUuslp8XxcI8qjFP/qk9lrSeGGP/yZiCHAClQR8ek8Vv7M qflh5l985xnguofltfEQKWpBJonu7sCvl9nxnsgJMBk929u2ZNQ01UHdXoVZXGwwgzRF I5ySAMUIjVHyPCuGHUZKJcH6ICIjqSfnb9gDVrhawGvxBzQ0pn9395cSXqdX2jK623Xb KWLo09BotzVHg1D1/zL5DhW58kFRqRu8Jj5okplhQnmVIjGjZaJr/MCia8aC2+PPLy+D IvQaGEkFeIvZBxzj/ro7oUkBztl0HhZ2EKGJjxTze/vSv6UNOAmnfafi3davhqLi5StR y6JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=TJ22fkqtLUydFxUtOpTFe9NOHR9oS+BYeaFI4oAHitI=; b=n++rXT7oMGdQ5NYDh+UoR2CTXTU1EOQgHikLFARbD7GkbAHQmMH/PyDEW3764ZBLOh yI32bhFTxjyC5ktuLzucWSvU39w3BFygP0HHM9AhLgB7f/Pc/lTGoMAIcjK+Bl+zQCRx NdwbPaeo7z2QMNNkHIXAKgIMgxkTyUXwbeuN+YF5qjDFS7w3mf1VfgwG/1K9UOM7Cx1A cKwqrRA0LoYgWeOZIyRDpmT6/x4o5Z4fgJ+DQLE+z1qliZcTdnd4cWoyupylkCLJ3s1g 5WvYG6w2GzM2ktFCzuRCkVZgGupfuyPnceRt/LpKrSbUu1e2GMhPGbChj9T5gMhEwwlB yRgQ== X-Gm-Message-State: ALKqPwfd+EL8otvckXySz8e+xdHY6DQFfHNkRCQkdtUq22RKHB2amhid bifhKf4sAf7Na4Kth+NbzhGkZw== X-Received: by 2002:a17:902:265:: with SMTP id 92-v6mr4007726plc.368.1526016065381; Thu, 10 May 2018 22:21:05 -0700 (PDT) Received: from dragonet.kaist.ac.kr (dragonet.kaist.ac.kr. [143.248.133.220]) by smtp.gmail.com with ESMTPSA id x71-v6sm6685776pfe.47.2018.05.10.22.21.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 10 May 2018 22:21:04 -0700 (PDT) Date: Fri, 11 May 2018 14:20:59 +0900 From: DaeRyong Jeong To: santosh.shilimkar@oracle.com, davem@davemloft.net Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org, rds-devel@oss.oracle.com, linux-kernel@vger.kernel.org, byoungyoung@purdue.edu, kt0755@gmail.com Subject: KASAN: null-ptr-deref Read in rds_ib_get_mr Message-ID: <20180511052056.GA10547@dragonet.kaist.ac.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We report the crash: KASAN: null-ptr-deref Read in rds_ib_get_mr Note that this bug is previously reported by syzkaller. https://syzkaller.appspot.com/bug?id=0bb56a5a48b000b52aa2b0d8dd20b1f545214d91 Nonetheless, this bug has not fixed yet, and we hope that this report and our analysis, which gets help by the RaceFuzzer's feature, will helpful to fix the crash. This crash has been found in v4.17-rc1 using RaceFuzzer (a modified version of Syzkaller), which we describe more at the end of this report. Our analysis shows that the race occurs when invoking two syscalls concurrently, bind$rds and setsockopt$RDS_GET_MR. Analysis: We think the concurrent execution of __rds_rdma_map() and rds_bind() causes the problem. __rds_rdma_map() checks whether rs->rs_bound_addr is 0 or not. But the concurrent execution with rds_bind() can by-pass this check. Therefore, __rds_rdmap_map() calls rs->rs_transport->get_mr() and rds_ib_get_mr() causes the null deref at ib_rdma.c:544 in v4.17-rc1, when dereferencing rs_conn. Thread interleaving: CPU0 (__rds_rdma_map) CPU1 (rds_bind) // rds_add_bound() sets rs->bound_addr as none 0 ret = rds_add_bound(rs, sin->sin_addr.s_addr, &sin->sin_port); if (rs->rs_bound_addr == 0 || !rs->rs_transport) { ret = -ENOTCONN; /* XXX not a great errno */ goto out; } if (rs->rs_transport) { /* previously bound */ trans = rs->rs_transport; if (trans->laddr_check(sock_net(sock->sk), sin->sin_addr.s_addr) != 0) { ret = -ENOPROTOOPT; // rds_remove_bound() sets rs->bound_addr as 0 rds_remove_bound(rs); ... trans_private = rs->rs_transport->get_mr(sg, nents, rs, &mr->r_key); (in rds_ib_get_mr()) struct rds_ib_connection *ic = rs->rs_conn->c_transport_data; Call sequence (v4.17-rc1): CPU0 rds_setsockopt rds_get_mr __rds_rdma_map rds_ib_get_mr CPU1 rds_bind rds_add_bound ... rds_remove_bound Crash log: ================================================================== BUG: KASAN: null-ptr-deref in rds_ib_get_mr+0x3a/0x150 net/rds/ib_rdma.c:544 Read of size 8 at addr 0000000000000068 by task syz-executor0/32067 CPU: 0 PID: 32067 Comm: syz-executor0 Not tainted 4.17.0-rc1 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x166/0x21c lib/dump_stack.c:113 kasan_report_error mm/kasan/report.c:352 [inline] kasan_report+0x140/0x360 mm/kasan/report.c:412 check_memory_region_inline mm/kasan/kasan.c:260 [inline] __asan_load8+0x54/0x90 mm/kasan/kasan.c:699 rds_ib_get_mr+0x3a/0x150 net/rds/ib_rdma.c:544 __rds_rdma_map+0x521/0x9d0 net/rds/rdma.c:271 rds_get_mr+0xad/0xf0 net/rds/rdma.c:333 rds_setsockopt+0x57f/0x720 net/rds/af_rds.c:347 __sys_setsockopt+0x147/0x230 net/socket.c:1903 __do_sys_setsockopt net/socket.c:1914 [inline] __se_sys_setsockopt net/socket.c:1911 [inline] __x64_sys_setsockopt+0x67/0x80 net/socket.c:1911 do_syscall_64+0x15f/0x4a0 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4563f9 RSP: 002b:00007f6a2b3c2b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 000000000072bee0 RCX: 00000000004563f9 RDX: 0000000000000002 RSI: 0000000000000114 RDI: 0000000000000015 RBP: 0000000000000575 R08: 0000000000000020 R09: 0000000000000000 R10: 0000000020000140 R11: 0000000000000246 R12: 00007f6a2b3c36d4 R13: 00000000ffffffff R14: 00000000006fd398 R15: 0000000000000000 ================================================================== = About RaceFuzzer RaceFuzzer is a customized version of Syzkaller, specifically tailored to find race condition bugs in the Linux kernel. While we leverage many different technique, the notable feature of RaceFuzzer is in leveraging a custom hypervisor (QEMU/KVM) to interleave the scheduling. In particular, we modified the hypervisor to intentionally stall a per-core execution, which is similar to supporting per-core breakpoint functionality. This allows RaceFuzzer to force the kernel to deterministically trigger racy condition (which may rarely happen in practice due to randomness in scheduling). RaceFuzzer's C repro always pinpoints two racy syscalls. Since C repro's scheduling synchronization should be performed at the user space, its reproducibility is limited (reproduction may take from 1 second to 10 minutes (or even more), depending on a bug). This is because, while RaceFuzzer precisely interleaves the scheduling at the kernel's instruction level when finding this bug, C repro cannot fully utilize such a feature. Please disregard all code related to "should_hypercall" in the C repro, as this is only for our debugging purposes using our own hypervisor.