Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Pass ab pointer directly to ath12k_dp_tx_get_encap_type()<br /> <br /> In ath12k_dp_tx_get_encap_type(), the arvif parameter is only used to<br /> retrieve the ab pointer. In vdev delete sequence the arvif-&gt;ar could<br /> become NULL and that would trigger kernel panic.<br /> Since the caller ath12k_dp_tx() already has a valid ab pointer, pass it<br /> directly to avoid panic and unnecessary dereferencing.<br /> <br /> PC points to "ath12k_dp_tx+0x228/0x988 [ath12k]"<br /> LR points to "ath12k_dp_tx+0xc8/0x988 [ath12k]".<br /> The Backtrace obtained is as follows:<br /> ath12k_dp_tx+0x228/0x988 [ath12k]<br /> ath12k_mac_tx_check_max_limit+0x608/0x920 [ath12k]<br /> ieee80211_process_measurement_req+0x320/0x348 [mac80211]<br /> ieee80211_tx_dequeue+0x9ac/0x1518 [mac80211]<br /> ieee80211_tx_dequeue+0xb14/0x1518 [mac80211]<br /> ieee80211_tx_prepare_skb+0x224/0x254 [mac80211]<br /> ieee80211_xmit+0xec/0x100 [mac80211]<br /> __ieee80211_subif_start_xmit+0xc50/0xf40 [mac80211]<br /> ieee80211_subif_start_xmit+0x2e8/0x308 [mac80211]<br /> netdev_start_xmit+0x150/0x18c<br /> dev_hard_start_xmit+0x74/0xc0<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtl818x: Kill URBs before clearing tx status queue<br /> <br /> In rtl8187_stop() move the call of usb_kill_anchored_urbs() before clearing<br /> b_tx_status.queue. This change prevents callbacks from using already freed<br /> skb due to anchor was not killed before freeing such skb.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000080<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted 6.15.0 #8 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:ieee80211_tx_status_irqsafe+0x21/0xc0 [mac80211]<br /> Call Trace:<br /> <br /> rtl8187_tx_cb+0x116/0x150 [rtl8187]<br /> __usb_hcd_giveback_urb+0x9d/0x120<br /> usb_giveback_urb_bh+0xbb/0x140<br /> process_one_work+0x19b/0x3c0<br /> bh_worker+0x1a7/0x210<br /> tasklet_action+0x10/0x30<br /> handle_softirqs+0xf0/0x340<br /> __irq_exit_rcu+0xcd/0xf0<br /> common_interrupt+0x85/0xa0<br /> <br /> <br /> Tested on RTL8187BvE device.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iwlwifi: Add missing check for alloc_ordered_workqueue<br /> <br /> Add check for the return value of alloc_ordered_workqueue since it may<br /> return NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: clear initialized flag for deinit-ed srng lists<br /> <br /> In a number of cases we see kernel panics on resume due<br /> to ath11k kernel page fault, which happens under the<br /> following circumstances:<br /> <br /> 1) First ath11k_hal_dump_srng_stats() call<br /> <br /> Last interrupt received for each group:<br /> ath11k_pci 0000:01:00.0: group_id 0 22511ms before<br /> ath11k_pci 0000:01:00.0: group_id 1 14440788ms before<br /> [..]<br /> ath11k_pci 0000:01:00.0: failed to receive control response completion, polling..<br /> ath11k_pci 0000:01:00.0: Service connect timeout<br /> ath11k_pci 0000:01:00.0: failed to connect to HTT: -110<br /> ath11k_pci 0000:01:00.0: failed to start core: -110<br /> ath11k_pci 0000:01:00.0: firmware crashed: MHI_CB_EE_RDDM<br /> ath11k_pci 0000:01:00.0: already resetting count 2<br /> ath11k_pci 0000:01:00.0: failed to wait wlan mode request (mode 4): -110<br /> ath11k_pci 0000:01:00.0: qmi failed to send wlan mode off: -110<br /> ath11k_pci 0000:01:00.0: failed to reconfigure driver on crash recovery<br /> [..]<br /> <br /> 2) At this point reconfiguration fails (we have 2 resets) and<br /> ath11k_core_reconfigure_on_crash() calls ath11k_hal_srng_deinit()<br /> which destroys srng lists. However, it does not reset per-list<br /> -&gt;initialized flag.<br /> <br /> 3) Second ath11k_hal_dump_srng_stats() call sees stale -&gt;initialized<br /> flag and attempts to dump srng stats:<br /> <br /> Last interrupt received for each group:<br /> ath11k_pci 0000:01:00.0: group_id 0 66785ms before<br /> ath11k_pci 0000:01:00.0: group_id 1 14485062ms before<br /> ath11k_pci 0000:01:00.0: group_id 2 14485062ms before<br /> ath11k_pci 0000:01:00.0: group_id 3 14485062ms before<br /> ath11k_pci 0000:01:00.0: group_id 4 14780845ms before<br /> ath11k_pci 0000:01:00.0: group_id 5 14780845ms before<br /> ath11k_pci 0000:01:00.0: group_id 6 14485062ms before<br /> ath11k_pci 0000:01:00.0: group_id 7 66814ms before<br /> ath11k_pci 0000:01:00.0: group_id 8 68997ms before<br /> ath11k_pci 0000:01:00.0: group_id 9 67588ms before<br /> ath11k_pci 0000:01:00.0: group_id 10 69511ms before<br /> BUG: unable to handle page fault for address: ffffa007404eb010<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 100000067 P4D 100000067 PUD 10022d067 PMD 100b01067 PTE 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> RIP: 0010:ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k]<br /> Call Trace:<br /> <br /> ? __die_body+0xae/0xb0<br /> ? page_fault_oops+0x381/0x3e0<br /> ? exc_page_fault+0x69/0xa0<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)]<br /> ath11k_qmi_driver_event_work+0xbd/0x1050 [ath11k (HASH:6cea 4)]<br /> worker_thread+0x389/0x930<br /> kthread+0x149/0x170<br /> <br /> Clear per-list -&gt;initialized flag in ath11k_hal_srng_deinit().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Fix UAF on sva unbind with pending IOPFs<br /> <br /> Commit 17fce9d2336d ("iommu/vt-d: Put iopf enablement in domain attach<br /> path") disables IOPF on device by removing the device from its IOMMU&amp;#39;s<br /> IOPF queue when the last IOPF-capable domain is detached from the device.<br /> Unfortunately, it did this in a wrong place where there are still pending<br /> IOPFs. As a result, a use-after-free error is potentially triggered and<br /> eventually a kernel panic with a kernel trace similar to the following:<br /> <br /> refcount_t: underflow; use-after-free.<br /> WARNING: CPU: 3 PID: 313 at lib/refcount.c:28 refcount_warn_saturate+0xd8/0xe0<br /> Workqueue: iopf_queue/dmar0-iopfq iommu_sva_handle_iopf<br /> Call Trace:<br /> <br /> iopf_free_group+0xe/0x20<br /> process_one_work+0x197/0x3d0<br /> worker_thread+0x23a/0x350<br /> ? rescuer_thread+0x4a0/0x4a0<br /> kthread+0xf8/0x230<br /> ? finish_task_switch.isra.0+0x81/0x260<br /> ? kthreads_online_cpu+0x110/0x110<br /> ? kthreads_online_cpu+0x110/0x110<br /> ret_from_fork+0x13b/0x170<br /> ? kthreads_online_cpu+0x110/0x110<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The intel_pasid_tear_down_entry() function is responsible for blocking<br /> hardware from generating new page faults and flushing all in-flight<br /> ones. Therefore, moving iopf_for_domain_remove() after this function<br /> should resolve this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen: fix UAF in dmabuf_exp_from_pages()<br /> <br /> [dma_buf_fd() fixes; no preferences regarding the tree it goes through -<br /> up to xen folks]<br /> <br /> As soon as we&amp;#39;d inserted a file reference into descriptor table, another<br /> thread could close it. That&amp;#39;s fine for the case when all we are doing is<br /> returning that descriptor to userland (it&amp;#39;s a race, but it&amp;#39;s a userland<br /> race and there&amp;#39;s nothing the kernel can do about it). However, if we<br /> follow fd_install() with any kind of access to objects that would be<br /> destroyed on close (be it the struct file itself or anything destroyed<br /> by its -&gt;release()), we have a UAF.<br /> <br /> dma_buf_fd() is a combination of reserving a descriptor and fd_install().<br /> gntdev dmabuf_exp_from_pages() calls it and then proceeds to access the<br /> objects destroyed on close - starting with gntdev_dmabuf itself.<br /> <br /> Fix that by doing reserving descriptor before anything else and do<br /> fd_install() only when everything had been set up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panthor: Fix UAF in panthor_gem_create_with_handle() debugfs code<br /> <br /> The object is potentially already gone after the drm_gem_object_put().<br /> In general the object should be fully constructed before calling<br /> drm_gem_handle_create(), except the debugfs tracking uses a separate<br /> lock and list and separate flag to denotate whether the object is<br /> actually initialized.<br /> <br /> Since I&amp;#39;m touching this all anyway simplify this by only adding the<br /> object to the debugfs when it&amp;#39;s ready for that, which allows us to<br /> delete that separate flag. panthor_gem_debugfs_bo_rm() already checks<br /> whether we&amp;#39;ve actually been added to the list or this is some error<br /> path cleanup.<br /> <br /> v2: Fix build issues for !CONFIG_DEBUGFS (Adrián)<br /> <br /> v3: Add linebreak and remove outdated comment (Liviu)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/rockchip: vop2: fail cleanly if missing a primary plane for a video-port<br /> <br /> Each window of a vop2 is usable by a specific set of video ports, so while<br /> binding the vop2, we look through the list of available windows trying to<br /> find one designated as primary-plane and usable by that specific port.<br /> <br /> The code later wants to use drm_crtc_init_with_planes with that found<br /> primary plane, but nothing has checked so far if a primary plane was<br /> actually found.<br /> <br /> For whatever reason, the rk3576 vp2 does not have a usable primary window<br /> (if vp0 is also in use) which brought the issue to light and ended in a<br /> null-pointer dereference further down.<br /> <br /> As we expect a primary-plane to exist for a video-port, add a check at<br /> the end of the window-iteration and fail probing if none was found.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix use-after-free in amdgpu_userq_suspend+0x51a/0x5a0<br /> <br /> [ +0.000020] BUG: KASAN: slab-use-after-free in amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu]<br /> [ +0.000817] Read of size 8 at addr ffff88812eec8c58 by task amd_pci_unplug/1733<br /> <br /> [ +0.000027] CPU: 10 UID: 0 PID: 1733 Comm: amd_pci_unplug Tainted: G W 6.14.0+ #2<br /> [ +0.000009] Tainted: [W]=WARN<br /> [ +0.000003] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020<br /> [ +0.000004] Call Trace:<br /> [ +0.000004] <br /> [ +0.000003] dump_stack_lvl+0x76/0xa0<br /> [ +0.000011] print_report+0xce/0x600<br /> [ +0.000009] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000006] ? kasan_complete_mode_report_info+0x76/0x200<br /> [ +0.000007] ? kasan_addr_to_slab+0xd/0xb0<br /> [ +0.000006] ? amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu]<br /> [ +0.000707] kasan_report+0xbe/0x110<br /> [ +0.000006] ? amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu]<br /> [ +0.000541] __asan_report_load8_noabort+0x14/0x30<br /> [ +0.000005] amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu]<br /> [ +0.000535] ? stop_cpsch+0x396/0x600 [amdgpu]<br /> [ +0.000556] ? stop_cpsch+0x429/0x600 [amdgpu]<br /> [ +0.000536] ? __pfx_amdgpu_userq_suspend+0x10/0x10 [amdgpu]<br /> [ +0.000536] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? kgd2kfd_suspend+0x132/0x1d0 [amdgpu]<br /> [ +0.000542] amdgpu_device_fini_hw+0x581/0xe90 [amdgpu]<br /> [ +0.000485] ? down_write+0xbb/0x140<br /> [ +0.000007] ? __mutex_unlock_slowpath.constprop.0+0x317/0x360<br /> [ +0.000005] ? __pfx_amdgpu_device_fini_hw+0x10/0x10 [amdgpu]<br /> [ +0.000482] ? __kasan_check_write+0x14/0x30<br /> [ +0.000004] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? up_write+0x55/0xb0<br /> [ +0.000007] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000005] ? blocking_notifier_chain_unregister+0x6c/0xc0<br /> [ +0.000008] amdgpu_driver_unload_kms+0x69/0x90 [amdgpu]<br /> [ +0.000484] amdgpu_pci_remove+0x93/0x130 [amdgpu]<br /> [ +0.000482] pci_device_remove+0xae/0x1e0<br /> [ +0.000008] device_remove+0xc7/0x180<br /> [ +0.000008] device_release_driver_internal+0x3d4/0x5a0<br /> [ +0.000007] device_release_driver+0x12/0x20<br /> [ +0.000004] pci_stop_bus_device+0x104/0x150<br /> [ +0.000006] pci_stop_and_remove_bus_device_locked+0x1b/0x40<br /> [ +0.000005] remove_store+0xd7/0xf0<br /> [ +0.000005] ? __pfx_remove_store+0x10/0x10<br /> [ +0.000006] ? __pfx__copy_from_iter+0x10/0x10<br /> [ +0.000006] ? __pfx_dev_attr_store+0x10/0x10<br /> [ +0.000006] dev_attr_store+0x3f/0x80<br /> [ +0.000006] sysfs_kf_write+0x125/0x1d0<br /> [ +0.000004] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000005] ? __kasan_check_write+0x14/0x30<br /> [ +0.000005] kernfs_fop_write_iter+0x2ea/0x490<br /> [ +0.000005] ? rw_verify_area+0x70/0x420<br /> [ +0.000005] ? __pfx_kernfs_fop_write_iter+0x10/0x10<br /> [ +0.000006] vfs_write+0x90d/0xe70<br /> [ +0.000005] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000005] ? __pfx_vfs_write+0x10/0x10<br /> [ +0.000004] ? local_clock+0x15/0x30<br /> [ +0.000008] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? __kasan_slab_free+0x5f/0x80<br /> [ +0.000005] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? __kasan_check_read+0x11/0x20<br /> [ +0.000004] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? fdget_pos+0x1d3/0x500<br /> [ +0.000007] ksys_write+0x119/0x220<br /> [ +0.000005] ? putname+0x1c/0x30<br /> [ +0.000006] ? __pfx_ksys_write+0x10/0x10<br /> [ +0.000007] __x64_sys_write+0x72/0xc0<br /> [ +0.000006] x64_sys_call+0x18ab/0x26f0<br /> [ +0.000006] do_syscall_64+0x7c/0x170<br /> [ +0.000004] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? __pfx___x64_sys_openat+0x10/0x10<br /> [ +0.000006] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? __kasan_check_read+0x11/0x20<br /> [ +0.000003] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? fpregs_assert_state_consistent+0x21/0xb0<br /> [ +0.000006] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? syscall_exit_to_user_mode+0x4e/0x240<br /> [ +0.000005] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? do_syscall_64+0x88/0x170<br /> [ +0.000003] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? irqentry_exit+0x43/0x50<br /> [ +0.000004] ? srso_return_thunk+0x5<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: Fix possible OOB access in mt7996_tx()<br /> <br /> Fis possible Out-Of-Boundary access in mt7996_tx routine if link_id is<br /> set to IEEE80211_LINK_UNSPECIFIED

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: fix double free in &amp;#39;hci_discovery_filter_clear()&amp;#39;<br /> <br /> Function &amp;#39;hci_discovery_filter_clear()&amp;#39; frees &amp;#39;uuids&amp;#39; array and then<br /> sets it to NULL. There is a tiny chance of the following race:<br /> <br /> &amp;#39;hci_cmd_sync_work()&amp;#39;<br /> <br /> &amp;#39;update_passive_scan_sync()&amp;#39;<br /> <br /> &amp;#39;hci_update_passive_scan_sync()&amp;#39;<br /> <br /> &amp;#39;hci_discovery_filter_clear()&amp;#39;<br /> kfree(uuids);<br /> <br /> <br /> &amp;#39;start_service_discovery()&amp;#39;<br /> <br /> &amp;#39;hci_discovery_filter_clear()&amp;#39;<br /> kfree(uuids); // DOUBLE FREE<br /> <br /> <br /> <br /> uuids = NULL;<br /> <br /> To fix it let&amp;#39;s add locking around &amp;#39;kfree()&amp;#39; call and NULL pointer<br /> assignment. Otherwise the following backtrace fires:<br /> <br /> [ ] ------------[ cut here ]------------<br /> [ ] kernel BUG at mm/slub.c:547!<br /> [ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP<br /> [ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1<br /> [ ] Tainted: [O]=OOT_MODULE<br /> [ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ ] pc : __slab_free+0xf8/0x348<br /> [ ] lr : __slab_free+0x48/0x348<br /> ...<br /> [ ] Call trace:<br /> [ ] __slab_free+0xf8/0x348<br /> [ ] kfree+0x164/0x27c<br /> [ ] start_service_discovery+0x1d0/0x2c0<br /> [ ] hci_sock_sendmsg+0x518/0x924<br /> [ ] __sock_sendmsg+0x54/0x60<br /> [ ] sock_write_iter+0x98/0xf8<br /> [ ] do_iter_readv_writev+0xe4/0x1c8<br /> [ ] vfs_writev+0x128/0x2b0<br /> [ ] do_writev+0xfc/0x118<br /> [ ] __arm64_sys_writev+0x20/0x2c<br /> [ ] invoke_syscall+0x68/0xf0<br /> [ ] el0_svc_common.constprop.0+0x40/0xe0<br /> [ ] do_el0_svc+0x1c/0x28<br /> [ ] el0_svc+0x30/0xd0<br /> [ ] el0t_64_sync_handler+0x100/0x12c<br /> [ ] el0t_64_sync+0x194/0x198<br /> [ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000)<br /> [ ] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, arm64: Fix fp initialization for exception boundary<br /> <br /> In the ARM64 BPF JIT when prog-&gt;aux-&gt;exception_boundary is set for a BPF<br /> program, find_used_callee_regs() is not called because for a program<br /> acting as exception boundary, all callee saved registers are saved.<br /> find_used_callee_regs() sets `ctx-&gt;fp_used = true;` when it sees FP<br /> being used in any of the instructions.<br /> <br /> For programs acting as exception boundary, ctx-&gt;fp_used remains false<br /> even if frame pointer is used by the program and therefore, FP is not<br /> set-up for such programs in the prologue. This can cause the kernel to<br /> crash due to a pagefault.<br /> <br /> Fix it by setting ctx-&gt;fp_used = true for exception boundary programs as<br /> fp is always saved in such programs.