[openwrt/openwrt] mac80211: CVE-2024-46760: rtw88: schedule rx work after everything is set up
LEDE Commits
lede-commits at lists.infradead.org
Sat Sep 21 04:28:35 PDT 2024
robimarko pushed a commit to openwrt/openwrt.git, branch main:
https://git.openwrt.org/5e769878ad45a8ed019a4d0ad0657e50c0fbdeed
commit 5e769878ad45a8ed019a4d0ad0657e50c0fbdeed
Author: Antonio Flores <antflores627 at gmail.com>
AuthorDate: Wed Sep 18 11:06:12 2024 -0400
mac80211: CVE-2024-46760: rtw88: schedule rx work after everything is set up
link: https://lore.kernel.org/all/2024091842-CVE-2024-46760-1eb3@gregkh
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: usb: schedule rx work after everything is set up
Right now it's possible to hit NULL pointer dereference in
rtw_rx_fill_rx_status on hw object and/or its fields because
initialization routine can start getting USB replies before
rtw_dev is fully setup.
The stack trace looks like this:
rtw_rx_fill_rx_status
rtw8821c_query_rx_desc
rtw_usb_rx_handler
...
queue_work
rtw_usb_read_port_complete
...
usb_submit_urb
rtw_usb_rx_resubmit
rtw_usb_init_rx
rtw_usb_probe
So while we do the async stuff rtw_usb_probe continues and calls
rtw_register_hw, which does all kinds of initialization (e.g.
via ieee80211_register_hw) that rtw_rx_fill_rx_status relies on.
Fix this by moving the first usb_submit_urb after everything
is set up.
For me, this bug manifested as:
[ 8.893177] rtw_8821cu 1-1:1.2: band wrong, packet dropped
[ 8.910904] rtw_8821cu 1-1:1.2: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status
because I'm using Larry's backport of rtw88 driver with the NULL
checks in rtw_rx_fill_rx_status.
The Linux kernel CVE team has assigned CVE-2024-46760 to this issue.
Affected and fixed versions
===========================
Fixed in 6.6.51 with commit c83d464b82a8
Fixed in 6.10.10 with commit 25eaef533bf3
Fixed in 6.11 with commit adc539784c98
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2024-46760
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
drivers/net/wireless/realtek/rtw88/usb.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/c83d464b82a8ad62ec9077637f75d73fe955635a
https://git.kernel.org/stable/c/25eaef533bf3ccc6fee5067aac16f41f280e343e
https://git.kernel.org/stable/c/adc539784c98a7cc602cbf557debfc2e7b9be8b3
Signed-off-by: Antonio Flores <antflores627 at gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16420
Signed-off-by: Robert Marko <robimarko at gmail.com>
---
...usb-schedule-rx-work-after-everything-is-.patch | 98 ++++++++++++++++++++++
1 file changed, 98 insertions(+)
diff --git a/package/kernel/mac80211/patches/rtl/001-v6.10-wifi-rtw88-usb-schedule-rx-work-after-everything-is-.patch b/package/kernel/mac80211/patches/rtl/001-v6.10-wifi-rtw88-usb-schedule-rx-work-after-everything-is-.patch
new file mode 100644
index 0000000000..2fa581f288
--- /dev/null
+++ b/package/kernel/mac80211/patches/rtl/001-v6.10-wifi-rtw88-usb-schedule-rx-work-after-everything-is-.patch
@@ -0,0 +1,98 @@
+From 25eaef533bf3ccc6fee5067aac16f41f280e343e Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Marcin=20=C5=9Alusarz?= <mslusarz at renau.com>
+Date: Tue, 28 May 2024 13:02:46 +0200
+Subject: [PATCH] wifi: rtw88: usb: schedule rx work after everything is set up
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[ Upstream commit adc539784c98a7cc602cbf557debfc2e7b9be8b3 ]
+
+Right now it's possible to hit NULL pointer dereference in
+rtw_rx_fill_rx_status on hw object and/or its fields because
+initialization routine can start getting USB replies before
+rtw_dev is fully setup.
+
+The stack trace looks like this:
+
+rtw_rx_fill_rx_status
+rtw8821c_query_rx_desc
+rtw_usb_rx_handler
+...
+queue_work
+rtw_usb_read_port_complete
+...
+usb_submit_urb
+rtw_usb_rx_resubmit
+rtw_usb_init_rx
+rtw_usb_probe
+
+So while we do the async stuff rtw_usb_probe continues and calls
+rtw_register_hw, which does all kinds of initialization (e.g.
+via ieee80211_register_hw) that rtw_rx_fill_rx_status relies on.
+
+Fix this by moving the first usb_submit_urb after everything
+is set up.
+
+For me, this bug manifested as:
+[ 8.893177] rtw_8821cu 1-1:1.2: band wrong, packet dropped
+[ 8.910904] rtw_8821cu 1-1:1.2: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status
+because I'm using Larry's backport of rtw88 driver with the NULL
+checks in rtw_rx_fill_rx_status.
+
+Link: https://lore.kernel.org/linux-wireless/CA+shoWQ7P49jhQasofDcTdQhiuarPTjYEDa--NiVVx494WcuQw@mail.gmail.com/
+Signed-off-by: Marcin Ślusarz <mslusarz at renau.com>
+Cc: Tim K <tpkuester at gmail.com>
+Cc: Ping-Ke Shih <pkshih at realtek.com>
+Cc: Larry Finger <Larry.Finger at lwfinger.net>
+Cc: Kalle Valo <kvalo at kernel.org>
+Cc: linux-wireless at vger.kernel.org
+Cc: linux-kernel at vger.kernel.org
+Signed-off-by: Ping-Ke Shih <pkshih at realtek.com>
+Link: https://patch.msgid.link/20240528110246.477321-1-marcin.slusarz@gmail.com
+Signed-off-by: Sasha Levin <sashal at kernel.org>
+---
+ drivers/net/wireless/realtek/rtw88/usb.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+--- a/drivers/net/wireless/realtek/rtw88/usb.c
++++ b/drivers/net/wireless/realtek/rtw88/usb.c
+@@ -740,7 +740,6 @@ static struct rtw_hci_ops rtw_usb_ops =
+ static int rtw_usb_init_rx(struct rtw_dev *rtwdev)
+ {
+ struct rtw_usb *rtwusb = rtw_get_usb_priv(rtwdev);
+- int i;
+
+ rtwusb->rxwq = create_singlethread_workqueue("rtw88_usb: rx wq");
+ if (!rtwusb->rxwq) {
+@@ -752,13 +751,19 @@ static int rtw_usb_init_rx(struct rtw_de
+
+ INIT_WORK(&rtwusb->rx_work, rtw_usb_rx_handler);
+
++ return 0;
++}
++
++static void rtw_usb_setup_rx(struct rtw_dev *rtwdev)
++{
++ struct rtw_usb *rtwusb = rtw_get_usb_priv(rtwdev);
++ int i;
++
+ for (i = 0; i < RTW_USB_RXCB_NUM; i++) {
+ struct rx_usb_ctrl_block *rxcb = &rtwusb->rx_cb[i];
+
+ rtw_usb_rx_resubmit(rtwusb, rxcb);
+ }
+-
+- return 0;
+ }
+
+ static void rtw_usb_deinit_rx(struct rtw_dev *rtwdev)
+@@ -895,6 +900,8 @@ int rtw_usb_probe(struct usb_interface *
+ goto err_destroy_rxwq;
+ }
+
++ rtw_usb_setup_rx(rtwdev);
++
+ return 0;
+
+ err_destroy_rxwq:
More information about the lede-commits
mailing list