Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: Fix use-after-free race condition for maps<br /> <br /> It is possible that in between calling fastrpc_map_get() until<br /> map-&gt;fl-&gt;lock is taken in fastrpc_free_map(), another thread can call<br /> fastrpc_map_lookup() and get a reference to a map that is about to be<br /> deleted.<br /> <br /> Rewrite fastrpc_map_get() to only increase the reference count of a map<br /> if it&amp;#39;s non-zero. Propagate this to callers so they can know if a map is<br /> about to be deleted.<br /> <br /> Fixes this warning:<br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate<br /> ...<br /> Call trace:<br /> refcount_warn_saturate<br /> [fastrpc_map_get inlined]<br /> [fastrpc_map_lookup inlined]<br /> fastrpc_map_create<br /> fastrpc_internal_invoke<br /> fastrpc_device_ioctl<br /> __arm64_sys_ioctl<br /> invoke_syscall

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: Don&amp;#39;t remove map on creater_process and device_release<br /> <br /> Do not remove the map from the list on error path in<br /> fastrpc_init_create_process, instead call fastrpc_map_put, to avoid<br /> use-after-free. Do not remove it on fastrpc_device_release either,<br /> call fastrpc_map_put instead.<br /> <br /> The fastrpc_free_map is the only proper place to remove the map.<br /> This is called only after the reference count is 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: Fix use-after-free and race in fastrpc_map_find<br /> <br /> Currently, there is a race window between the point when the mutex is<br /> unlocked in fastrpc_map_lookup and the reference count increasing<br /> (fastrpc_map_get) in fastrpc_map_find, which can also lead to<br /> use-after-free.<br /> <br /> So lets merge fastrpc_map_find into fastrpc_map_lookup which allows us<br /> to both protect the maps list by also taking the &amp;fl-&gt;lock spinlock and<br /> the reference count, since the spinlock will be released only after.<br /> Add take_ref argument to make this suitable for all callers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: sdata can be NULL during AMPDU start<br /> <br /> ieee80211_tx_ba_session_handle_start() may get NULL for sdata when a<br /> deauthentication is ongoing.<br /> <br /> Here a trace triggering the race with the hostapd test<br /> multi_ap_fronthaul_on_ap:<br /> <br /> (gdb) list *drv_ampdu_action+0x46<br /> 0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396).<br /> 391 int ret = -EOPNOTSUPP;<br /> 392<br /> 393 might_sleep();<br /> 394<br /> 395 sdata = get_bss_sdata(sdata);<br /> 396 if (!check_sdata_in_driver(sdata))<br /> 397 return -EIO;<br /> 398<br /> 399 trace_drv_ampdu_action(local, sdata, params);<br /> 400<br /> <br /> wlan0: moving STA 02:00:00:00:03:00 to state 3<br /> wlan0: associated<br /> wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING)<br /> wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0<br /> wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port)<br /> wlan0: moving STA 02:00:00:00:03:00 to state 2<br /> wlan0: moving STA 02:00:00:00:03:00 to state 1<br /> wlan0: Removed STA 02:00:00:00:03:00<br /> wlan0: Destroyed STA 02:00:00:00:03:00<br /> BUG: unable to handle page fault for address: fffffffffffffb48<br /> PGD 11814067 P4D 11814067 PUD 11816067 PMD 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G W 6.1.0-rc8-wt+ #59<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014<br /> Workqueue: phy3 ieee80211_ba_session_work [mac80211]<br /> RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211]<br /> 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 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85<br /> RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287<br /> RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240<br /> RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40<br /> RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001<br /> R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0<br /> R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8<br /> FS: 0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0<br /> Call Trace:<br /> <br /> ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211]<br /> ieee80211_ba_session_work+0xff/0x2e0 [mac80211]<br /> process_one_work+0x29f/0x620<br /> worker_thread+0x4d/0x3d0<br /> ? process_one_work+0x620/0x620<br /> kthread+0xfb/0x120<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix initialization of rx-&gt;link and rx-&gt;link_sta<br /> <br /> There are some codepaths that do not initialize rx-&gt;link_sta properly. This<br /> causes a crash in places which assume that rx-&gt;link_sta is valid if rx-&gt;sta<br /> is valid.<br /> One known instance is triggered by __ieee80211_rx_h_amsdu being called from<br /> fast-rx. It results in a crash like this one:<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000000a8<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page PGD 0 P4D 0<br /> Oops: 0002 [#1] PREEMPT SMP PTI<br /> CPU: 1 PID: 506 Comm: mt76-usb-rx phy Tainted: G E 6.1.0-debian64x+1.7 #3<br /> Hardware name: ZOTAC ZBOX-ID92/ZBOX-IQ01/ZBOX-ID92/ZBOX-IQ01, BIOS B220P007 05/21/2014<br /> RIP: 0010:ieee80211_deliver_skb+0x62/0x1f0 [mac80211]<br /> Code: 00 48 89 04 24 e8 9e a7 c3 df 89 c0 48 03 1c c5 a0 ea 39 a1 4c 01 6b 08 48 ff 03 48<br /> 83 7d 28 00 74 11 48 8b 45 30 48 63 55 44 83 84 d0 a8 00 00 00 01 41 8b 86 c0<br /> 11 00 00 8d 50 fd 83 fa 01<br /> RSP: 0018:ffff999040803b10 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: ffffb9903f496480 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffff999040803ce0 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d21828ac900<br /> R13: 000000000000004a R14: ffff8d2198ed89c0 R15: ffff8d2198ed8000<br /> FS: 0000000000000000(0000) GS:ffff8d24afe80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000000000a8 CR3: 0000000429810002 CR4: 00000000001706e0<br /> Call Trace:<br /> <br /> __ieee80211_rx_h_amsdu+0x1b5/0x240 [mac80211]<br /> ? ieee80211_prepare_and_rx_handle+0xcdd/0x1320 [mac80211]<br /> ? __local_bh_enable_ip+0x3b/0xa0<br /> ieee80211_prepare_and_rx_handle+0xcdd/0x1320 [mac80211]<br /> ? prepare_transfer+0x109/0x1a0 [xhci_hcd]<br /> ieee80211_rx_list+0xa80/0xda0 [mac80211]<br /> mt76_rx_complete+0x207/0x2e0 [mt76]<br /> mt76_rx_poll_complete+0x357/0x5a0 [mt76]<br /> mt76u_rx_worker+0x4f5/0x600 [mt76_usb]<br /> ? mt76_get_min_avg_rssi+0x140/0x140 [mt76]<br /> __mt76_worker_fn+0x50/0x80 [mt76]<br /> kthread+0xed/0x120<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30<br /> <br /> Since the initialization of rx-&gt;link and rx-&gt;link_sta is rather convoluted<br /> and duplicated in many places, clean it up by using a helper function to<br /> set it.<br /> <br /> [remove unnecessary rx-&gt;sta-&gt;sta.mlo check]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: let&amp;#39;s avoid panic if extent_tree is not created<br /> <br /> This patch avoids the below panic.<br /> <br /> pc : __lookup_extent_tree+0xd8/0x760<br /> lr : f2fs_do_write_data_page+0x104/0x87c<br /> sp : ffffffc010cbb3c0<br /> x29: ffffffc010cbb3e0 x28: 0000000000000000<br /> x27: ffffff8803e7f020 x26: ffffff8803e7ed40<br /> x25: ffffff8803e7f020 x24: ffffffc010cbb460<br /> x23: ffffffc010cbb480 x22: 0000000000000000<br /> x21: 0000000000000000 x20: ffffffff22e90900<br /> x19: 0000000000000000 x18: ffffffc010c5d080<br /> x17: 0000000000000000 x16: 0000000000000020<br /> x15: ffffffdb1acdbb88 x14: ffffff888759e2b0<br /> x13: 0000000000000000 x12: ffffff802da49000<br /> x11: 000000000a001200 x10: ffffff8803e7ed40<br /> x9 : ffffff8023195800 x8 : ffffff802da49078<br /> x7 : 0000000000000001 x6 : 0000000000000000<br /> x5 : 0000000000000006 x4 : ffffffc010cbba28<br /> x3 : 0000000000000000 x2 : ffffffc010cbb480<br /> x1 : 0000000000000000 x0 : ffffff8803e7ed40<br /> Call trace:<br /> __lookup_extent_tree+0xd8/0x760<br /> f2fs_do_write_data_page+0x104/0x87c<br /> f2fs_write_single_data_page+0x420/0xb60<br /> f2fs_write_cache_pages+0x418/0xb1c<br /> __f2fs_write_data_pages+0x428/0x58c<br /> f2fs_write_data_pages+0x30/0x40<br /> do_writepages+0x88/0x190<br /> __writeback_single_inode+0x48/0x448<br /> writeback_sb_inodes+0x468/0x9e8<br /> __writeback_inodes_wb+0xb8/0x2a4<br /> wb_writeback+0x33c/0x740<br /> wb_do_writeback+0x2b4/0x400<br /> wb_workfn+0xe4/0x34c<br /> process_one_work+0x24c/0x5bc<br /> worker_thread+0x3e8/0xa50<br /> kthread+0x150/0x1b4

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_qca: Fix driver shutdown on closed serdev<br /> <br /> The driver shutdown callback (which sends EDL_SOC_RESET to the device<br /> over serdev) should not be invoked when HCI device is not open (e.g. if<br /> hci_dev_open_sync() failed), because the serdev and its TTY are not open<br /> either. Also skip this step if device is powered off<br /> (qca_power_shutdown()).<br /> <br /> The shutdown callback causes use-after-free during system reboot with<br /> Qualcomm Atheros Bluetooth:<br /> <br /> Unable to handle kernel paging request at virtual address<br /> 0072662f67726fd7<br /> ...<br /> CPU: 6 PID: 1 Comm: systemd-shutdow Tainted: G W<br /> 6.1.0-rt5-00325-g8a5f56bcfcca #8<br /> Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)<br /> Call trace:<br /> tty_driver_flush_buffer+0x4/0x30<br /> serdev_device_write_flush+0x24/0x34<br /> qca_serdev_shutdown+0x80/0x130 [hci_uart]<br /> device_shutdown+0x15c/0x260<br /> kernel_restart+0x48/0xac<br /> <br /> KASAN report:<br /> <br /> BUG: KASAN: use-after-free in tty_driver_flush_buffer+0x1c/0x50<br /> Read of size 8 at addr ffff16270c2e0018 by task systemd-shutdow/1<br /> <br /> CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted<br /> 6.1.0-next-20221220-00014-gb85aaf97fb01-dirty #28<br /> Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)<br /> Call trace:<br /> dump_backtrace.part.0+0xdc/0xf0<br /> show_stack+0x18/0x30<br /> dump_stack_lvl+0x68/0x84<br /> print_report+0x188/0x488<br /> kasan_report+0xa4/0xf0<br /> __asan_load8+0x80/0xac<br /> tty_driver_flush_buffer+0x1c/0x50<br /> ttyport_write_flush+0x34/0x44<br /> serdev_device_write_flush+0x48/0x60<br /> qca_serdev_shutdown+0x124/0x274<br /> device_shutdown+0x1e8/0x350<br /> kernel_restart+0x48/0xb0<br /> __do_sys_reboot+0x244/0x2d0<br /> __arm64_sys_reboot+0x54/0x70<br /> invoke_syscall+0x60/0x190<br /> el0_svc_common.constprop.0+0x7c/0x160<br /> do_el0_svc+0x44/0xf0<br /> el0_svc+0x2c/0x6c<br /> el0t_64_sync_handler+0xbc/0x140<br /> el0t_64_sync+0x190/0x194

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efi: fix NULL-deref in init error path<br /> <br /> In cases where runtime services are not supported or have been disabled,<br /> the runtime services workqueue will never have been allocated.<br /> <br /> Do not try to destroy the workqueue unconditionally in the unlikely<br /> event that EFI initialisation fails to avoid dereferencing a NULL<br /> pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/surface: aggregator: Add missing call to ssam_request_sync_free()<br /> <br /> Although rare, ssam_request_sync_init() can fail. In that case, the<br /> request should be freed via ssam_request_sync_free(). Currently it is<br /> leaked instead. Fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86/amd: Fix refcount leak in amd_pmc_probe<br /> <br /> pci_get_domain_bus_and_slot() takes reference, the caller should release<br /> the reference by calling pci_dev_put() after use. Call pci_dev_put() in<br /> the error path to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix macsec possible null dereference when updating MAC security entity (SecY)<br /> <br /> Upon updating MAC security entity (SecY) in hw offload path, the macsec<br /> security association (SA) initialization routine is called. In case of<br /> extended packet number (epn) is enabled the salt and ssci attributes are<br /> retrieved using the MACsec driver rx_sa context which is unavailable when<br /> updating a SecY property such as encoding-sa hence the null dereference.<br /> Fix by using the provided SA to set those attributes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: IPoIB, Block PKEY interfaces with less rx queues than parent<br /> <br /> A user is able to configure an arbitrary number of rx queues when<br /> creating an interface via netlink. This doesn&amp;#39;t work for child PKEY<br /> interfaces because the child interface uses the parent receive channels.<br /> <br /> Although the child shares the parent&amp;#39;s receive channels, the number of<br /> rx queues is important for the channel_stats array: the parent&amp;#39;s rx<br /> channel index is used to access the child&amp;#39;s channel_stats. So the array<br /> has to be at least as large as the parent&amp;#39;s rx queue size for the<br /> counting to work correctly and to prevent out of bound accesses.<br /> <br /> This patch checks for the mentioned scenario and returns an error when<br /> trying to create the interface. The error is propagated to the user.