4.19-stable patches

added patches:
	bluetooth-eliminate-the-potential-race-condition-when-removing-the-hci-controller.patch
	bluetooth-verify-amp-hci_chan-before-amp_destroy.patch
	hsr-use-netdev_err-instead-of-warn_once.patch
	net-nfc-fix-use-after-free-llcp_sock_bind-connect.patch

diff --git a/queue-4.19/bluetooth-eliminate-the-potential-race-condition-when-removing-the-hci-controller.patch b/queue-4.19/bluetooth-eliminate-the-potential-race-condition-when-removing-the-hci-controller.patch
new file mode 100644 (file)
index 0000000..2e5b7aa
--- /dev/null
+++ b/queue-4.19/bluetooth-eliminate-the-potential-race-condition-when-removing-the-hci-controller.patch
@@ -0,0 +1,53 @@
+From e2cb6b891ad2b8caa9131e3be70f45243df82a80 Mon Sep 17 00:00:00 2001
+From: Lin Ma <linma@zju.edu.cn>
+Date: Mon, 12 Apr 2021 19:17:57 +0800
+Subject: bluetooth: eliminate the potential race condition when removing the HCI controller
+
+From: Lin Ma <linma@zju.edu.cn>
+
+commit e2cb6b891ad2b8caa9131e3be70f45243df82a80 upstream.
+
+There is a possible race condition vulnerability between issuing a HCI
+command and removing the cont.  Specifically, functions hci_req_sync()
+and hci_dev_do_close() can race each other like below:
+
+thread-A in hci_req_sync()      |   thread-B in hci_dev_do_close()
+                                |   hci_req_sync_lock(hdev);
+test_bit(HCI_UP, &hdev->flags); |
+...                             |   test_and_clear_bit(HCI_UP, &hdev->flags)
+hci_req_sync_lock(hdev);        |
+                                |
+In this commit we alter the sequence in function hci_req_sync(). Hence,
+the thread-A cannot issue th.
+
+Signed-off-by: Lin Ma <linma@zju.edu.cn>
+Cc: Marcel Holtmann <marcel@holtmann.org>
+Fixes: 7c6a329e4447 ("[Bluetooth] Fix regression from using default link policy")
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/hci_request.c |   12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+--- a/net/bluetooth/hci_request.c
++++ b/net/bluetooth/hci_request.c
+@@ -271,12 +271,16 @@ int hci_req_sync(struct hci_dev *hdev, i
+ {
+       int ret;
+ 
+-      if (!test_bit(HCI_UP, &hdev->flags))
+-              return -ENETDOWN;
+-
+       /* Serialize all requests */
+       hci_req_sync_lock(hdev);
+-      ret = __hci_req_sync(hdev, req, opt, timeout, hci_status);
++      /* check the state after obtaing the lock to protect the HCI_UP
++       * against any races from hci_dev_do_close when the controller
++       * gets removed.
++       */
++      if (test_bit(HCI_UP, &hdev->flags))
++              ret = __hci_req_sync(hdev, req, opt, timeout, hci_status);
++      else
++              ret = -ENETDOWN;
+       hci_req_sync_unlock(hdev);
+ 
+       return ret;

diff --git a/queue-4.19/bluetooth-verify-amp-hci_chan-before-amp_destroy.patch b/queue-4.19/bluetooth-verify-amp-hci_chan-before-amp_destroy.patch
new file mode 100644 (file)
index 0000000..21abc1a
--- /dev/null
+++ b/queue-4.19/bluetooth-verify-amp-hci_chan-before-amp_destroy.patch
@@ -0,0 +1,138 @@
+From 5c4c8c9544099bb9043a10a5318130a943e32fc3 Mon Sep 17 00:00:00 2001
+From: Archie Pusaka <apusaka@chromium.org>
+Date: Mon, 22 Mar 2021 14:03:11 +0800
+Subject: Bluetooth: verify AMP hci_chan before amp_destroy
+
+From: Archie Pusaka <apusaka@chromium.org>
+
+commit 5c4c8c9544099bb9043a10a5318130a943e32fc3 upstream.
+
+hci_chan can be created in 2 places: hci_loglink_complete_evt() if
+it is an AMP hci_chan, or l2cap_conn_add() otherwise. In theory,
+Only AMP hci_chan should be removed by a call to
+hci_disconn_loglink_complete_evt(). However, the controller might mess
+up, call that function, and destroy an hci_chan which is not initiated
+by hci_loglink_complete_evt().
+
+This patch adds a verification that the destroyed hci_chan must have
+been init'd by hci_loglink_complete_evt().
+
+Example crash call trace:
+Call Trace:
+ __dump_stack lib/dump_stack.c:77 [inline]
+ dump_stack+0xe3/0x144 lib/dump_stack.c:118
+ print_address_description+0x67/0x22a mm/kasan/report.c:256
+ kasan_report_error mm/kasan/report.c:354 [inline]
+ kasan_report mm/kasan/report.c:412 [inline]
+ kasan_report+0x251/0x28f mm/kasan/report.c:396
+ hci_send_acl+0x3b/0x56e net/bluetooth/hci_core.c:4072
+ l2cap_send_cmd+0x5af/0x5c2 net/bluetooth/l2cap_core.c:877
+ l2cap_send_move_chan_cfm_icid+0x8e/0xb1 net/bluetooth/l2cap_core.c:4661
+ l2cap_move_fail net/bluetooth/l2cap_core.c:5146 [inline]
+ l2cap_move_channel_rsp net/bluetooth/l2cap_core.c:5185 [inline]
+ l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:5464 [inline]
+ l2cap_sig_channel net/bluetooth/l2cap_core.c:5799 [inline]
+ l2cap_recv_frame+0x1d12/0x51aa net/bluetooth/l2cap_core.c:7023
+ l2cap_recv_acldata+0x2ea/0x693 net/bluetooth/l2cap_core.c:7596
+ hci_acldata_packet net/bluetooth/hci_core.c:4606 [inline]
+ hci_rx_work+0x2bd/0x45e net/bluetooth/hci_core.c:4796
+ process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175
+ worker_thread+0x4fc/0x670 kernel/workqueue.c:2321
+ kthread+0x2f0/0x304 kernel/kthread.c:253
+ ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
+
+Allocated by task 38:
+ set_track mm/kasan/kasan.c:460 [inline]
+ kasan_kmalloc+0x8d/0x9a mm/kasan/kasan.c:553
+ kmem_cache_alloc_trace+0x102/0x129 mm/slub.c:2787
+ kmalloc include/linux/slab.h:515 [inline]
+ kzalloc include/linux/slab.h:709 [inline]
+ hci_chan_create+0x86/0x26d net/bluetooth/hci_conn.c:1674
+ l2cap_conn_add.part.0+0x1c/0x814 net/bluetooth/l2cap_core.c:7062
+ l2cap_conn_add net/bluetooth/l2cap_core.c:7059 [inline]
+ l2cap_connect_cfm+0x134/0x852 net/bluetooth/l2cap_core.c:7381
+ hci_connect_cfm+0x9d/0x122 include/net/bluetooth/hci_core.h:1404
+ hci_remote_ext_features_evt net/bluetooth/hci_event.c:4161 [inline]
+ hci_event_packet+0x463f/0x72fa net/bluetooth/hci_event.c:5981
+ hci_rx_work+0x197/0x45e net/bluetooth/hci_core.c:4791
+ process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175
+ worker_thread+0x4fc/0x670 kernel/workqueue.c:2321
+ kthread+0x2f0/0x304 kernel/kthread.c:253
+ ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
+
+Freed by task 1732:
+ set_track mm/kasan/kasan.c:460 [inline]
+ __kasan_slab_free mm/kasan/kasan.c:521 [inline]
+ __kasan_slab_free+0x106/0x128 mm/kasan/kasan.c:493
+ slab_free_hook mm/slub.c:1409 [inline]
+ slab_free_freelist_hook+0xaa/0xf6 mm/slub.c:1436
+ slab_free mm/slub.c:3009 [inline]
+ kfree+0x182/0x21e mm/slub.c:3972
+ hci_disconn_loglink_complete_evt net/bluetooth/hci_event.c:4891 [inline]
+ hci_event_packet+0x6a1c/0x72fa net/bluetooth/hci_event.c:6050
+ hci_rx_work+0x197/0x45e net/bluetooth/hci_core.c:4791
+ process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175
+ worker_thread+0x4fc/0x670 kernel/workqueue.c:2321
+ kthread+0x2f0/0x304 kernel/kthread.c:253
+ ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
+
+The buggy address belongs to the object at ffff8881d7af9180
+ which belongs to the cache kmalloc-128 of size 128
+The buggy address is located 24 bytes inside of
+ 128-byte region [ffff8881d7af9180, ffff8881d7af9200)
+The buggy address belongs to the page:
+page:ffffea00075ebe40 count:1 mapcount:0 mapping:ffff8881da403200 index:0x0
+flags: 0x8000000000000200(slab)
+raw: 8000000000000200 dead000000000100 dead000000000200 ffff8881da403200
+raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000
+page dumped because: kasan: bad access detected
+
+Memory state around the buggy address:
+ ffff8881d7af9080: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
+ ffff8881d7af9100: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
+>ffff8881d7af9180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+                            ^
+ ffff8881d7af9200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+ ffff8881d7af9280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+
+Signed-off-by: Archie Pusaka <apusaka@chromium.org>
+Reported-by: syzbot+98228e7407314d2d4ba2@syzkaller.appspotmail.com
+Reviewed-by: Alain Michaud <alainm@chromium.org>
+Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Cc: George Kennedy <george.kennedy@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/net/bluetooth/hci_core.h |    1 +
+ net/bluetooth/hci_event.c        |    3 ++-
+ 2 files changed, 3 insertions(+), 1 deletion(-)
+
+--- a/include/net/bluetooth/hci_core.h
++++ b/include/net/bluetooth/hci_core.h
+@@ -526,6 +526,7 @@ struct hci_chan {
+       struct sk_buff_head data_q;
+       unsigned int    sent;
+       __u8            state;
++      bool            amp;
+ };
+ 
+ struct hci_conn_params {
+--- a/net/bluetooth/hci_event.c
++++ b/net/bluetooth/hci_event.c
+@@ -4721,6 +4721,7 @@ static void hci_loglink_complete_evt(str
+               return;
+ 
+       hchan->handle = le16_to_cpu(ev->handle);
++      hchan->amp = true;
+ 
+       BT_DBG("hcon %p mgr %p hchan %p", hcon, hcon->amp_mgr, hchan);
+ 
+@@ -4753,7 +4754,7 @@ static void hci_disconn_loglink_complete
+       hci_dev_lock(hdev);
+ 
+       hchan = hci_chan_lookup_handle(hdev, le16_to_cpu(ev->handle));
+-      if (!hchan)
++      if (!hchan || !hchan->amp)
+               goto unlock;
+ 
+       amp_destroy_logical_link(hchan, ev->reason);

diff --git a/queue-4.19/hsr-use-netdev_err-instead-of-warn_once.patch b/queue-4.19/hsr-use-netdev_err-instead-of-warn_once.patch
new file mode 100644 (file)
index 0000000..3963e34
--- /dev/null
+++ b/queue-4.19/hsr-use-netdev_err-instead-of-warn_once.patch
@@ -0,0 +1,35 @@
+From 4b793acdca0050739b99ace6a8b9e7f717f57c6b Mon Sep 17 00:00:00 2001
+From: Taehee Yoo <ap420073@gmail.com>
+Date: Fri, 28 Feb 2020 18:01:46 +0000
+Subject: hsr: use netdev_err() instead of WARN_ONCE()
+
+From: Taehee Yoo <ap420073@gmail.com>
+
+commit 4b793acdca0050739b99ace6a8b9e7f717f57c6b upstream.
+
+When HSR interface is sending a frame, it finds a node with
+the destination ethernet address from the list.
+If there is no node, it calls WARN_ONCE().
+But, using WARN_ONCE() for this situation is a little bit overdoing.
+So, in this patch, the netdev_err() is used instead.
+
+Signed-off-by: Taehee Yoo <ap420073@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Cc: George Kennedy <george.kennedy@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/hsr/hsr_framereg.c |    3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/net/hsr/hsr_framereg.c
++++ b/net/hsr/hsr_framereg.c
+@@ -310,7 +310,8 @@ void hsr_addr_subst_dest(struct hsr_node
+ 
+       node_dst = find_node_by_AddrA(&port->hsr->node_db, eth_hdr(skb)->h_dest);
+       if (!node_dst) {
+-              WARN_ONCE(1, "%s: Unknown node\n", __func__);
++              if (net_ratelimit())
++                      netdev_err(skb->dev, "%s: Unknown node\n", __func__);
+               return;
+       }
+       if (port->type != node_dst->AddrB_port)

diff --git a/queue-4.19/net-nfc-fix-use-after-free-llcp_sock_bind-connect.patch b/queue-4.19/net-nfc-fix-use-after-free-llcp_sock_bind-connect.patch
new file mode 100644 (file)
index 0000000..83750c5
--- /dev/null
+++ b/queue-4.19/net-nfc-fix-use-after-free-llcp_sock_bind-connect.patch
@@ -0,0 +1,73 @@
+From c61760e6940dd4039a7f5e84a6afc9cdbf4d82b6 Mon Sep 17 00:00:00 2001
+From: Or Cohen <orcohen@paloaltonetworks.com>
+Date: Tue, 4 May 2021 10:16:46 +0300
+Subject: net/nfc: fix use-after-free llcp_sock_bind/connect
+
+From: Or Cohen <orcohen@paloaltonetworks.com>
+
+commit c61760e6940dd4039a7f5e84a6afc9cdbf4d82b6 upstream.
+
+Commits 8a4cd82d ("nfc: fix refcount leak in llcp_sock_connect()")
+and c33b1cc62 ("nfc: fix refcount leak in llcp_sock_bind()")
+fixed a refcount leak bug in bind/connect but introduced a
+use-after-free if the same local is assigned to 2 different sockets.
+
+This can be triggered by the following simple program:
+    int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP );
+    int sock2 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP );
+    memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) );
+    addr.sa_family = AF_NFC;
+    addr.nfc_protocol = NFC_PROTO_NFC_DEP;
+    bind( sock1, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) )
+    bind( sock2, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) )
+    close(sock1);
+    close(sock2);
+
+Fix this by assigning NULL to llcp_sock->local after calling
+nfc_llcp_local_put.
+
+This addresses CVE-2021-23134.
+
+Reported-by: Or Cohen <orcohen@paloaltonetworks.com>
+Reported-by: Nadav Markus <nmarkus@paloaltonetworks.com>
+Fixes: c33b1cc62 ("nfc: fix refcount leak in llcp_sock_bind()")
+Signed-off-by: Or Cohen <orcohen@paloaltonetworks.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/nfc/llcp_sock.c |    4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/net/nfc/llcp_sock.c
++++ b/net/nfc/llcp_sock.c
+@@ -121,12 +121,14 @@ static int llcp_sock_bind(struct socket
+                                         GFP_KERNEL);
+       if (!llcp_sock->service_name) {
+               nfc_llcp_local_put(llcp_sock->local);
++              llcp_sock->local = NULL;
+               ret = -ENOMEM;
+               goto put_dev;
+       }
+       llcp_sock->ssap = nfc_llcp_get_sdp_ssap(local, llcp_sock);
+       if (llcp_sock->ssap == LLCP_SAP_MAX) {
+               nfc_llcp_local_put(llcp_sock->local);
++              llcp_sock->local = NULL;
+               kfree(llcp_sock->service_name);
+               llcp_sock->service_name = NULL;
+               ret = -EADDRINUSE;
+@@ -721,6 +723,7 @@ static int llcp_sock_connect(struct sock
+       llcp_sock->ssap = nfc_llcp_get_local_ssap(local);
+       if (llcp_sock->ssap == LLCP_SAP_MAX) {
+               nfc_llcp_local_put(llcp_sock->local);
++              llcp_sock->local = NULL;
+               ret = -ENOMEM;
+               goto put_dev;
+       }
+@@ -759,6 +762,7 @@ static int llcp_sock_connect(struct sock
+ sock_unlink:
+       nfc_llcp_put_ssap(local, llcp_sock->ssap);
+       nfc_llcp_local_put(llcp_sock->local);
++      llcp_sock->local = NULL;
+ 
+       nfc_llcp_sock_unlink(&local->connecting_sockets, sk);
+       kfree(llcp_sock->service_name);