1. 12 12月, 2017 3 次提交
  2. 11 12月, 2017 4 次提交
  3. 09 12月, 2017 21 次提交
  4. 08 12月, 2017 10 次提交
  5. 07 12月, 2017 2 次提交
    • H
      rds: Fix NULL pointer dereference in __rds_rdma_map · f3069c6d
      Håkon Bugge 提交于
      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: NHåkon Bugge <haakon.bugge@oracle.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f3069c6d
    • C
      net_sched: use macvlan real dev trans_start in dev_trans_start() · 32d3e51a
      Chris Dion 提交于
      Macvlan devices are similar to vlans and do not update their
      own trans_start. In order for arp monitoring to work for a bond device
      when the slaves are macvlans, obtain its real device.
      Signed-off-by: NChris Dion <christopher.dion@dell.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      32d3e51a