1. 21 May, 2019 3 commits
    • YueHaibing's avatar
      ipvs: Fix use-after-free in ip_vs_in · 719c7d56
      YueHaibing authored
      BUG: KASAN: use-after-free in ip_vs_in.part.29+0xe8/0xd20 [ip_vs]
      Read of size 4 at addr ffff8881e9b26e2c by task sshd/5603
      
      CPU: 0 PID: 5603 Comm: sshd Not tainted 4.19.39+ #30
      Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
      Call Trace:
       dump_stack+0x71/0xab
       print_address_description+0x6a/0x270
       kasan_report+0x179/0x2c0
       ip_vs_in.part.29+0xe8/0xd20 [ip_vs]
       ip_vs_in+0xd8/0x170 [ip_vs]
       nf_hook_slow+0x5f/0xe0
       __ip_local_out+0x1d5/0x250
       ip_local_out+0x19/0x60
       __tcp_transmit_skb+0xba1/0x14f0
       tcp_write_xmit+0x41f/0x1ed0
       ? _copy_from_iter_full+0xca/0x340
       __tcp_push_pending_frames+0x52/0x140
       tcp_sendmsg_locked+0x787/0x1600
       ? tcp_sendpage+0x60/0x60
       ? inet_sk_set_state+0xb0/0xb0
       tcp_sendmsg+0x27/0x40
       sock_sendmsg+0x6d/0x80
       sock_write_iter+0x121/0x1c0
       ? sock_sendmsg+0x80/0x80
       __vfs_write+0x23e/0x370
       vfs_write+0xe7/0x230
       ksys_write+0xa1/0x120
       ? __ia32_sys_read+0x50/0x50
       ? __audit_syscall_exit+0x3ce/0x450
       do_syscall_64+0x73/0x200
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7ff6f6147c60
      Code: 73 01 c3 48 8b 0d 28 12 2d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 5d 73 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83
      RSP: 002b:00007ffd772ead18 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000000000034 RCX: 00007ff6f6147c60
      RDX: 0000000000000034 RSI: 000055df30a31270 RDI: 0000000000000003
      RBP: 000055df30a31270 R08: 0000000000000000 R09: 0000000000000000
      R10: 00007ffd772ead70 R11: 0000000000000246 R12: 00007ffd772ead74
      R13: 00007ffd772eae20 R14: 00007ffd772eae24 R15: 000055df2f12ddc0
      
      Allocated by task 6052:
       kasan_kmalloc+0xa0/0xd0
       __kmalloc+0x10a/0x220
       ops_init+0x97/0x190
       register_pernet_operations+0x1ac/0x360
       register_pernet_subsys+0x24/0x40
       0xffffffffc0ea016d
       do_one_initcall+0x8b/0x253
       do_init_module+0xe3/0x335
       load_module+0x2fc0/0x3890
       __do_sys_finit_module+0x192/0x1c0
       do_syscall_64+0x73/0x200
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Freed by task 6067:
       __kasan_slab_free+0x130/0x180
       kfree+0x90/0x1a0
       ops_free_list.part.7+0xa6/0xc0
       unregister_pernet_operations+0x18b/0x1f0
       unregister_pernet_subsys+0x1d/0x30
       ip_vs_cleanup+0x1d/0xd2f [ip_vs]
       __x64_sys_delete_module+0x20c/0x300
       do_syscall_64+0x73/0x200
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      The buggy address belongs to the object at ffff8881e9b26600 which belongs to the cache kmalloc-4096 of size 4096
      The buggy address is located 2092 bytes inside of 4096-byte region [ffff8881e9b26600, ffff8881e9b27600)
      The buggy address belongs to the page:
      page:ffffea0007a6c800 count:1 mapcount:0 mapping:ffff888107c0e600 index:0x0 compound_mapcount: 0
      flags: 0x17ffffc0008100(slab|head)
      raw: 0017ffffc0008100 dead000000000100 dead000000000200 ffff888107c0e600
      raw: 0000000000000000 0000000080070007 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      while unregistering ipvs module, ops_free_list calls
      __ip_vs_cleanup, then nf_unregister_net_hooks be called to
      do remove nf hook entries. It need a RCU period to finish,
      however net->ipvs is set to NULL immediately, which will
      trigger NULL pointer dereference when a packet is hooked
      and handled by ip_vs_in where net->ipvs is dereferenced.
      
      Another scene is ops_free_list call ops_free to free the
      net_generic directly while __ip_vs_cleanup finished, then
      calling ip_vs_in will triggers use-after-free.
      
      This patch moves nf_unregister_net_hooks from __ip_vs_cleanup()
      to __ip_vs_dev_cleanup(),  where rcu_barrier() is called by
      unregister_pernet_device -> unregister_pernet_operations,
      that will do the needed grace period.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: efe41606 ("ipvs: convert to use pernet nf_hook api")
      Suggested-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Acked-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      719c7d56
    • Phil Sutter's avatar
      netfilter: nft_fib: Fix existence check support · e633508a
      Phil Sutter authored
      NFTA_FIB_F_PRESENT flag was not always honored since eval functions did
      not call nft_fib_store_result in all cases.
      
      Given that in all callsites there is a struct net_device pointer
      available which holds the interface data to be stored in destination
      register, simplify nft_fib_store_result() to just accept that pointer
      instead of the nft_pktinfo pointer and interface index. This also
      allows to drop the index to interface lookup previously needed to get
      the name associated with given index.
      
      Fixes: 055c4b34 ("netfilter: nft_fib: Support existence check")
      Signed-off-by: default avatarPhil Sutter <phil@nwl.cc>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      e633508a
    • Jagdish Motwani's avatar
      netfilter: nf_queue: fix reinject verdict handling · 946c0d8e
      Jagdish Motwani authored
      This patch fixes netfilter hook traversal when there are more than 1 hooks
      returning NF_QUEUE verdict. When the first queue reinjects the packet,
      'nf_reinject' starts traversing hooks with a proper hook_index. However,
      if it again receives a NF_QUEUE verdict (by some other netfilter hook), it
      queues the packet with a wrong hook_index. So, when the second queue
      reinjects the packet, it re-executes hooks in between.
      
      Fixes: 960632ec ("netfilter: convert hook list to an array")
      Signed-off-by: default avatarJagdish Motwani <jagdish.motwani@sophos.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      946c0d8e
  2. 20 May, 2019 1 commit
  3. 18 May, 2019 4 commits
    • David S. Miller's avatar
      Merge branch 'mlxsw-Two-port-module-fixes' · ee8a2b95
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      mlxsw: Two port module fixes
      
      Patch #1 fixes driver initialization failure on old ASICs due to
      unsupported register access. This is fixed by first testing if the
      register is supported.
      
      Patch #2 fixes reading of certain modules' EEPROM. The problem and
      solution are explained in detail in the commit message.
      
      Please consider both patches for stable.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee8a2b95
    • Vadim Pasternak's avatar
      mlxsw: core: Prevent reading unsupported slave address from SFP EEPROM · f1436c80
      Vadim Pasternak authored
      Prevent reading unsupported slave address from SFP EEPROM by testing
      Diagnostic Monitoring Type byte in EEPROM. Read only page zero of
      EEPROM, in case this byte is zero.
      
      If some SFP transceiver does not support Digital Optical Monitoring
      (DOM), reading SFP EEPROM slave address 0x51 could return an error.
      Availability of DOM support is verified by reading from zero page
      Diagnostic Monitoring Type byte describing how diagnostic monitoring is
      implemented by transceiver. If bit 6 of this byte is set, it indicates
      that digital diagnostic monitoring has been implemented. Otherwise it is
      not and transceiver could fail to reply to transaction for slave address
      0x51 [1010001X (A2h)], which is used to access measurements page.
      
      Such issue has been observed when reading cable MCP2M00-xxxx,
      MCP7F00-xxxx, and few others.
      
      Fixes: 2ea10903 ("mlxsw: spectrum: Add support for access cable info via ethtool")
      Fixes: 4400081b ("mlxsw: spectrum: Fix EEPROM access in case of SFP/SFP+")
      Signed-off-by: default avatarVadim Pasternak <vadimp@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f1436c80
    • Vadim Pasternak's avatar
      mlxsw: core: Prevent QSFP module initialization for old hardware · c52ecff7
      Vadim Pasternak authored
      Old Mellanox silicons, like switchx-2, switch-ib do not support reading
      QSFP modules temperature through MTMP register. Attempt to access this
      register on systems equipped with the this kind of silicon will cause
      initialization flow failure.
      Test for hardware resource capability is added in order to distinct
      between old and new silicon - old silicons do not have such capability.
      
      Fixes: 6a79507c ("mlxsw: core: Extend thermal module with per QSFP module thermal zones")
      Fixes: 5c42eaa0 ("mlxsw: core: Extend hwmon interface with QSFP module temperature attributes")
      Reported-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarVadim Pasternak <vadimp@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c52ecff7
    • Jorge E. Moreira's avatar
      vsock/virtio: Initialize core virtio vsock before registering the driver · ba95e5df
      Jorge E. Moreira authored
      Avoid a race in which static variables in net/vmw_vsock/af_vsock.c are
      accessed (while handling interrupts) before they are initialized.
      
      [    4.201410] BUG: unable to handle kernel paging request at ffffffffffffffe8
      [    4.207829] IP: vsock_addr_equals_addr+0x3/0x20
      [    4.211379] PGD 28210067 P4D 28210067 PUD 28212067 PMD 0
      [    4.211379] Oops: 0000 [#1] PREEMPT SMP PTI
      [    4.211379] Modules linked in:
      [    4.211379] CPU: 1 PID: 30 Comm: kworker/1:1 Not tainted 4.14.106-419297-gd7e28cc1f241 #1
      [    4.211379] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
      [    4.211379] Workqueue: virtio_vsock virtio_transport_rx_work
      [    4.211379] task: ffffa3273d175280 task.stack: ffffaea1800e8000
      [    4.211379] RIP: 0010:vsock_addr_equals_addr+0x3/0x20
      [    4.211379] RSP: 0000:ffffaea1800ebd28 EFLAGS: 00010286
      [    4.211379] RAX: 0000000000000002 RBX: 0000000000000000 RCX: ffffffffb94e42f0
      [    4.211379] RDX: 0000000000000400 RSI: ffffffffffffffe0 RDI: ffffaea1800ebdd0
      [    4.211379] RBP: ffffaea1800ebd58 R08: 0000000000000001 R09: 0000000000000001
      [    4.211379] R10: 0000000000000000 R11: ffffffffb89d5d60 R12: ffffaea1800ebdd0
      [    4.211379] R13: 00000000828cbfbf R14: 0000000000000000 R15: ffffaea1800ebdc0
      [    4.211379] FS:  0000000000000000(0000) GS:ffffa3273fd00000(0000) knlGS:0000000000000000
      [    4.211379] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [    4.211379] CR2: ffffffffffffffe8 CR3: 000000002820e001 CR4: 00000000001606e0
      [    4.211379] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [    4.211379] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [    4.211379] Call Trace:
      [    4.211379]  ? vsock_find_connected_socket+0x6c/0xe0
      [    4.211379]  virtio_transport_recv_pkt+0x15f/0x740
      [    4.211379]  ? detach_buf+0x1b5/0x210
      [    4.211379]  virtio_transport_rx_work+0xb7/0x140
      [    4.211379]  process_one_work+0x1ef/0x480
      [    4.211379]  worker_thread+0x312/0x460
      [    4.211379]  kthread+0x132/0x140
      [    4.211379]  ? process_one_work+0x480/0x480
      [    4.211379]  ? kthread_destroy_worker+0xd0/0xd0
      [    4.211379]  ret_from_fork+0x35/0x40
      [    4.211379] Code: c7 47 08 00 00 00 00 66 c7 07 28 00 c7 47 08 ff ff ff ff c7 47 04 ff ff ff ff c3 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 8b 47 08 <3b> 46 08 75 0a 8b 47 04 3b 46 04 0f 94 c0 c3 31 c0 c3 90 66 2e
      [    4.211379] RIP: vsock_addr_equals_addr+0x3/0x20 RSP: ffffaea1800ebd28
      [    4.211379] CR2: ffffffffffffffe8
      [    4.211379] ---[ end trace f31cc4a2e6df3689 ]---
      [    4.211379] Kernel panic - not syncing: Fatal exception in interrupt
      [    4.211379] Kernel Offset: 0x37000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
      [    4.211379] Rebooting in 5 seconds..
      
      Fixes: 22b5c0b6 ("vsock/virtio: fix kernel panic after device hot-unplug")
      Cc: Stefan Hajnoczi <stefanha@redhat.com>
      Cc: Stefano Garzarella <sgarzare@redhat.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: kvm@vger.kernel.org
      Cc: virtualization@lists.linux-foundation.org
      Cc: netdev@vger.kernel.org
      Cc: kernel-team@android.com
      Cc: stable@vger.kernel.org [4.9+]
      Signed-off-by: default avatarJorge E. Moreira <jemoreira@google.com>
      Reviewed-by: default avatarStefano Garzarella <sgarzare@redhat.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Acked-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ba95e5df
  4. 17 May, 2019 20 commits
  5. 16 May, 2019 12 commits