| Message ID | 20171206161828.8368-1-Haakon.Bugge@oracle.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On 12/6/2017 8:18 AM, Håkon Bugge wrote: > 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 <haakon.bugge@oracle.com> > Reported-by: syzbot <syzkaller@googlegroups.com> > --- Thanks Haakon for testing and posting out the discussed change out. Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Håkon Bugge <Haakon.Bugge@oracle.com> Date: Wed, 6 Dec 2017 17:18:28 +0100 > 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: ... > The fix is to check the existence of an underlying transport in > __rds_rdma_map(). > > Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com> > Reported-by: syzbot <syzkaller@googlegroups.com> Applied and queued up for -stable, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/rds/rdma.c b/net/rds/rdma.c index 8886f15abe90..bc2f1e0977d6 100644 --- a/net/rds/rdma.c +++ b/net/rds/rdma.c @@ -183,7 +183,7 @@ static int __rds_rdma_map(struct rds_sock *rs, struct rds_get_mr_args *args, 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; }
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 <haakon.bugge@oracle.com> Reported-by: syzbot <syzkaller@googlegroups.com> --- net/rds/rdma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)