Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects<br /> <br /> The hwmp code use objects of type mesh_preq_queue, added to a list in<br /> ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath<br /> gets deleted, ex mesh interface is removed, the entries in that list will<br /> never get cleaned. Fix this by flushing all corresponding items of the<br /> preq_queue in mesh_path_flush_pending().<br /> <br /> This should take care of KASAN reports like this:<br /> <br /> unreferenced object 0xffff00000668d800 (size 128):<br /> comm "kworker/u8:4", pid 67, jiffies 4295419552 (age 1836.444s)<br /> hex dump (first 32 bytes):<br /> 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h.....<br /> 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....&gt;...........<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x1e0/0x35c<br /> [] kmalloc_trace+0x34/0x80<br /> [] mesh_queue_preq+0x44/0x2a8<br /> [] mesh_nexthop_resolve+0x198/0x19c<br /> [] ieee80211_xmit+0x1d0/0x1f4<br /> [] __ieee80211_subif_start_xmit+0x30c/0x764<br /> [] ieee80211_subif_start_xmit+0x9c/0x7a4<br /> [] dev_hard_start_xmit+0x174/0x440<br /> [] __dev_queue_xmit+0xe24/0x111c<br /> [] batadv_send_skb_packet+0x180/0x1e4<br /> [] batadv_v_elp_periodic_work+0x2f4/0x508<br /> [] process_one_work+0x4b8/0xa1c<br /> [] worker_thread+0x9c/0x634<br /> [] kthread+0x1bc/0x1c4<br /> [] ret_from_fork+0x10/0x20<br /> unreferenced object 0xffff000009051f00 (size 128):<br /> comm "kworker/u8:4", pid 67, jiffies 4295419553 (age 1836.440s)<br /> hex dump (first 32 bytes):<br /> 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h.....<br /> 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6&amp;#39;.......Xy.....<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x1e0/0x35c<br /> [] kmalloc_trace+0x34/0x80<br /> [] mesh_queue_preq+0x44/0x2a8<br /> [] mesh_nexthop_resolve+0x198/0x19c<br /> [] ieee80211_xmit+0x1d0/0x1f4<br /> [] __ieee80211_subif_start_xmit+0x30c/0x764<br /> [] ieee80211_subif_start_xmit+0x9c/0x7a4<br /> [] dev_hard_start_xmit+0x174/0x440<br /> [] __dev_queue_xmit+0xe24/0x111c<br /> [] batadv_send_skb_packet+0x180/0x1e4<br /> [] batadv_v_elp_periodic_work+0x2f4/0x508<br /> [] process_one_work+0x4b8/0xa1c<br /> [] worker_thread+0x9c/0x634<br /> [] kthread+0x1bc/0x1c4<br /> [] ret_from_fork+0x10/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/kexec: Fix bug with call depth tracking<br /> <br /> The call to cc_platform_has() triggers a fault and system crash if call depth<br /> tracking is active because the GS segment has been reset by load_segments() and<br /> GS_BASE is now 0 but call depth tracking uses per-CPU variables to operate.<br /> <br /> Call cc_platform_has() earlier in the function when GS is still valid.<br /> <br /> [ bp: Massage. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: Return right value in iommu_sva_bind_device()<br /> <br /> iommu_sva_bind_device() should return either a sva bond handle or an<br /> ERR_PTR value in error cases. Existing drivers (idxd and uacce) only<br /> check the return value with IS_ERR(). This could potentially lead to<br /> a kernel NULL pointer dereference issue if the function returns NULL<br /> instead of an error pointer.<br /> <br /> In reality, this doesn&amp;#39;t cause any problems because iommu_sva_bind_device()<br /> only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA.<br /> In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will<br /> return an error, and the device drivers won&amp;#39;t call iommu_sva_bind_device()<br /> at all.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gve: Clear napi-&gt;skb before dev_kfree_skb_any()<br /> <br /> gve_rx_free_skb incorrectly leaves napi-&gt;skb referencing an skb after it<br /> is freed with dev_kfree_skb_any(). This can result in a subsequent call<br /> to napi_get_frags returning a dangling pointer.<br /> <br /> Fix this by clearing napi-&gt;skb before the skb is freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: don&amp;#39;t read past the mfuart notifcation<br /> <br /> In case the firmware sends a notification that claims it has more data<br /> than it has, we will read past that was allocated for the notification.<br /> Remove the print of the buffer, we won&amp;#39;t see it by default. If needed,<br /> we can see the content with tracing.<br /> <br /> This was reported by KFENCE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix races between hole punching and AIO+DIO<br /> <br /> After commit "ocfs2: return real error code in ocfs2_dio_wr_get_block",<br /> fstests/generic/300 become from always failed to sometimes failed:<br /> <br /> ========================================================================<br /> [ 473.293420 ] run fstests generic/300<br /> <br /> [ 475.296983 ] JBD2: Ignoring recovery information on journal<br /> [ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode.<br /> [ 494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found<br /> [ 494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted.<br /> [ 494.292018 ] OCFS2: File system is now read-only.<br /> [ 494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30<br /> [ 494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3<br /> fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072<br /> =========================================================================<br /> <br /> In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten<br /> extents to a list. extents are also inserted into extent tree in<br /> ocfs2_write_begin_nolock. Then another thread call fallocate to puch a<br /> hole at one of the unwritten extent. The extent at cpos was removed by<br /> ocfs2_remove_extent(). At end io worker thread, ocfs2_search_extent_list<br /> found there is no such extent at the cpos.<br /> <br /> T1 T2 T3<br /> inode lock<br /> ...<br /> insert extents<br /> ...<br /> inode unlock<br /> ocfs2_fallocate<br /> __ocfs2_change_file_space<br /> inode lock<br /> lock ip_alloc_sem<br /> ocfs2_remove_inode_range inode<br /> ocfs2_remove_btree_range<br /> ocfs2_remove_extent<br /> ^---remove the extent at cpos 78723<br /> ...<br /> unlock ip_alloc_sem<br /> inode unlock<br /> ocfs2_dio_end_io<br /> ocfs2_dio_end_io_write<br /> lock ip_alloc_sem<br /> ocfs2_mark_extent_written<br /> ocfs2_change_extent_flag<br /> ocfs2_search_extent_list<br /> ^---failed to find extent<br /> ...<br /> unlock ip_alloc_sem<br /> <br /> In most filesystems, fallocate is not compatible with racing with AIO+DIO,<br /> so fix it by adding to wait for all dio before fallocate/punch_hole like<br /> ext4.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bridge: mst: pass vlan group directly to br_mst_vlan_set_state<br /> <br /> Pass the already obtained vlan group pointer to br_mst_vlan_set_state()<br /> instead of dereferencing it again. Each caller has already correctly<br /> dereferenced it for their context. This change is required for the<br /> following suspicious RCU dereference fix. No functional changes<br /> intended.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/rsrc: don&amp;#39;t lock while !TASK_RUNNING<br /> <br /> There is a report of io_rsrc_ref_quiesce() locking a mutex while not<br /> TASK_RUNNING, which is due to forgetting restoring the state back after<br /> io_run_task_work_sig() and attempts to break out of the waiting loop.<br /> <br /> do not call blocking ops when !TASK_RUNNING; state=1 set at<br /> [] prepare_to_wait+0xa4/0x380<br /> kernel/sched/wait.c:237<br /> WARNING: CPU: 2 PID: 397056 at kernel/sched/core.c:10099<br /> __might_sleep+0x114/0x160 kernel/sched/core.c:10099<br /> RIP: 0010:__might_sleep+0x114/0x160 kernel/sched/core.c:10099<br /> Call Trace:<br /> <br /> __mutex_lock_common kernel/locking/mutex.c:585 [inline]<br /> __mutex_lock+0xb4/0x940 kernel/locking/mutex.c:752<br /> io_rsrc_ref_quiesce+0x590/0x940 io_uring/rsrc.c:253<br /> io_sqe_buffers_unregister+0xa2/0x340 io_uring/rsrc.c:799<br /> __io_uring_register io_uring/register.c:424 [inline]<br /> __do_sys_io_uring_register+0x5b9/0x2400 io_uring/register.c:613<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xd8/0x270 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x6f/0x77

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau: don&amp;#39;t attempt to schedule hpd_work on headless cards<br /> <br /> If the card doesn&amp;#39;t have display hardware, hpd_work and hpd_lock are<br /> left uninitialized which causes BUG when attempting to schedule hpd_work<br /> on runtime PM resume.<br /> <br /> Fix it by adding headless flag to DRM and skip any hpd if it&amp;#39;s set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xhci: Handle TD clearing for multiple streams case<br /> <br /> When multiple streams are in use, multiple TDs might be in flight when<br /> an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for<br /> each, to ensure everything is reset properly and the caches cleared.<br /> Change the logic so that any N&gt;1 TDs found active for different streams<br /> are deferred until after the first one is processed, calling<br /> xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to<br /> queue another command until we are done with all of them. Also change<br /> the error/"should never happen" paths to ensure we at least clear any<br /> affected TDs, even if we can&amp;#39;t issue a command to clear the hardware<br /> cache, and complain loudly with an xhci_warn() if this ever happens.<br /> <br /> This problem case dates back to commit e9df17eb1408 ("USB: xhci: Correct<br /> assumptions about number of rings per endpoint.") early on in the XHCI<br /> driver&amp;#39;s life, when stream support was first added.<br /> It was then identified but not fixed nor made into a warning in commit<br /> 674f8438c121 ("xhci: split handling halted endpoints into two steps"),<br /> which added a FIXME comment for the problem case (without materially<br /> changing the behavior as far as I can tell, though the new logic made<br /> the problem more obvious).<br /> <br /> Then later, in commit 94f339147fc3 ("xhci: Fix failure to give back some<br /> cached cancelled URBs."), it was acknowledged again.<br /> <br /> [Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cached<br /> cancelled URBs.") was a targeted regression fix to the previously mentioned<br /> patch. Users reported issues with usb stuck after unmounting/disconnecting<br /> UAS devices. This rolled back the TD clearing of multiple streams to its<br /> original state.]<br /> <br /> Apparently the commit author was aware of the problem (yet still chose<br /> to submit it): It was still mentioned as a FIXME, an xhci_dbg() was<br /> added to log the problem condition, and the remaining issue was mentioned<br /> in the commit description. The choice of making the log type xhci_dbg()<br /> for what is, at this point, a completely unhandled and known broken<br /> condition is puzzling and unfortunate, as it guarantees that no actual<br /> users would see the log in production, thereby making it nigh<br /> undebuggable (indeed, even if you turn on DEBUG, the message doesn&amp;#39;t<br /> really hint at there being a problem at all).<br /> <br /> It took me *months* of random xHC crashes to finally find a reliable<br /> repro and be able to do a deep dive debug session, which could all have<br /> been avoided had this unhandled, broken condition been actually reported<br /> with a warning, as it should have been as a bug intentionally left in<br /> unfixed (never mind that it shouldn&amp;#39;t have been left in at all).<br /> <br /> &gt; Another fix to solve clearing the caches of all stream rings with<br /> &gt; cancelled TDs is needed, but not as urgent.<br /> <br /> 3 years after that statement and 14 years after the original bug was<br /> introduced, I think it&amp;#39;s finally time to fix it. And maybe next time<br /> let&amp;#39;s not leave bugs unfixed (that are actually worse than the original<br /> bug), and let&amp;#39;s actually get people to review kernel commits please.<br /> <br /> Fixes xHC crashes and IOMMU faults with UAS devices when handling<br /> errors/faults. Easiest repro is to use `hdparm` to mark an early sector<br /> (e.g. 1024) on a disk as bad, then `cat /dev/sdX &gt; /dev/null` in a loop.<br /> At least in the case of JMicron controllers, the read errors end up<br /> having to cancel two TDs (for two queued requests to different streams)<br /> and the one that didn&amp;#39;t get cleared properly ends up faulting the xHC<br /> entirely when it tries to access DMA pages that have since been unmapped,<br /> referred to by the stale TDs. This normally happens quickly (after two<br /> or three loops). After this fix, I left the `cat` in a loop running<br /> overnight and experienced no xHC failures, with all read errors<br /> recovered properly. Repro&amp;#39;d and tested on an Apple M1 Mac Mini<br /> (dwc3 host).<br /> <br /> On systems without an IOMMU, this bug would instead silently corrupt<br /> freed memory, making this a<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethtool: fix the error condition in ethtool_get_phy_stats_ethtool()<br /> <br /> Clang static checker (scan-build) warning:<br /> net/ethtool/ioctl.c:line 2233, column 2<br /> Called function pointer is null (null dereference).<br /> <br /> Return &amp;#39;-EOPNOTSUPP&amp;#39; when &amp;#39;ops-&gt;get_ethtool_phy_stats&amp;#39; is NULL to fix<br /> this typo error.