Received: by 10.223.185.116 with SMTP id b49csp6405846wrg; Wed, 28 Feb 2018 08:53:46 -0800 (PST) X-Google-Smtp-Source: AH8x2267tYQOTDrsgALEqdbE8fLWZX99oQctfeRm3N9178xPuPfkXw6aqIuCB75INx8Mp41qyD15 X-Received: by 10.99.190.15 with SMTP id l15mr15089196pgf.325.1519836826846; Wed, 28 Feb 2018 08:53:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519836826; cv=none; d=google.com; s=arc-20160816; b=sWR7LYbmU1yn1t141i4Y0NnSMIS7GF50TWsOQjCftQduHDIbFRjUmIquq3PvU/6yK0 a2tg5yzAU1gri35ZX+fnnWyOEkMthOP2iQmGGnt32CvlUVwaCGh7zqmOrl4+9jtGkr6s SuGNGJt7XvpqYogr0yWQnuFm1Fv4JYypw+8EDlWINmysQYZ0Y16JdhszLGf2bs3S8Mjo zlLgd1caiOJXx7WIboaG92s6nhL9qreP4tiCalkSlc43cdnZVxynoIEAoSOnCHZpx32q E7S5ClYrAKHw3g9z7jNaxuAtupk5t6pxZaWgLGB9YgRLKCjAbLWxlF+3U0N0/YGZ11oB y/Ow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=EP+kInWZwS6IvseZsyR+GBJ6xEHqCywIg6MQhFWRXEA=; b=ukXhx2zJIST2CT5nZzbX2iGtPWAJeLghUtTcEBwmsyPjrVNVltQOmQ3pTE/99pK3ln mz2csTW/DUnjzrLH6Z9llej5QyLPdOb9Eni7/SHFdFaP3FVprMk4DRIhXBz9tfGNFhAo yDEwU+BjX1cFJhl1z7RCMa1YmEBPHw22djidxnVCl2rpU6r8pkfygF145iSYx/9FsQge prm5+SiNg6u0NH2tmjQyaIPLAaFdiysjawLBBPtBep/AWhYbaIzAM05GXZv1EKfk4GgB p6t1GmM31x//UQ2h9pLgglFQwu+4XZHfEz/FA8iTlEBXgeRGDJZTvq3qwDIesMFI5o9D VJMw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h3-v6si1522516pld.180.2018.02.28.08.53.32; Wed, 28 Feb 2018 08:53:46 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932347AbeB1Qw2 (ORCPT + 99 others); Wed, 28 Feb 2018 11:52:28 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:34549 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752952AbeB1P6K (ORCPT ); Wed, 28 Feb 2018 10:58:10 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1er3Ym-0006XR-Au; Wed, 28 Feb 2018 15:22:25 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Yl-0000Kt-AN; Wed, 28 Feb 2018 15:22:23 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Santosh Shilimkar" , "syzbot" , "David S. Miller" , "=?UTF-8?q?H=C3=A5kon=20Bugge?=" , "=?UTF-8?Q?H=C3=A5kon=20?=Bugge" Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 254/254] rds: Fix NULL pointer dereference in __rds_rdma_map In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.55-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Håkon Bugge commit f3069c6d33f6ae63a1668737bc78aaaa51bff7ca upstream. This is a fix for syzkaller719569, where memory registration was attempted without any underlying transport being loaded. Analysis of the case reveals that it is the setsockopt() RDS_GET_MR (2) and RDS_GET_MR_FOR_DEST (7) that are vulnerable. Here is an example stack trace when the bug is hit: BUG: unable to handle kernel NULL pointer dereference at 00000000000000c0 IP: __rds_rdma_map+0x36/0x440 [rds] PGD 2f93d03067 P4D 2f93d03067 PUD 2f93d02067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: bridge stp llc tun rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache rds binfmt_misc sb_edac intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul c rc32_pclmul ghash_clmulni_intel pcbc aesni_intel crypto_simd glue_helper cryptd iTCO_wdt mei_me sg iTCO_vendor_support ipmi_si mei ipmi_devintf nfsd shpchp pcspkr i2c_i801 ioatd ma ipmi_msghandler wmi lpc_ich mfd_core auth_rpcgss nfs_acl lockd grace sunrpc ip_tables ext4 mbcache jbd2 mgag200 i2c_algo_bit drm_kms_helper ixgbe syscopyarea ahci sysfillrect sysimgblt libahci mdio fb_sys_fops ttm ptp libata sd_mod mlx4_core drm crc32c_intel pps_core megaraid_sas i2c_core dca dm_mirror dm_region_hash dm_log dm_mod CPU: 48 PID: 45787 Comm: repro_set2 Not tainted 4.14.2-3.el7uek.x86_64 #2 Hardware name: Oracle Corporation ORACLE SERVER X5-2L/ASM,MOBO TRAY,2U, BIOS 31110000 03/03/2017 task: ffff882f9190db00 task.stack: ffffc9002b994000 RIP: 0010:__rds_rdma_map+0x36/0x440 [rds] RSP: 0018:ffffc9002b997df0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff882fa2182580 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffc9002b997e40 RDI: ffff882fa2182580 RBP: ffffc9002b997e30 R08: 0000000000000000 R09: 0000000000000002 R10: ffff885fb29e3838 R11: 0000000000000000 R12: ffff882fa2182580 R13: ffff882fa2182580 R14: 0000000000000002 R15: 0000000020000ffc FS: 00007fbffa20b700(0000) GS:ffff882fbfb80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000c0 CR3: 0000002f98a66006 CR4: 00000000001606e0 Call Trace: rds_get_mr+0x56/0x80 [rds] rds_setsockopt+0x172/0x340 [rds] ? __fget_light+0x25/0x60 ? __fdget+0x13/0x20 SyS_setsockopt+0x80/0xe0 do_syscall_64+0x67/0x1b0 entry_SYSCALL64_slow_path+0x25/0x25 RIP: 0033:0x7fbff9b117f9 RSP: 002b:00007fbffa20aed8 EFLAGS: 00000293 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00000000000c84a4 RCX: 00007fbff9b117f9 RDX: 0000000000000002 RSI: 0000400000000114 RDI: 000000000000109b RBP: 00007fbffa20af10 R08: 0000000000000020 R09: 00007fbff9dd7860 R10: 0000000020000ffc R11: 0000000000000293 R12: 0000000000000000 R13: 00007fbffa20b9c0 R14: 00007fbffa20b700 R15: 0000000000000021 Code: 41 56 41 55 49 89 fd 41 54 53 48 83 ec 18 8b 87 f0 02 00 00 48 89 55 d0 48 89 4d c8 85 c0 0f 84 2d 03 00 00 48 8b 87 00 03 00 00 <48> 83 b8 c0 00 00 00 00 0f 84 25 03 00 0 0 48 8b 06 48 8b 56 08 The fix is to check the existence of an underlying transport in __rds_rdma_map(). Signed-off-by: Håkon Bugge Reported-by: syzbot Acked-by: Santosh Shilimkar Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- net/rds/rdma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/rds/rdma.c +++ b/net/rds/rdma.c @@ -184,7 +184,7 @@ static int __rds_rdma_map(struct rds_soc long i; int ret; - if (rs->rs_bound_addr == 0) { + if (rs->rs_bound_addr == 0 || !rs->rs_transport) { ret = -ENOTCONN; /* XXX not a great errno */ goto out; }