From: Greg Kroah-Hartman Date: Thu, 27 Apr 2023 10:16:04 +0000 (+0200) Subject: 6.3-stable patches X-Git-Tag: v5.15.110~12 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=7a1d3dfaa0c4a9be9436647f4abec0081d694357;p=thirdparty%2Fkernel%2Fstable-queue.git 6.3-stable patches added patches: bluetooth-perform-careful-capability-checks-in-hci_sock_ioctl.patch drm-fb-helper-set-x-yres_virtual-in-drm_fb_helper_check_var.patch fsverity-explicitly-check-for-buffer-overflow-in-build_merkle_tree.patch fsverity-reject-fs_ioc_enable_verity-on-mode-3-fds.patch gpiolib-acpi-add-a-ignore-wakeup-quirk-for-clevo-nl5xnu.patch series wifi-brcmfmac-add-cypress-43439-sdio-ids.patch wifi-brcmfmac-slab-out-of-bounds-read-in-brcmf_get_assoc_ies.patch --- diff --git a/queue-6.3/bluetooth-perform-careful-capability-checks-in-hci_sock_ioctl.patch b/queue-6.3/bluetooth-perform-careful-capability-checks-in-hci_sock_ioctl.patch new file mode 100644 index 00000000000..486e10ad0c2 --- /dev/null +++ b/queue-6.3/bluetooth-perform-careful-capability-checks-in-hci_sock_ioctl.patch @@ -0,0 +1,50 @@ +From 25c150ac103a4ebeed0319994c742a90634ddf18 Mon Sep 17 00:00:00 2001 +From: Ruihan Li +Date: Sun, 16 Apr 2023 16:14:04 +0800 +Subject: bluetooth: Perform careful capability checks in hci_sock_ioctl() + +From: Ruihan Li + +commit 25c150ac103a4ebeed0319994c742a90634ddf18 upstream. + +Previously, capability was checked using capable(), which verified that the +caller of the ioctl system call had the required capability. In addition, +the result of the check would be stored in the HCI_SOCK_TRUSTED flag, +making it persistent for the socket. + +However, malicious programs can abuse this approach by deliberately sharing +an HCI socket with a privileged task. The HCI socket will be marked as +trusted when the privileged task occasionally makes an ioctl call. + +This problem can be solved by using sk_capable() to check capability, which +ensures that not only the current task but also the socket opener has the +specified capability, thus reducing the risk of privilege escalation +through the previously identified vulnerability. + +Cc: stable@vger.kernel.org +Fixes: f81f5b2db869 ("Bluetooth: Send control open and close messages for HCI raw sockets") +Signed-off-by: Ruihan Li +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Greg Kroah-Hartman +--- + net/bluetooth/hci_sock.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/net/bluetooth/hci_sock.c ++++ b/net/bluetooth/hci_sock.c +@@ -1003,7 +1003,14 @@ static int hci_sock_ioctl(struct socket + if (hci_sock_gen_cookie(sk)) { + struct sk_buff *skb; + +- if (capable(CAP_NET_ADMIN)) ++ /* Perform careful checks before setting the HCI_SOCK_TRUSTED ++ * flag. Make sure that not only the current task but also ++ * the socket opener has the required capability, since ++ * privileged programs can be tricked into making ioctl calls ++ * on HCI sockets, and the socket should not be marked as ++ * trusted simply because the ioctl caller is privileged. ++ */ ++ if (sk_capable(sk, CAP_NET_ADMIN)) + hci_sock_set_flag(sk, HCI_SOCK_TRUSTED); + + /* Send event to monitor */ diff --git a/queue-6.3/drm-fb-helper-set-x-yres_virtual-in-drm_fb_helper_check_var.patch b/queue-6.3/drm-fb-helper-set-x-yres_virtual-in-drm_fb_helper_check_var.patch new file mode 100644 index 00000000000..962ee0bfe08 --- /dev/null +++ b/queue-6.3/drm-fb-helper-set-x-yres_virtual-in-drm_fb_helper_check_var.patch @@ -0,0 +1,39 @@ +From 1935f0deb6116dd785ea64d8035eab0ff441255b Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Tue, 4 Apr 2023 21:40:36 +0200 +Subject: drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var + +From: Daniel Vetter + +commit 1935f0deb6116dd785ea64d8035eab0ff441255b upstream. + +Drivers are supposed to fix this up if needed if they don't outright +reject it. Uncovered by 6c11df58fd1a ("fbmem: Check virtual screen +sizes in fb_set_var()"). + +Reported-by: syzbot+20dcf81733d43ddff661@syzkaller.appspotmail.com +Link: https://syzkaller.appspot.com/bug?id=c5faf983bfa4a607de530cd3bb008888bf06cefc +Cc: stable@vger.kernel.org # v5.4+ +Cc: Daniel Vetter +Cc: Javier Martinez Canillas +Cc: Thomas Zimmermann +Reviewed-by: Javier Martinez Canillas +Signed-off-by: Daniel Vetter +Link: https://patchwork.freedesktop.org/patch/msgid/20230404194038.472803-1-daniel.vetter@ffwll.ch +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/drm_fb_helper.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/gpu/drm/drm_fb_helper.c ++++ b/drivers/gpu/drm/drm_fb_helper.c +@@ -1569,6 +1569,9 @@ int drm_fb_helper_check_var(struct fb_va + return -EINVAL; + } + ++ var->xres_virtual = fb->width; ++ var->yres_virtual = fb->height; ++ + /* + * Workaround for SDL 1.2, which is known to be setting all pixel format + * fields values to zero in some cases. We treat this situation as a diff --git a/queue-6.3/fsverity-explicitly-check-for-buffer-overflow-in-build_merkle_tree.patch b/queue-6.3/fsverity-explicitly-check-for-buffer-overflow-in-build_merkle_tree.patch new file mode 100644 index 00000000000..714afa1e183 --- /dev/null +++ b/queue-6.3/fsverity-explicitly-check-for-buffer-overflow-in-build_merkle_tree.patch @@ -0,0 +1,64 @@ +From 39049b69ec9fc125fa1f314165dcc86f72cb72ec Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Mon, 27 Mar 2023 21:15:05 -0700 +Subject: fsverity: explicitly check for buffer overflow in build_merkle_tree() + +From: Eric Biggers + +commit 39049b69ec9fc125fa1f314165dcc86f72cb72ec upstream. + +The new Merkle tree construction algorithm is a bit fragile in that it +may overflow the 'root_hash' array if the tree actually generated does +not match the calculated tree parameters. + +This should never happen unless there is a filesystem bug that allows +the file size to change despite deny_write_access(), or a bug in the +Merkle tree logic itself. Regardless, it's fairly easy to check for +buffer overflow here, so let's do so. + +This is a robustness improvement only; this case is not currently known +to be reachable. I've added a Fixes tag anyway, since I recommend that +this be included in kernels that have the mentioned commit. + +Fixes: 56124d6c87fd ("fsverity: support enabling with tree block size < PAGE_SIZE") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230328041505.110162-1-ebiggers@kernel.org +Signed-off-by: Eric Biggers +Signed-off-by: Greg Kroah-Hartman +--- + fs/verity/enable.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/fs/verity/enable.c ++++ b/fs/verity/enable.c +@@ -13,6 +13,7 @@ + + struct block_buffer { + u32 filled; ++ bool is_root_hash; + u8 *data; + }; + +@@ -24,6 +25,14 @@ static int hash_one_block(struct inode * + struct block_buffer *next = cur + 1; + int err; + ++ /* ++ * Safety check to prevent a buffer overflow in case of a filesystem bug ++ * that allows the file size to change despite deny_write_access(), or a ++ * bug in the Merkle tree logic itself ++ */ ++ if (WARN_ON_ONCE(next->is_root_hash && next->filled != 0)) ++ return -EINVAL; ++ + /* Zero-pad the block if it's shorter than the block size. */ + memset(&cur->data[cur->filled], 0, params->block_size - cur->filled); + +@@ -97,6 +106,7 @@ static int build_merkle_tree(struct file + } + } + buffers[num_levels].data = root_hash; ++ buffers[num_levels].is_root_hash = true; + + BUILD_BUG_ON(sizeof(level_offset) != sizeof(params->level_start)); + memcpy(level_offset, params->level_start, sizeof(level_offset)); diff --git a/queue-6.3/fsverity-reject-fs_ioc_enable_verity-on-mode-3-fds.patch b/queue-6.3/fsverity-reject-fs_ioc_enable_verity-on-mode-3-fds.patch new file mode 100644 index 00000000000..3a383e4d581 --- /dev/null +++ b/queue-6.3/fsverity-reject-fs_ioc_enable_verity-on-mode-3-fds.patch @@ -0,0 +1,54 @@ +From 04839139213cf60d4c5fc792214a08830e294ff8 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Thu, 6 Apr 2023 14:31:11 -0700 +Subject: fsverity: reject FS_IOC_ENABLE_VERITY on mode 3 fds + +From: Eric Biggers + +commit 04839139213cf60d4c5fc792214a08830e294ff8 upstream. + +Commit 56124d6c87fd ("fsverity: support enabling with tree block size < +PAGE_SIZE") changed FS_IOC_ENABLE_VERITY to use __kernel_read() to read +the file's data, instead of direct pagecache accesses. + +An unintended consequence of this is that the +'WARN_ON_ONCE(!(file->f_mode & FMODE_READ))' in __kernel_read() became +reachable by fuzz tests. This happens if FS_IOC_ENABLE_VERITY is called +on a fd opened with access mode 3, which means "ioctl access only". + +Arguably, FS_IOC_ENABLE_VERITY should work on ioctl-only fds. But +ioctl-only fds are a weird Linux extension that is rarely used and that +few people even know about. (The documentation for FS_IOC_ENABLE_VERITY +even specifically says it requires O_RDONLY.) It's probably not +worthwhile to make the ioctl internally open a new fd just to handle +this case. Thus, just reject the ioctl on such fds for now. + +Fixes: 56124d6c87fd ("fsverity: support enabling with tree block size < PAGE_SIZE") +Reported-by: syzbot+51177e4144d764827c45@syzkaller.appspotmail.com +Link: https://syzkaller.appspot.com/bug?id=2281afcbbfa8fdb92f9887479cc0e4180f1c6b28 +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230406215106.235829-1-ebiggers@kernel.org +Reviewed-by: Christoph Hellwig +Reviewed-by: Christian Brauner +Signed-off-by: Eric Biggers +Signed-off-by: Greg Kroah-Hartman +--- + fs/verity/enable.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/fs/verity/enable.c ++++ b/fs/verity/enable.c +@@ -347,6 +347,13 @@ int fsverity_ioctl_enable(struct file *f + err = file_permission(filp, MAY_WRITE); + if (err) + return err; ++ /* ++ * __kernel_read() is used while building the Merkle tree. So, we can't ++ * allow file descriptors that were opened for ioctl access only, using ++ * the special nonstandard access mode 3. O_RDONLY only, please! ++ */ ++ if (!(filp->f_mode & FMODE_READ)) ++ return -EBADF; + + if (IS_APPEND(inode)) + return -EPERM; diff --git a/queue-6.3/gpiolib-acpi-add-a-ignore-wakeup-quirk-for-clevo-nl5xnu.patch b/queue-6.3/gpiolib-acpi-add-a-ignore-wakeup-quirk-for-clevo-nl5xnu.patch new file mode 100644 index 00000000000..584dd479d1d --- /dev/null +++ b/queue-6.3/gpiolib-acpi-add-a-ignore-wakeup-quirk-for-clevo-nl5xnu.patch @@ -0,0 +1,54 @@ +From 782eea0c89f7d071d6b56ecfa1b8b0c81164b9be Mon Sep 17 00:00:00 2001 +From: Werner Sembach +Date: Wed, 22 Mar 2023 13:15:47 +0100 +Subject: gpiolib: acpi: Add a ignore wakeup quirk for Clevo NL5xNU + +From: Werner Sembach + +commit 782eea0c89f7d071d6b56ecfa1b8b0c81164b9be upstream. + +commit 1796f808e4bb ("HID: i2c-hid: acpi: Stop setting wakeup_capable") +changed the policy such that I2C touchpads may be able to wake up the +system by default if the system is configured as such. + +However on Clevo NL5xNU there is a mistake in the ACPI tables that the +TP_ATTN# signal connected to GPIO 9 is configured as ActiveLow and level +triggered but connected to a pull up. As soon as the system suspends the +touchpad loses power and then the system wakes up. + +To avoid this problem, introduce a quirk for this model that will prevent +the wakeup capability for being set for GPIO 9. + +This patch is analoge to a very similar patch for NL5xRU, just the DMI +string changed. + +Signed-off-by: Werner Sembach +Cc: stable@vger.kernel.org +Signed-off-by: Andy Shevchenko +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpio/gpiolib-acpi.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + +--- a/drivers/gpio/gpiolib-acpi.c ++++ b/drivers/gpio/gpiolib-acpi.c +@@ -1624,6 +1624,19 @@ static const struct dmi_system_id gpioli + * https://gitlab.freedesktop.org/drm/amd/-/issues/1722#note_1720627 + */ + .matches = { ++ DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"), ++ }, ++ .driver_data = &(struct acpi_gpiolib_dmi_quirk) { ++ .ignore_wake = "ELAN0415:00@9", ++ }, ++ }, ++ { ++ /* ++ * Spurious wakeups from TP_ATTN# pin ++ * Found in BIOS 1.7.8 ++ * https://gitlab.freedesktop.org/drm/amd/-/issues/1722#note_1720627 ++ */ ++ .matches = { + DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"), + }, + .driver_data = &(struct acpi_gpiolib_dmi_quirk) { diff --git a/queue-6.3/series b/queue-6.3/series new file mode 100644 index 00000000000..3903e61a96e --- /dev/null +++ b/queue-6.3/series @@ -0,0 +1,7 @@ +wifi-brcmfmac-slab-out-of-bounds-read-in-brcmf_get_assoc_ies.patch +fsverity-reject-fs_ioc_enable_verity-on-mode-3-fds.patch +drm-fb-helper-set-x-yres_virtual-in-drm_fb_helper_check_var.patch +fsverity-explicitly-check-for-buffer-overflow-in-build_merkle_tree.patch +gpiolib-acpi-add-a-ignore-wakeup-quirk-for-clevo-nl5xnu.patch +bluetooth-perform-careful-capability-checks-in-hci_sock_ioctl.patch +wifi-brcmfmac-add-cypress-43439-sdio-ids.patch diff --git a/queue-6.3/wifi-brcmfmac-add-cypress-43439-sdio-ids.patch b/queue-6.3/wifi-brcmfmac-add-cypress-43439-sdio-ids.patch new file mode 100644 index 00000000000..397817ccf7e --- /dev/null +++ b/queue-6.3/wifi-brcmfmac-add-cypress-43439-sdio-ids.patch @@ -0,0 +1,93 @@ +From cc4cffc3c142d57df48c07851862444e1d33bdaa Mon Sep 17 00:00:00 2001 +From: Marek Vasut +Date: Fri, 7 Apr 2023 22:37:52 +0200 +Subject: wifi: brcmfmac: add Cypress 43439 SDIO ids + +From: Marek Vasut + +commit cc4cffc3c142d57df48c07851862444e1d33bdaa upstream. + +Add SDIO ids for use with the muRata 1YN (Cypress CYW43439). +The odd thing about this is that the previous 1YN populated +on M.2 card for evaluation purposes had BRCM SDIO vendor ID, +while the chip populated on real hardware has a Cypress one. +The device ID also differs between the two devices. But they +are both 43439 otherwise, so add the IDs for both. + +On-device 1YN (43439), the new one, chip label reads "1YN": +``` +/sys/.../mmc_host/mmc2/mmc2:0001 # cat vendor device +0x04b4 +0xbd3d +``` + +EA M.2 evaluation board 1YN (43439), the old one, chip label reads "1YN ES1.4": +``` +/sys/.../mmc_host/mmc0/mmc0:0001/# cat vendor device +0x02d0 +0xa9a6 +``` + +Reviewed-by: Hans de Goede +Cc: stable@vger.kernel.org +Signed-off-by: Marek Vasut +Reviewed-by: Simon Horman +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20230407203752.128539-1-marex@denx.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 9 ++++++++- + include/linux/mmc/sdio_ids.h | 5 ++++- + 2 files changed, 12 insertions(+), 2 deletions(-) + +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c +@@ -965,6 +965,12 @@ out: + .driver_data = BRCMF_FWVENDOR_ ## fw_vend \ + } + ++#define CYW_SDIO_DEVICE(dev_id, fw_vend) \ ++ { \ ++ SDIO_DEVICE(SDIO_VENDOR_ID_CYPRESS, dev_id), \ ++ .driver_data = BRCMF_FWVENDOR_ ## fw_vend \ ++ } ++ + /* devices we support, null terminated */ + static const struct sdio_device_id brcmf_sdmmc_ids[] = { + BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43143, WCC), +@@ -979,6 +985,7 @@ static const struct sdio_device_id brcmf + BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4335_4339, WCC), + BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4339, WCC), + BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43430, WCC), ++ BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43439, WCC), + BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4345, WCC), + BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43455, WCC), + BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4354, WCC), +@@ -986,9 +993,9 @@ static const struct sdio_device_id brcmf + BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4359, WCC), + BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_CYPRESS_4373, CYW), + BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_CYPRESS_43012, CYW), +- BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_CYPRESS_43439, CYW), + BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752, CYW), + BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_CYPRESS_89359, CYW), ++ CYW_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_CYPRESS_43439, CYW), + { /* end: all zeroes */ } + }; + MODULE_DEVICE_TABLE(sdio, brcmf_sdmmc_ids); +--- a/include/linux/mmc/sdio_ids.h ++++ b/include/linux/mmc/sdio_ids.h +@@ -74,10 +74,13 @@ + #define SDIO_DEVICE_ID_BROADCOM_43362 0xa962 + #define SDIO_DEVICE_ID_BROADCOM_43364 0xa9a4 + #define SDIO_DEVICE_ID_BROADCOM_43430 0xa9a6 +-#define SDIO_DEVICE_ID_BROADCOM_CYPRESS_43439 0xa9af ++#define SDIO_DEVICE_ID_BROADCOM_43439 0xa9af + #define SDIO_DEVICE_ID_BROADCOM_43455 0xa9bf + #define SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752 0xaae8 + ++#define SDIO_VENDOR_ID_CYPRESS 0x04b4 ++#define SDIO_DEVICE_ID_BROADCOM_CYPRESS_43439 0xbd3d ++ + #define SDIO_VENDOR_ID_MARVELL 0x02df + #define SDIO_DEVICE_ID_MARVELL_LIBERTAS 0x9103 + #define SDIO_DEVICE_ID_MARVELL_8688_WLAN 0x9104 diff --git a/queue-6.3/wifi-brcmfmac-slab-out-of-bounds-read-in-brcmf_get_assoc_ies.patch b/queue-6.3/wifi-brcmfmac-slab-out-of-bounds-read-in-brcmf_get_assoc_ies.patch new file mode 100644 index 00000000000..9eabbc8f224 --- /dev/null +++ b/queue-6.3/wifi-brcmfmac-slab-out-of-bounds-read-in-brcmf_get_assoc_ies.patch @@ -0,0 +1,168 @@ +From 0da40e018fd034d87c9460123fa7f897b69fdee7 Mon Sep 17 00:00:00 2001 +From: Jisoo Jang +Date: Thu, 9 Mar 2023 19:44:57 +0900 +Subject: wifi: brcmfmac: slab-out-of-bounds read in brcmf_get_assoc_ies() + +From: Jisoo Jang + +commit 0da40e018fd034d87c9460123fa7f897b69fdee7 upstream. + +Fix a slab-out-of-bounds read that occurs in kmemdup() called from +brcmf_get_assoc_ies(). +The bug could occur when assoc_info->req_len, data from a URB provided +by a USB device, is bigger than the size of buffer which is defined as +WL_EXTRA_BUF_MAX. + +Add the size check for req_len/resp_len of assoc_info. + +Found by a modified version of syzkaller. + +[ 46.592467][ T7] ================================================================== +[ 46.594687][ T7] BUG: KASAN: slab-out-of-bounds in kmemdup+0x3e/0x50 +[ 46.596572][ T7] Read of size 3014656 at addr ffff888019442000 by task kworker/0:1/7 +[ 46.598575][ T7] +[ 46.599157][ T7] CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G O 5.14.0+ #145 +[ 46.601333][ T7] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 +[ 46.604360][ T7] Workqueue: events brcmf_fweh_event_worker +[ 46.605943][ T7] Call Trace: +[ 46.606584][ T7] dump_stack_lvl+0x8e/0xd1 +[ 46.607446][ T7] print_address_description.constprop.0.cold+0x93/0x334 +[ 46.608610][ T7] ? kmemdup+0x3e/0x50 +[ 46.609341][ T7] kasan_report.cold+0x79/0xd5 +[ 46.610151][ T7] ? kmemdup+0x3e/0x50 +[ 46.610796][ T7] kasan_check_range+0x14e/0x1b0 +[ 46.611691][ T7] memcpy+0x20/0x60 +[ 46.612323][ T7] kmemdup+0x3e/0x50 +[ 46.612987][ T7] brcmf_get_assoc_ies+0x967/0xf60 +[ 46.613904][ T7] ? brcmf_notify_vif_event+0x3d0/0x3d0 +[ 46.614831][ T7] ? lock_chain_count+0x20/0x20 +[ 46.615683][ T7] ? mark_lock.part.0+0xfc/0x2770 +[ 46.616552][ T7] ? lock_chain_count+0x20/0x20 +[ 46.617409][ T7] ? mark_lock.part.0+0xfc/0x2770 +[ 46.618244][ T7] ? lock_chain_count+0x20/0x20 +[ 46.619024][ T7] brcmf_bss_connect_done.constprop.0+0x241/0x2e0 +[ 46.620019][ T7] ? brcmf_parse_configure_security.isra.0+0x2a0/0x2a0 +[ 46.620818][ T7] ? __lock_acquire+0x181f/0x5790 +[ 46.621462][ T7] brcmf_notify_connect_status+0x448/0x1950 +[ 46.622134][ T7] ? rcu_read_lock_bh_held+0xb0/0xb0 +[ 46.622736][ T7] ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0 +[ 46.623390][ T7] ? find_held_lock+0x2d/0x110 +[ 46.623962][ T7] ? brcmf_fweh_event_worker+0x19f/0xc60 +[ 46.624603][ T7] ? mark_held_locks+0x9f/0xe0 +[ 46.625145][ T7] ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0 +[ 46.625871][ T7] ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0 +[ 46.626545][ T7] brcmf_fweh_call_event_handler.isra.0+0x90/0x100 +[ 46.627338][ T7] brcmf_fweh_event_worker+0x557/0xc60 +[ 46.627962][ T7] ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100 +[ 46.628736][ T7] ? rcu_read_lock_sched_held+0xa1/0xd0 +[ 46.629396][ T7] ? rcu_read_lock_bh_held+0xb0/0xb0 +[ 46.629970][ T7] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 +[ 46.630649][ T7] process_one_work+0x92b/0x1460 +[ 46.631205][ T7] ? pwq_dec_nr_in_flight+0x330/0x330 +[ 46.631821][ T7] ? rwlock_bug.part.0+0x90/0x90 +[ 46.632347][ T7] worker_thread+0x95/0xe00 +[ 46.632832][ T7] ? __kthread_parkme+0x115/0x1e0 +[ 46.633393][ T7] ? process_one_work+0x1460/0x1460 +[ 46.633957][ T7] kthread+0x3a1/0x480 +[ 46.634369][ T7] ? set_kthread_struct+0x120/0x120 +[ 46.634933][ T7] ret_from_fork+0x1f/0x30 +[ 46.635431][ T7] +[ 46.635687][ T7] Allocated by task 7: +[ 46.636151][ T7] kasan_save_stack+0x1b/0x40 +[ 46.636628][ T7] __kasan_kmalloc+0x7c/0x90 +[ 46.637108][ T7] kmem_cache_alloc_trace+0x19e/0x330 +[ 46.637696][ T7] brcmf_cfg80211_attach+0x4a0/0x4040 +[ 46.638275][ T7] brcmf_attach+0x389/0xd40 +[ 46.638739][ T7] brcmf_usb_probe+0x12de/0x1690 +[ 46.639279][ T7] usb_probe_interface+0x2aa/0x760 +[ 46.639820][ T7] really_probe+0x205/0xb70 +[ 46.640342][ T7] __driver_probe_device+0x311/0x4b0 +[ 46.640876][ T7] driver_probe_device+0x4e/0x150 +[ 46.641445][ T7] __device_attach_driver+0x1cc/0x2a0 +[ 46.642000][ T7] bus_for_each_drv+0x156/0x1d0 +[ 46.642543][ T7] __device_attach+0x23f/0x3a0 +[ 46.643065][ T7] bus_probe_device+0x1da/0x290 +[ 46.643644][ T7] device_add+0xb7b/0x1eb0 +[ 46.644130][ T7] usb_set_configuration+0xf59/0x16f0 +[ 46.644720][ T7] usb_generic_driver_probe+0x82/0xa0 +[ 46.645295][ T7] usb_probe_device+0xbb/0x250 +[ 46.645786][ T7] really_probe+0x205/0xb70 +[ 46.646258][ T7] __driver_probe_device+0x311/0x4b0 +[ 46.646804][ T7] driver_probe_device+0x4e/0x150 +[ 46.647387][ T7] __device_attach_driver+0x1cc/0x2a0 +[ 46.647926][ T7] bus_for_each_drv+0x156/0x1d0 +[ 46.648454][ T7] __device_attach+0x23f/0x3a0 +[ 46.648939][ T7] bus_probe_device+0x1da/0x290 +[ 46.649478][ T7] device_add+0xb7b/0x1eb0 +[ 46.649936][ T7] usb_new_device.cold+0x49c/0x1029 +[ 46.650526][ T7] hub_event+0x1c98/0x3950 +[ 46.650975][ T7] process_one_work+0x92b/0x1460 +[ 46.651535][ T7] worker_thread+0x95/0xe00 +[ 46.651991][ T7] kthread+0x3a1/0x480 +[ 46.652413][ T7] ret_from_fork+0x1f/0x30 +[ 46.652885][ T7] +[ 46.653131][ T7] The buggy address belongs to the object at ffff888019442000 +[ 46.653131][ T7] which belongs to the cache kmalloc-2k of size 2048 +[ 46.654669][ T7] The buggy address is located 0 bytes inside of +[ 46.654669][ T7] 2048-byte region [ffff888019442000, ffff888019442800) +[ 46.656137][ T7] The buggy address belongs to the page: +[ 46.656720][ T7] page:ffffea0000651000 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x19440 +[ 46.657792][ T7] head:ffffea0000651000 order:3 compound_mapcount:0 compound_pincount:0 +[ 46.658673][ T7] flags: 0x100000000010200(slab|head|node=0|zone=1) +[ 46.659422][ T7] raw: 0100000000010200 0000000000000000 dead000000000122 ffff888100042000 +[ 46.660363][ T7] raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000 +[ 46.661236][ T7] page dumped because: kasan: bad access detected +[ 46.661956][ T7] page_owner tracks the page as allocated +[ 46.662588][ T7] page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52a20(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 7, ts 31136961085, free_ts 0 +[ 46.664271][ T7] prep_new_page+0x1aa/0x240 +[ 46.664763][ T7] get_page_from_freelist+0x159a/0x27c0 +[ 46.665340][ T7] __alloc_pages+0x2da/0x6a0 +[ 46.665847][ T7] alloc_pages+0xec/0x1e0 +[ 46.666308][ T7] allocate_slab+0x380/0x4e0 +[ 46.666770][ T7] ___slab_alloc+0x5bc/0x940 +[ 46.667264][ T7] __slab_alloc+0x6d/0x80 +[ 46.667712][ T7] kmem_cache_alloc_trace+0x30a/0x330 +[ 46.668299][ T7] brcmf_usbdev_qinit.constprop.0+0x50/0x470 +[ 46.668885][ T7] brcmf_usb_probe+0xc97/0x1690 +[ 46.669438][ T7] usb_probe_interface+0x2aa/0x760 +[ 46.669988][ T7] really_probe+0x205/0xb70 +[ 46.670487][ T7] __driver_probe_device+0x311/0x4b0 +[ 46.671031][ T7] driver_probe_device+0x4e/0x150 +[ 46.671604][ T7] __device_attach_driver+0x1cc/0x2a0 +[ 46.672192][ T7] bus_for_each_drv+0x156/0x1d0 +[ 46.672739][ T7] page_owner free stack trace missing +[ 46.673335][ T7] +[ 46.673620][ T7] Memory state around the buggy address: +[ 46.674213][ T7] ffff888019442700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +[ 46.675083][ T7] ffff888019442780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +[ 46.675994][ T7] >ffff888019442800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc +[ 46.676875][ T7] ^ +[ 46.677323][ T7] ffff888019442880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc +[ 46.678190][ T7] ffff888019442900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc +[ 46.679052][ T7] ================================================================== +[ 46.679945][ T7] Disabling lock debugging due to kernel taint +[ 46.680725][ T7] Kernel panic - not syncing: + +Reviewed-by: Arend van Spriel +Signed-off-by: Jisoo Jang +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20230309104457.22628-1-jisoo.jang@yonsei.ac.kr +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +@@ -6164,6 +6164,11 @@ static s32 brcmf_get_assoc_ies(struct br + (struct brcmf_cfg80211_assoc_ielen_le *)cfg->extra_buf; + req_len = le32_to_cpu(assoc_info->req_len); + resp_len = le32_to_cpu(assoc_info->resp_len); ++ if (req_len > WL_EXTRA_BUF_MAX || resp_len > WL_EXTRA_BUF_MAX) { ++ bphy_err(drvr, "invalid lengths in assoc info: req %u resp %u\n", ++ req_len, resp_len); ++ return -EINVAL; ++ } + if (req_len) { + err = brcmf_fil_iovar_data_get(ifp, "assoc_req_ies", + cfg->extra_buf,