1. 01 10月, 2019 6 次提交
  2. 21 9月, 2019 13 次提交
  3. 19 9月, 2019 10 次提交
  4. 16 9月, 2019 4 次提交
    • M
      {nl,mac}80211: fix interface combinations on crypto controlled devices · 1aa38ece
      Manikanta Pubbisetty 提交于
      [ Upstream commit e6f4051123fd33901e9655a675b22aefcdc5d277 ]
      
      Commit 33d915d9e8ce ("{nl,mac}80211: allow 4addr AP operation on
      crypto controlled devices") has introduced a change which allows
      4addr operation on crypto controlled devices (ex: ath10k). This
      change has inadvertently impacted the interface combinations logic
      on such devices.
      
      General rule is that software interfaces like AP/VLAN should not be
      listed under supported interface combinations and should not be
      considered during validation of these combinations; because of the
      aforementioned change, AP/VLAN interfaces(if present) will be checked
      against interfaces supported by the device and blocks valid interface
      combinations.
      
      Consider a case where an AP and AP/VLAN are up and running; when a
      second AP device is brought up on the same physical device, this AP
      will be checked against the AP/VLAN interface (which will not be
      part of supported interface combinations of the device) and blocks
      second AP to come up.
      
      Add a new API cfg80211_iftype_allowed() to fix the problem, this
      API works for all devices with/without SW crypto control.
      Signed-off-by: NManikanta Pubbisetty <mpubbise@codeaurora.org>
      Fixes: 33d915d9e8ce ("{nl,mac}80211: allow 4addr AP operation on crypto controlled devices")
      Link: https://lore.kernel.org/r/1563779690-9716-1-git-send-email-mpubbise@codeaurora.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1aa38ece
    • D
      hv_sock: Fix hang when a connection is closed · 91a71a61
      Dexuan Cui 提交于
      [ Upstream commit 685703b497bacea8765bb409d6b73455b73c540e ]
      
      There is a race condition for an established connection that is being closed
      by the guest: the refcnt is 4 at the end of hvs_release() (Note: here the
      'remove_sock' is false):
      
      1 for the initial value;
      1 for the sk being in the bound list;
      1 for the sk being in the connected list;
      1 for the delayed close_work.
      
      After hvs_release() finishes, __vsock_release() -> sock_put(sk) *may*
      decrease the refcnt to 3.
      
      Concurrently, hvs_close_connection() runs in another thread:
        calls vsock_remove_sock() to decrease the refcnt by 2;
        call sock_put() to decrease the refcnt to 0, and free the sk;
        next, the "release_sock(sk)" may hang due to use-after-free.
      
      In the above, after hvs_release() finishes, if hvs_close_connection() runs
      faster than "__vsock_release() -> sock_put(sk)", then there is not any issue,
      because at the beginning of hvs_close_connection(), the refcnt is still 4.
      
      The issue can be resolved if an extra reference is taken when the
      connection is established.
      
      Fixes: a9eeb998c28d ("hv_sock: Add support for delayed close")
      Signed-off-by: NDexuan Cui <decui@microsoft.com>
      Reviewed-by: NSunil Muthuswamy <sunilmut@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      91a71a61
    • S
      batman-adv: Only read OGM tvlv_len after buffer len check · 86d5ae21
      Sven Eckelmann 提交于
      commit a15d56a60760aa9dbe26343b9a0ac5228f35d445 upstream.
      
      Multiple batadv_ogm_packet can be stored in an skbuff. The functions
      batadv_iv_ogm_send_to_if()/batadv_iv_ogm_receive() use
      batadv_iv_ogm_aggr_packet() to check if there is another additional
      batadv_ogm_packet in the skb or not before they continue processing the
      packet.
      
      The length for such an OGM is BATADV_OGM_HLEN +
      batadv_ogm_packet->tvlv_len. The check must first check that at least
      BATADV_OGM_HLEN bytes are available before it accesses tvlv_len (which is
      part of the header. Otherwise it might try read outside of the currently
      available skbuff to get the content of tvlv_len.
      
      Fixes: ef261577 ("batman-adv: tvlv - basic infrastructure")
      Reported-by: syzbot+355cab184197dbbfa384@syzkaller.appspotmail.com
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      Acked-by: NAntonio Quartulli <a@unstable.cc>
      Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86d5ae21
    • E
      batman-adv: fix uninit-value in batadv_netlink_get_ifindex() · 4b5fee45
      Eric Dumazet 提交于
      commit 3ee1bb7aae97324ec9078da1f00cb2176919563f upstream.
      
      batadv_netlink_get_ifindex() needs to make sure user passed
      a correct u32 attribute.
      
      syzbot reported :
      BUG: KMSAN: uninit-value in batadv_netlink_dump_hardif+0x70d/0x880 net/batman-adv/netlink.c:968
      CPU: 1 PID: 11705 Comm: syz-executor888 Not tainted 5.1.0+ #1
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x191/0x1f0 lib/dump_stack.c:113
       kmsan_report+0x130/0x2a0 mm/kmsan/kmsan.c:622
       __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:310
       batadv_netlink_dump_hardif+0x70d/0x880 net/batman-adv/netlink.c:968
       genl_lock_dumpit+0xc6/0x130 net/netlink/genetlink.c:482
       netlink_dump+0xa84/0x1ab0 net/netlink/af_netlink.c:2253
       __netlink_dump_start+0xa3a/0xb30 net/netlink/af_netlink.c:2361
       genl_family_rcv_msg net/netlink/genetlink.c:550 [inline]
       genl_rcv_msg+0xfc1/0x1a40 net/netlink/genetlink.c:627
       netlink_rcv_skb+0x431/0x620 net/netlink/af_netlink.c:2486
       genl_rcv+0x63/0x80 net/netlink/genetlink.c:638
       netlink_unicast_kernel net/netlink/af_netlink.c:1311 [inline]
       netlink_unicast+0xf3e/0x1020 net/netlink/af_netlink.c:1337
       netlink_sendmsg+0x127e/0x12f0 net/netlink/af_netlink.c:1926
       sock_sendmsg_nosec net/socket.c:651 [inline]
       sock_sendmsg net/socket.c:661 [inline]
       ___sys_sendmsg+0xcc6/0x1200 net/socket.c:2260
       __sys_sendmsg net/socket.c:2298 [inline]
       __do_sys_sendmsg net/socket.c:2307 [inline]
       __se_sys_sendmsg+0x305/0x460 net/socket.c:2305
       __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2305
       do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      RIP: 0033:0x440209
      
      Fixes: b60620cf ("batman-adv: netlink: hardif query")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4b5fee45
  5. 10 9月, 2019 7 次提交