Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix read_dev_clk_lock spinlock init in idpf_ptp_init()<br /> <br /> In idpf_ptp_init(), read_dev_clk_lock is initialized after<br /> ptp_schedule_worker() had already been called (and after<br /> idpf_ptp_settime64() could reach the lock). The PTP aux worker<br /> fires immediately upon scheduling and can call into<br /> idpf_ptp_read_src_clk_reg_direct(), which takes<br /> spin_lock(&amp;ptp-&gt;read_dev_clk_lock) on an uninitialized lock, triggering<br /> the lockdep "non-static key" warning:<br /> <br /> [12973.796587] idpf 0000:83:00.0: Device HW Reset initiated<br /> [12974.094507] INFO: trying to register non-static key.<br /> ...<br /> [12974.097208] Call Trace:<br /> [12974.097213] <br /> [12974.097218] dump_stack_lvl+0x93/0xe0<br /> [12974.097234] register_lock_class+0x4c4/0x4e0<br /> [12974.097249] ? __lock_acquire+0x427/0x2290<br /> [12974.097259] __lock_acquire+0x98/0x2290<br /> [12974.097272] lock_acquire+0xc6/0x310<br /> [12974.097281] ? idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf]<br /> [12974.097311] ? lockdep_hardirqs_on_prepare+0xde/0x190<br /> [12974.097318] ? finish_task_switch.isra.0+0xd2/0x350<br /> [12974.097330] ? __pfx_ptp_aux_kworker+0x10/0x10 [ptp]<br /> [12974.097343] _raw_spin_lock+0x30/0x40<br /> [12974.097353] ? idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf]<br /> [12974.097373] idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf]<br /> [12974.097391] ? kthread_worker_fn+0x88/0x3d0<br /> [12974.097404] ? kthread_worker_fn+0x4e/0x3d0<br /> [12974.097411] idpf_ptp_update_cached_phctime+0x26/0x120 [idpf]<br /> [12974.097428] ? _raw_spin_unlock_irq+0x28/0x50<br /> [12974.097436] idpf_ptp_do_aux_work+0x15/0x20 [idpf]<br /> [12974.097454] ptp_aux_kworker+0x20/0x40 [ptp]<br /> [12974.097464] kthread_worker_fn+0xd5/0x3d0<br /> [12974.097474] ? __pfx_kthread_worker_fn+0x10/0x10<br /> [12974.097482] kthread+0xf4/0x130<br /> [12974.097489] ? __pfx_kthread+0x10/0x10<br /> [12974.097498] ret_from_fork+0x32c/0x410<br /> [12974.097512] ? __pfx_kthread+0x10/0x10<br /> [12974.097519] ret_from_fork_asm+0x1a/0x30<br /> [12974.097540] <br /> <br /> Move the call to spin_lock_init() up a bit to make sure read_dev_clk_lock<br /> is not touched before it&amp;#39;s been initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/adreno: Fix a reference leak in a6xx_gpu_init()<br /> <br /> In a6xx_gpu_init(), node is obtained via of_parse_phandle().<br /> While there was a manual of_node_put() at the end of the<br /> common path, several early error returns would bypass this call,<br /> resulting in a reference leak.<br /> Fix this by using the __free(device_node) cleanup handler to<br /> release the reference when the variable goes out of scope.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/700661/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix error path leaks in some WMI WOW calls<br /> <br /> Fix two instances where we used to directly return the result of<br /> ath11k_wmi_cmd_send(...). Because we did not check the return value, we<br /> also did not free the skb in the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs, afs: Fix write skipping in dir/link writepages<br /> <br /> Fix netfs_write_single() and afs_single_writepages() to better handle a<br /> write that would be skipped due to lock contention and WB_SYNC_NONE by<br /> returning 1 from netfs_write_single() if it skipped and making<br /> afs_single_writepages() skip also. If a skip occurs, the inode must be<br /> re-marked as the VFS may have cleared the mark.<br /> <br /> This is really only theoretical for directories in netfs_write_single() as<br /> the only path to that is through afs_single_writepages() that takes the<br /> -&gt;validate_lock around it, thereby serialising it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix partial invalidation of streaming-write folio<br /> <br /> In netfs_invalidate_folio(), if the region of a partial invalidation<br /> overlaps the front (but not all) of a dirty write cached in a streaming<br /> write page (dirty, but not uptodate, with the dirty region tracked by a<br /> netfs_folio struct), the function modifies the dirty region - but<br /> incorrectly as it moves the region forward by setting the start to the<br /> start, not the end, of the invalidation region.<br /> <br /> Fix this by setting finfo-&gt;dirty_offset to the end of the invalidation<br /> region (iend).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix zeropoint update where i_size &gt; remote_i_size<br /> <br /> Fix the update of the zero point[*] by netfs_release_folio() when there is<br /> uncommitted data in the pagecache beyond the folio being released but the<br /> on-server EOF is in this folio (ie. i_size &gt; remote_i_size). The update<br /> needs to limit zero_point to remote_i_size, not i_size as i_size is a local<br /> phenomenon reflecting updates made locally to the pagecache, not stuff<br /> written to the server. remote_i_size tracks the server&amp;#39;s i_size.<br /> <br /> [*] The zero point is the file position from which we can assume that the<br /> server will just return zeros, so we can avoid generating reads.<br /> <br /> Note that netfs_invalidate_folio() probably doesn&amp;#39;t need fixing as<br /> zero_point should be updated by setattr after truncation or fallocate.<br /> <br /> Found with:<br /> <br /> fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \<br /> /xfstest.test/junk --replay-ops=junk.fsxops<br /> <br /> using the following as junk.fsxops:<br /> <br /> truncate 0x0 0x1bbae 0x82864<br /> write 0x3ef2e 0xf9c8 0x1bbae<br /> write 0x67e05 0xcb5a 0x4e8f6<br /> mapread 0x57781 0x85b6 0x7495f<br /> copy_range 0x5d3d 0x10329 0x54fac 0x7495f<br /> write 0x64710 0x1c2b 0x7495f<br /> mapread 0x64000 0x1000 0x7495f<br /> <br /> on cifs with the default cache option.<br /> <br /> It shows read-gaps on folio 0x64 failing with a short read (ie. it hits<br /> EOF) if the FMODE_READ check is commented out in netfs_perform_write():<br /> <br /> if (//(file-&gt;f_mode &amp; FMODE_READ) ||<br /> netfs_is_cache_enabled(ctx)) {<br /> <br /> and no fscache. This was initially found with the generic/522 xfstest.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommupt: Check for missing PAGE_SIZE in the pgsize_bitmap<br /> <br /> Sashiko pointed out that the driver could drop PAGE_SIZE from the<br /> pgsize_bitmap. That is technically allowed but nothing does it, and<br /> such an iommu_domain would not be used with the DMA API today.<br /> <br /> Still, it is against the design and it is trivial to fix up. Lift<br /> the PT_WARN_ON to the if branch and just skip the fast path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: Handle unmap error when iommu_debug is enabled<br /> <br /> Sashiko noticed a latent bug where the map error flow called iommu_unmap()<br /> which calls iommu_debug_unmap_begin()/iommu_debug_unmap_end() however<br /> since this is an error path the map flow never actually established the<br /> original iommu_debug_map() it will malfunction.<br /> <br /> Lift the unmap error handling into iommu_map_nosync() and reorder it so<br /> the trace_map()/iommu_debug_map() records the partial mapping and then<br /> immediately unmaps it. This avoid creating the unbalanced tracking and<br /> provides saner tracing instead of a unmap unmatched to any map.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix iommu_map_sgtable() return value check and avoid WARN<br /> <br /> Commit "iommu: return full error code from iommu_map_sg[_atomic]()"<br /> changed iommu_map_sgtable() to return an ssize_t and negative values<br /> in error cases, rather than a size_t and a zero.<br /> <br /> Store the return value in the appropriate type and in case of error,<br /> return it rather than WARNing.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/719685/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix write streaming disablement if fd open O_RDWR<br /> <br /> In netfs_perform_write(), "write streaming" (the caching of dirty data in<br /> dirty but !uptodate folios) is performed to avoid the need to read data<br /> that is just going to get immediately overwritten. However, this is/will<br /> be disabled in three circumstances: if the fd is open O_RDWR, if fscache is<br /> in use (as we need to round out the blocks for DIO) or if content<br /> encryption is enabled (again for rounding out purposes).<br /> <br /> The idea behind disabling it if the fd is open O_RDWR is that we&amp;#39;d need to<br /> flush the write-streaming page before we could read the data, particularly<br /> through mmap. But netfs now fills in the gaps if -&gt;read_folio() is called<br /> on the page, so that is unnecessary. Further, this doesn&amp;#39;t actually work<br /> if a separate fd is open for reading.<br /> <br /> Fix this by removing the check for O_RDWR, thereby allowing streaming<br /> writes even when we might read.<br /> <br /> This caused a number of problems with the generic/522 xfstest, but those<br /> are now fixed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: uniwill-laptop: Do not enable the charging limit even when forced<br /> <br /> It seems that on some older models (~2020) the battery charging limit<br /> can permanently damage the battery. Prevent users from enabling this<br /> feature thru the "force" module parameter to avoid causing permanent<br /> hardware damage on such devices.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btmtk: fix urb-&gt;setup_packet leak in error paths<br /> <br /> The setup_packet of control urb is not freed if usb_submit_urb fails or<br /> the submitted urb is killed. Add free in these two paths.