From: Greg Kroah-Hartman Date: Fri, 10 Mar 2023 12:00:36 +0000 (+0100) Subject: 5.15-stable patches X-Git-Tag: v6.1.17~28 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=6903791c8f2926e9582f33010f7287da7a4f4486;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: bluetooth-hci_sock-purge-socket-queues-in-the-destruct-callback.patch media-uvcvideo-fix-race-condition-with-usb_kill_urb.patch --- diff --git a/queue-5.15/bluetooth-hci_sock-purge-socket-queues-in-the-destruct-callback.patch b/queue-5.15/bluetooth-hci_sock-purge-socket-queues-in-the-destruct-callback.patch new file mode 100644 index 00000000000..b3dc5a2b04f --- /dev/null +++ b/queue-5.15/bluetooth-hci_sock-purge-socket-queues-in-the-destruct-callback.patch @@ -0,0 +1,60 @@ +From 709fca500067524381e28a5f481882930eebac88 Mon Sep 17 00:00:00 2001 +From: Nguyen Dinh Phi +Date: Fri, 8 Oct 2021 03:04:24 +0800 +Subject: Bluetooth: hci_sock: purge socket queues in the destruct() callback + +From: Nguyen Dinh Phi + +commit 709fca500067524381e28a5f481882930eebac88 upstream. + +The receive path may take the socket right before hci_sock_release(), +but it may enqueue the packets to the socket queues after the call to +skb_queue_purge(), therefore the socket can be destroyed without clear +its queues completely. + +Moving these skb_queue_purge() to the hci_sock_destruct() will fix this +issue, because nothing is referencing the socket at this point. + +Signed-off-by: Nguyen Dinh Phi +Reported-by: syzbot+4c4ffd1e1094dae61035@syzkaller.appspotmail.com +Signed-off-by: Marcel Holtmann +Signed-off-by: Fedor Pchelkin +Signed-off-by: Greg Kroah-Hartman +--- + net/bluetooth/hci_sock.c | 11 +++++++---- + 1 file changed, 7 insertions(+), 4 deletions(-) + +--- a/net/bluetooth/hci_sock.c ++++ b/net/bluetooth/hci_sock.c +@@ -888,10 +888,6 @@ static int hci_sock_release(struct socke + } + + sock_orphan(sk); +- +- skb_queue_purge(&sk->sk_receive_queue); +- skb_queue_purge(&sk->sk_write_queue); +- + release_sock(sk); + sock_put(sk); + return 0; +@@ -2012,6 +2008,12 @@ done: + return err; + } + ++static void hci_sock_destruct(struct sock *sk) ++{ ++ skb_queue_purge(&sk->sk_receive_queue); ++ skb_queue_purge(&sk->sk_write_queue); ++} ++ + static const struct proto_ops hci_sock_ops = { + .family = PF_BLUETOOTH, + .owner = THIS_MODULE, +@@ -2065,6 +2067,7 @@ static int hci_sock_create(struct net *n + + sock->state = SS_UNCONNECTED; + sk->sk_state = BT_OPEN; ++ sk->sk_destruct = hci_sock_destruct; + + bt_sock_link(&hci_sk_list, sk); + return 0; diff --git a/queue-5.15/media-uvcvideo-fix-race-condition-with-usb_kill_urb.patch b/queue-5.15/media-uvcvideo-fix-race-condition-with-usb_kill_urb.patch new file mode 100644 index 00000000000..95368ea5ae1 --- /dev/null +++ b/queue-5.15/media-uvcvideo-fix-race-condition-with-usb_kill_urb.patch @@ -0,0 +1,140 @@ +From 619d9b710cf06f7a00a17120ca92333684ac45a8 Mon Sep 17 00:00:00 2001 +From: Ricardo Ribalda +Date: Thu, 5 Jan 2023 15:31:29 +0100 +Subject: media: uvcvideo: Fix race condition with usb_kill_urb + +From: Ricardo Ribalda + +commit 619d9b710cf06f7a00a17120ca92333684ac45a8 upstream. + +usb_kill_urb warranties that all the handlers are finished when it +returns, but does not protect against threads that might be handling +asynchronously the urb. + +For UVC, the function uvc_ctrl_status_event_async() takes care of +control changes asynchronously. + +If the code is executed in the following order: + +CPU 0 CPU 1 +===== ===== +uvc_status_complete() + uvc_status_stop() +uvc_ctrl_status_event_work() + uvc_status_start() -> FAIL + +Then uvc_status_start will keep failing and this error will be shown: + +<4>[ 5.540139] URB 0000000000000000 submitted while active +drivers/usb/core/urb.c:378 usb_submit_urb+0x4c3/0x528 + +Let's improve the current situation, by not re-submiting the urb if +we are stopping the status event. Also process the queued work +(if any) during stop. + +CPU 0 CPU 1 +===== ===== +uvc_status_complete() + uvc_status_stop() + uvc_status_start() +uvc_ctrl_status_event_work() -> FAIL + +Hopefully, with the usb layer protection this should be enough to cover +all the cases. + +Cc: stable@vger.kernel.org +Fixes: e5225c820c05 ("media: uvcvideo: Send a control event when a Control Change interrupt arrives") +Reviewed-by: Yunke Cao +Signed-off-by: Ricardo Ribalda +Reviewed-by: Laurent Pinchart +Signed-off-by: Laurent Pinchart +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/usb/uvc/uvc_ctrl.c | 5 +++++ + drivers/media/usb/uvc/uvc_status.c | 37 +++++++++++++++++++++++++++++++++++++ + drivers/media/usb/uvc/uvcvideo.h | 1 + + 3 files changed, 43 insertions(+) + +--- a/drivers/media/usb/uvc/uvc_ctrl.c ++++ b/drivers/media/usb/uvc/uvc_ctrl.c +@@ -6,6 +6,7 @@ + * Laurent Pinchart (laurent.pinchart@ideasonboard.com) + */ + ++#include + #include + #include + #include +@@ -1459,6 +1460,10 @@ static void uvc_ctrl_status_event_work(s + + uvc_ctrl_status_event(w->chain, w->ctrl, w->data); + ++ /* The barrier is needed to synchronize with uvc_status_stop(). */ ++ if (smp_load_acquire(&dev->flush_status)) ++ return; ++ + /* Resubmit the URB. */ + w->urb->interval = dev->int_ep->desc.bInterval; + ret = usb_submit_urb(w->urb, GFP_KERNEL); +--- a/drivers/media/usb/uvc/uvc_status.c ++++ b/drivers/media/usb/uvc/uvc_status.c +@@ -6,6 +6,7 @@ + * Laurent Pinchart (laurent.pinchart@ideasonboard.com) + */ + ++#include + #include + #include + #include +@@ -309,5 +310,41 @@ int uvc_status_start(struct uvc_device * + + void uvc_status_stop(struct uvc_device *dev) + { ++ struct uvc_ctrl_work *w = &dev->async_ctrl; ++ ++ /* ++ * Prevent the asynchronous control handler from requeing the URB. The ++ * barrier is needed so the flush_status change is visible to other ++ * CPUs running the asynchronous handler before usb_kill_urb() is ++ * called below. ++ */ ++ smp_store_release(&dev->flush_status, true); ++ ++ /* ++ * Cancel any pending asynchronous work. If any status event was queued, ++ * process it synchronously. ++ */ ++ if (cancel_work_sync(&w->work)) ++ uvc_ctrl_status_event(w->chain, w->ctrl, w->data); ++ ++ /* Kill the urb. */ + usb_kill_urb(dev->int_urb); ++ ++ /* ++ * The URB completion handler may have queued asynchronous work. This ++ * won't resubmit the URB as flush_status is set, but it needs to be ++ * cancelled before returning or it could then race with a future ++ * uvc_status_start() call. ++ */ ++ if (cancel_work_sync(&w->work)) ++ uvc_ctrl_status_event(w->chain, w->ctrl, w->data); ++ ++ /* ++ * From this point, there are no events on the queue and the status URB ++ * is dead. No events will be queued until uvc_status_start() is called. ++ * The barrier is needed to make sure that flush_status is visible to ++ * uvc_ctrl_status_event_work() when uvc_status_start() will be called ++ * again. ++ */ ++ smp_store_release(&dev->flush_status, false); + } +--- a/drivers/media/usb/uvc/uvcvideo.h ++++ b/drivers/media/usb/uvc/uvcvideo.h +@@ -697,6 +697,7 @@ struct uvc_device { + /* Status Interrupt Endpoint */ + struct usb_host_endpoint *int_ep; + struct urb *int_urb; ++ bool flush_status; + u8 *status; + struct input_dev *input; + char input_phys[64]; diff --git a/queue-5.15/series b/queue-5.15/series index 64210408cc1..b8e2a73eb73 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -125,3 +125,5 @@ net-tls-avoid-hanging-tasks-on-the-tx_lock.patch x86-resctl-fix-scheduler-confusion-with-current.patch drm-display-dp_mst-fix-down-up-message-handling-after-sink-disconnect.patch drm-display-dp_mst-fix-down-message-handling-after-a-packet-reception-error.patch +bluetooth-hci_sock-purge-socket-queues-in-the-destruct-callback.patch +media-uvcvideo-fix-race-condition-with-usb_kill_urb.patch