Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: fix use-after-free in nvme_free_host_mem()<br /> <br /> nvme_free_host_mem() frees dev-&gt;hmb_sgt via dma_free_noncontiguous()<br /> but never clears the pointer afterward. This leads to a use-after-free<br /> if nvme_free_host_mem() is called twice in the same error path.<br /> <br /> This can happen during nvme_probe() when nvme_setup_host_mem() succeeds<br /> in allocating the HMB (setting dev-&gt;hmb_sgt) but nvme_set_host_mem()<br /> fails with an I/O error:<br /> <br /> nvme_setup_host_mem()<br /> nvme_alloc_host_mem_single() -&gt; sets dev-&gt;hmb_sgt<br /> nvme_set_host_mem() -&gt; fails with -EIO<br /> nvme_free_host_mem() -&gt; frees hmb_sgt, but does NOT NULL it<br /> return error<br /> <br /> nvme_probe() error path:<br /> nvme_free_host_mem() -&gt; dev-&gt;hmb_sgt is stale, use-after-free<br /> <br /> The second call dereferences the freed sgt, causing a NULL pointer<br /> dereference in iommu_dma_free_noncontiguous() when it accesses<br /> sgt-&gt;sgl-&gt;dma_address (the backing memory has been freed and zeroed).<br /> <br /> This is reproducible on Thunderbolt-attached NVMe devices (e.g., OWC<br /> Envoy Express behind a Dell WD22TB4 dock) where the device intermittently<br /> returns I/O errors during HMB setup due to PCIe link instability.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> RIP: 0010:iommu_dma_free_noncontiguous+0x22/0x80<br /> Call Trace:<br /> <br /> dma_free_noncontiguous+0x3b/0x130<br /> nvme_free_host_mem+0x30/0xf0 [nvme]<br /> nvme_probe.cold+0xcc/0x275 [nvme]<br /> local_pci_probe+0x43/0xa0<br /> pci_device_probe+0xeea/0x290<br /> really_probe+0xf9/0x3b0<br /> __driver_probe_device+0x8b/0x170<br /> driver_probe_device+0x24/0xd0<br /> __driver_attach_async_helper+0x6b/0x110<br /> async_run_entry_fn+0x37/0x170<br /> process_one_work+0x1ac/0x3d0<br /> worker_thread+0x1b8/0x360<br /> kthread+0xf7/0x130<br /> ret_from_fork+0x2d8/0x3a0<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Fix this by setting dev-&gt;hmb_sgt to NULL after freeing it, so the<br /> second call takes the multi-descriptor path which safely handles the<br /> already-cleaned-up state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: fix bio leak on mapping failure<br /> <br /> The local bio is always NULL, so we&amp;#39;d leak the bio if the integrity<br /> mapping failed. Just get it directly from the request.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT<br /> <br /> On PREEMPT_RT, non-HARD irq_work runs in per-CPU kthreads via<br /> run_irq_workd(), so irq_work_sync() uses rcuwait() to wait for BUSY==0.<br /> <br /> After irq_work_single() clears BUSY via atomic_cmpxchg(), it still<br /> dereferences @work for irq_work_is_hard() and rcuwait_wake_up().<br /> <br /> An irq_work_sync() caller on another CPU that enters after BUSY is cleared<br /> can observe BUSY==0 immediately, return, and free the work before those<br /> accesses complete — causing a use-after-free.<br /> <br /> Fix this by wrapping run_irq_workd() in guard(rcu)() so that the entire<br /> irq_work_single() execution is within an RCU read-side critical<br /> section. Then add synchronize_rcu() in irq_work_sync() after<br /> rcuwait_wait_event() to ensure the caller waits for the RCU grace period<br /> before returning, preventing premature frees.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: cortina: Make RX SKB per-port<br /> <br /> The SKB used to assemble packets from fragments in gmac_rx()<br /> is static local, but the Gemini has two ethernet ports, meaning<br /> there can be races between the ports on a bad day if a device<br /> is using both.<br /> <br /> Make the RX SKB a per-port variable and carry it over between<br /> invocations in the port struct instead.<br /> <br /> Zero the pointer once we call napi_gro_frags(), on error (after<br /> calling napi_free_frags()) or if the port is stopped.<br /> <br /> Zero it in some place where not strictly necessary just to<br /> emphasize what is going on.<br /> <br /> This was found by Sashiko during normal patch review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix the locking used by afs_get_link()<br /> <br /> The afs filesystem in the kernel doesn&amp;#39;t do locking correctly for symbolic<br /> links. There are a number of problems:<br /> <br /> (1) It doesn&amp;#39;t do any locking around afs_read_single() to prevent races<br /> between multiple -&gt;get_link() calls, thereby allowing the possibility<br /> of leaks.<br /> <br /> (2) It doesn&amp;#39;t use RCU barriering when accessing the buffer pointers<br /> during RCU pathwalk.<br /> <br /> (3) It can race with another thread updating the contents of the symlink<br /> if a third party updated it on the server.<br /> <br /> Fix this by the following means:<br /> <br /> (0) Move symlink handling into its own file as this makes it more<br /> complicated.<br /> <br /> (1) Take the validate_lock around afs_read_single() to prevent races<br /> between multiple -&gt;get_link() calls.<br /> <br /> (2) Keep a separate copy of the symlink contents with an rcu_head. This<br /> is always going to be a lot smaller than a page, so it can be<br /> kmalloc&amp;#39;d and save quite a bit of memory. It also needs a refcount<br /> for non-RCU pathwalk.<br /> <br /> (3) Split the symlink read and write-to-cache routines in afs from those<br /> for directories.<br /> <br /> (4) Discard the I/O buffer as soon as the write-to-cache completes as this<br /> is a full page (plus a folio_queue).<br /> <br /> (5) If there&amp;#39;s no cache, discard the I/O buffer immediately after reading<br /> and copying if there is no cache.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix netfs_read_folio() to wait on writeback<br /> <br /> Fix netfs_read_folio() to wait for an ongoing writeback to complete so that<br /> it can trust the dirty flag and whatever is attached to folio-&gt;private<br /> (folio-&gt;private may get cleaned up by the collector before it clears the<br /> writeback flag).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix folio-&gt;private handling in netfs_perform_write()<br /> <br /> Under some circumstances, netfs_perform_write() doesn&amp;#39;t correctly<br /> manipulate folio-&gt;private between NULL, NETFS_FOLIO_COPY_TO_CACHE, pointing<br /> to a group and pointing to a netfs_folio struct, leading to potential<br /> multiple attachments of private data with associated folio ref leaks and<br /> also leaks of netfs_folio structs or netfs_group refs.<br /> <br /> Fix this by consolidating the place at which a folio is marked uptodate in<br /> one place and having that look at what&amp;#39;s attached to folio-&gt;private and<br /> decide how to clean it up and then set the new group. Also, the content<br /> shouldn&amp;#39;t be flushed if group is NULL, even if a group is specified in the<br /> netfs_group parameter, as that would be the case for a new folio. A<br /> filesystem should always specify netfs_group or never specify netfs_group.<br /> <br /> The Sashiko auto-review tool noted that it was theoretically possible that<br /> the fpos &gt;= ctx-&gt;zero_point section might leak if it modified a streaming<br /> write folio. This is unlikely, but with a network filesystem, third party<br /> changes can happen. It also pointed out that __netfs_set_group() would<br /> leak if called multiple times on the same folio from the "whole folio<br /> modify section".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix leak of request in netfs_write_begin() error handling<br /> <br /> Fix netfs_write_begin() to not leak our ref on the request in the event<br /> that we get an error from netfs_wait_for_read().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix early put of sink folio in netfs_read_gaps()<br /> <br /> Fix netfs_read_gaps() to release the sink page it uses after waiting for<br /> the request to complete. The way the sink page is used is that an<br /> ITER_BVEC-class iterator is created that has the gaps from the target folio<br /> at either end, but has the sink page tiled over the middle so that a single<br /> read op can fill in both gaps.<br /> <br /> The bug was found by KASAN detecting a UAF on the generic/075 xfstest in<br /> the cifsd kernel thread that handles reception of data from the TCP socket:<br /> <br /> BUG: KASAN: use-after-free in _copy_to_iter+0x48a/0xa20<br /> Write of size 885 at addr ffff888107f92000 by task cifsd/1285<br /> CPU: 2 UID: 0 PID: 1285 Comm: cifsd Not tainted 7.0.0 #6 PREEMPT(lazy)<br /> Call Trace:<br /> dump_stack_lvl+0x5d/0x80<br /> print_report+0x17f/0x4f1<br /> kasan_report+0x100/0x1e0<br /> kasan_check_range+0x10f/0x1e0<br /> __asan_memcpy+0x3c/0x60<br /> _copy_to_iter+0x48a/0xa20<br /> __skb_datagram_iter+0x2c9/0x430<br /> skb_copy_datagram_iter+0x6e/0x160<br /> tcp_recvmsg_locked+0xce0/0x1130<br /> tcp_recvmsg+0xeb/0x300<br /> inet_recvmsg+0xcf/0x3a0<br /> sock_recvmsg+0xea/0x100<br /> cifs_readv_from_socket+0x3a6/0x4d0 [cifs]<br /> cifs_read_iter_from_socket+0xdd/0x130 [cifs]<br /> cifs_readv_receive+0xaad/0xb10 [cifs]<br /> cifs_demultiplex_thread+0x1148/0x1740 [cifs]<br /> kthread+0x1cf/0x210

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix potential deadlock in write-through mode<br /> <br /> Fix netfs_advance_writethrough() to always unlock the supplied folio and to<br /> mark it dirty if it isn&amp;#39;t yet written to the end. Unfortunately, it can&amp;#39;t<br /> be marked for writeback until the folio is done with as that may cause a<br /> deadlock against mmapped reads and writes.<br /> <br /> Even though it has been marked dirty, premature writeback can&amp;#39;t occur as<br /> the caller is holding both inode-&gt;i_rwsem (which will prevent concurrent<br /> truncation, fallocation, DIO and other writes) and ictx-&gt;wb_lock (which<br /> will cause flushing to wait and writeback to skip or wait).<br /> <br /> Note that this may be easier to deal with once the queuing of folios is<br /> split from the generation of subrequests.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix streaming write being overwritten<br /> <br /> In order to avoid reading whilst writing, netfslib will allow "streaming<br /> writes" in which dirty data is stored directly into folios without reading<br /> them first. Such folios are marked dirty but may not be marked uptodate.<br /> If a folio is entirely written by a streaming write, uptodate will be set,<br /> otherwise it will have a netfs_folio struct attached to -&gt;private recording<br /> the dirty region.<br /> <br /> In the event that a partially written streaming write page is to be<br /> overwritten entirely by a single write(), netfs_perform_write() will try to<br /> copy over it, but doesn&amp;#39;t discard the netfs_folio if it succeeds; further,<br /> it doesn&amp;#39;t correctly handle a partial copy that overwrites some of the<br /> dirty data.<br /> <br /> Fix this by the following:<br /> <br /> (1) If the folio is successfully overwritten, free the netfs_folio struct<br /> before marking the page uptodate.<br /> <br /> (2) If the copy to the folio partially fails, but short of the dirty data,<br /> just ignore the copy.<br /> <br /> (3) If the copy partially fails and overwrites some of the dirty data,<br /> accept the copy, update the netfs_folio struct to record the new data.<br /> If the folio is now filled, free the netfs_folio and set uptodate,<br /> otherwise return a partial write.<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 0 0x927c0<br /> write 0x63fb8 0x53c8 0<br /> copy_range 0xb704 0x19b9 0x24429 0x79380<br /> write 0x2402b 0x144a2 0x90660 *<br /> write 0x204d5 0x140a0 0x927c0 *<br /> copy_range 0x1f72c 0x137d0 0x7a906 0x927c0 *<br /> read 0x00000 0x20000 0x9157c<br /> read 0x20000 0x20000 0x9157c<br /> read 0x40000 0x20000 0x9157c<br /> read 0x60000 0x20000 0x9157c<br /> read 0x7e1a0 0xcfb9 0x9157c<br /> <br /> on cifs with the default cache option.<br /> <br /> It shows folio 0x24 misbehaving if the FMODE_READ check is commented out in<br /> 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 /> netfs: Fix netfs_invalidate_folio() to clear dirty bit if all changes gone<br /> <br /> If a streaming write is made, this will leave the relevant modified folio<br /> in a not-uptodate, but dirty state with a netfs_folio struct hung off of<br /> folio-&gt;private indicating the dirty range. Subsequently truncating the<br /> file such that the dirty data in the folio is removed, but the first part<br /> of the folio theoretically remains will cause the netfs_folio struct to be<br /> discarded... but will leave the dirty flag set.<br /> <br /> If the folio is then read via mmap(), netfs_read_folio() will see that the<br /> page is dirty and jump to netfs_read_gaps() to fill in the missing bits.<br /> netfs_read_gaps(), however, expects there to be a netfs_folio struct<br /> present and can oops because truncate removed it.<br /> <br /> Fix this by calling folio_cancel_dirty() in netfs_invalidate_folio() in the<br /> event that all the dirty data in the folio is erased (as nfs does).<br /> <br /> Also add some tracepoints to log modifications to a dirty page.<br /> <br /> This can be reproduced with something like:<br /> <br /> dd if=/dev/zero of=/xfstest.test/foo bs=1M count=1<br /> umount /xfstest.test<br /> mount /xfstest.test<br /> xfs_io -c "w 0xbbbf 0xf96c" \<br /> -c "truncate 0xbbbf" \<br /> -c "mmap -r 0xb000 0x11000" \<br /> -c "mr 0xb000 0x11000" \<br /> /xfstest.test/foo<br /> <br /> with fscaching disabled (otherwise streaming writes are suppressed) and a<br /> change to netfs_perform_write() to disallow streaming writes if the fd is<br /> open O_RDWR:<br /> <br /> if (//(file-&gt;f_mode &amp; FMODE_READ) ||