Vulnerabilities

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: 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 /> 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 /> 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 /> 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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix possible infinite loop in fib6_info_uses_dev()<br /> <br /> fib6_info_uses_dev() seems to rely on RCU without an explicit<br /> protection.<br /> <br /> Like the prior fix in rt6_nlmsg_size(),<br /> we need to make sure fib6_del_route() or fib6_add_rt2node()<br /> have not removed the anchor from the list, or we risk an infinite loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: prevent infinite loop in rt6_nlmsg_size()<br /> <br /> While testing prior patch, I was able to trigger<br /> an infinite loop in rt6_nlmsg_size() in the following place:<br /> <br /> list_for_each_entry_rcu(sibling, &amp;f6i-&gt;fib6_siblings,<br /> fib6_siblings) {<br /> rt6_nh_nlmsg_size(sibling-&gt;fib6_nh, &amp;nexthop_len);<br /> }<br /> <br /> This is because fib6_del_route() and fib6_add_rt2node()<br /> uses list_del_rcu(), which can confuse rcu readers,<br /> because they might no longer see the head of the list.<br /> <br /> Restart the loop if f6i-&gt;fib6_nsiblings is zero.