CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48875 – wifi: mac80211: sdata can be NULL during AMPDU start
https://notcve.org/view.php?id=CVE-2022-48875
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: sdata can be NULL during AMPDU start ieee80211_tx_ba_session_handle_start() may get NULL for sdata when a deauthentication is ongoing. Here a trace triggering the race with the hostapd test multi_ap_fronthaul_on_ap: (gdb) list *drv_ampdu_action+0x46 0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396). 391 int ret = -EOPNOTSUPP; 392 393 might_sleep(); 394 395 sdata = get_bss_sdata(sdata); 396 if (!check_sdata_in_driver(sdata)) 397 return -EIO; 398 399 trace_drv_ampdu_action(local, sdata, params); 400 wlan0: moving STA 02:00:00:00:03:00 to state 3 wlan0: associated wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING) wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0 wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port) wlan0: moving STA 02:00:00:00:03:00 to state 2 wlan0: moving STA 02:00:00:00:03:00 to state 1 wlan0: Removed STA 02:00:00:00:03:00 wlan0: Destroyed STA 02:00:00:00:03:00 BUG: unable to handle page fault for address: fffffffffffffb48 PGD 11814067 P4D 11814067 PUD 11816067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G W 6.1.0-rc8-wt+ #59 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Workqueue: phy3 ieee80211_ba_session_work [mac80211] RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211] Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 <8b> 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85 RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287 RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240 RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40 RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0 R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8 FS: 0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0 Call Trace: <TASK> ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211] ieee80211_ba_session_work+0xff/0x2e0 [mac80211] process_one_work+0x29f/0x620 worker_thread+0x4d/0x3d0 ? process_one_work+0x620/0x620 kthread+0xfb/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> • https://git.kernel.org/stable/c/187523fa7c2d4c780f775cb869216865c4a909ef https://git.kernel.org/stable/c/a12fd43bd175fa52c82f9740179d38c34ca1b62e https://git.kernel.org/stable/c/c838df8461a601b20dc1b9fb1834d2aad8e2f949 https://git.kernel.org/stable/c/69403bad97aa0162e3d7911b27e25abe774093df •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48874 – misc: fastrpc: Fix use-after-free and race in fastrpc_map_find
https://notcve.org/view.php?id=CVE-2022-48874
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix use-after-free and race in fastrpc_map_find Currently, there is a race window between the point when the mutex is unlocked in fastrpc_map_lookup and the reference count increasing (fastrpc_map_get) in fastrpc_map_find, which can also lead to use-after-free. So lets merge fastrpc_map_find into fastrpc_map_lookup which allows us to both protect the maps list by also taking the &fl->lock spinlock and the reference count, since the spinlock will be released only after. Add take_ref argument to make this suitable for all callers. • https://git.kernel.org/stable/c/8f6c1d8c4f0cc316b0456788fff8373554d1d99d https://git.kernel.org/stable/c/a50c5c25b6e7d2824698c0e6385f882a18f4a498 https://git.kernel.org/stable/c/9446fa1683a7e3937d9970248ced427c1983a1c5 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48873 – misc: fastrpc: Don't remove map on creater_process and device_release
https://notcve.org/view.php?id=CVE-2022-48873
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Don't remove map on creater_process and device_release Do not remove the map from the list on error path in fastrpc_init_create_process, instead call fastrpc_map_put, to avoid use-after-free. Do not remove it on fastrpc_device_release either, call fastrpc_map_put instead. The fastrpc_free_map is the only proper place to remove the map. This is called only after the reference count is 0. • https://git.kernel.org/stable/c/b49f6d83e290f17e20f4e5cf31288d3bb4955ea6 https://git.kernel.org/stable/c/aaf5aa44934ad069cac805923c49f6968b9a0d49 https://git.kernel.org/stable/c/4b5c44e924a571d0ad07054de549624fbc04e4d7 https://git.kernel.org/stable/c/193cd853145b63e670bd73740250983af1475330 https://git.kernel.org/stable/c/1b7b7bb400dd13dcb03fc6e591bb7ca4664bbec8 https://git.kernel.org/stable/c/35ddd482345c43d9eec1f3406c0f20a95ed4054b https://git.kernel.org/stable/c/5bb96c8f9268e2fdb0e5321cbc358ee5941efc15 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48872 – misc: fastrpc: Fix use-after-free race condition for maps
https://notcve.org/view.php?id=CVE-2022-48872
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix use-after-free race condition for maps It is possible that in between calling fastrpc_map_get() until map->fl->lock is taken in fastrpc_free_map(), another thread can call fastrpc_map_lookup() and get a reference to a map that is about to be deleted. Rewrite fastrpc_map_get() to only increase the reference count of a map if it's non-zero. Propagate this to callers so they can know if a map is about to be deleted. Fixes this warning: refcount_t: addition on 0; use-after-free. WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate ... Call trace: refcount_warn_saturate [fastrpc_map_get inlined] [fastrpc_map_lookup inlined] fastrpc_map_create fastrpc_internal_invoke fastrpc_device_ioctl __arm64_sys_ioctl invoke_syscall • https://git.kernel.org/stable/c/c68cfb718c8f97b7f7a50ed66be5feb42d0c8988 https://git.kernel.org/stable/c/556dfdb226ce1e5231d8836159b23f8bb0395bf4 https://git.kernel.org/stable/c/b171d0d2cf1b8387c72c8d325c5d5746fa271e39 https://git.kernel.org/stable/c/61a0890cb95afec5c8a2f4a879de2b6220984ef1 https://git.kernel.org/stable/c/079c78c68714f7d8d58e66c477b0243b31806907 https://git.kernel.org/stable/c/96b328d119eca7563c1edcc4e1039a62e6370ecb •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48871 – tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer
https://notcve.org/view.php?id=CVE-2022-48871
In the Linux kernel, the following vulnerability has been resolved: tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer Driver's probe allocates memory for RX FIFO (port->rx_fifo) based on default RX FIFO depth, e.g. 16. Later during serial startup the qcom_geni_serial_port_setup() updates the RX FIFO depth (port->rx_fifo_depth) to match real device capabilities, e.g. to 32. The RX UART handle code will read "port->rx_fifo_depth" number of words into "port->rx_fifo" buffer, thus exceeding the bounds. This can be observed in certain configurations with Qualcomm Bluetooth HCI UART device and KASAN: Bluetooth: hci0: QCA Product ID :0x00000010 Bluetooth: hci0: QCA SOC Version :0x400a0200 Bluetooth: hci0: QCA ROM Version :0x00000200 Bluetooth: hci0: QCA Patch Version:0x00000d2b Bluetooth: hci0: QCA controller version 0x02000200 Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2 Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2) Bluetooth: hci0: QCA Failed to download patch (-2) ================================================================== BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c Write of size 4 at addr ffff279347d578c0 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x8c/0xb8 print_report+0x188/0x488 kasan_report+0xb4/0x100 __asan_store4+0x80/0xa4 handle_rx_uart+0xa8/0x18c qcom_geni_serial_handle_rx+0x84/0x9c qcom_geni_serial_isr+0x24c/0x760 __handle_irq_event_percpu+0x108/0x500 handle_irq_event+0x6c/0x110 handle_fasteoi_irq+0x138/0x2cc generic_handle_domain_irq+0x48/0x64 If the RX FIFO depth changes after probe, be sure to resize the buffer. • https://git.kernel.org/stable/c/f9d690b6ece7ec9a6ff6b588df95a010ab2d66f9 https://git.kernel.org/stable/c/894681682dbefdad917b88f86cde1069140a047a https://git.kernel.org/stable/c/cb53a3366eb28fed67850c80afa52075bb71a38a https://git.kernel.org/stable/c/fd524ca7fe45b8a06dca2dd546d62684a9768f95 https://git.kernel.org/stable/c/b8caf69a6946e18ffebad49847e258f5b6d52ac2 •