Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix netfs_read_to_pagecache() to pause on subreq failure<br /> <br /> Fix netfs_read_to_pagecache() so that it pauses the generation of new<br /> subrequests if an already-issued subrequest fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix missing barriers when accessing stream-&gt;subrequests locklessly<br /> <br /> The list of subrequests attached to stream-&gt;subrequests is accessed without<br /> locks by netfs_collect_read_results() and netfs_collect_write_results(),<br /> and then they access subreq-&gt;flags without taking a barrier after getting<br /> the subreq pointer from the list. Relatedly, the functions that build the<br /> list don&amp;#39;t use any sort of write barrier when constructing the list to make<br /> sure that the NETFS_SREQ_IN_PROGRESS flag is perceived to be set first if<br /> no lock is taken.<br /> <br /> Fix this by:<br /> <br /> (1) Add a new list_add_tail_release() function that uses a release barrier<br /> to set the pointer to the new member of the list.<br /> <br /> (2) Add a new list_first_entry_or_null_acquire() function that uses an<br /> acquire barrier to read the pointer to the first member in a list (or<br /> return NULL).<br /> <br /> (3) Use list_add_tail_release() when adding a subreq to -&gt;subrequests.<br /> <br /> (4) Use list_first_entry_or_null_acquire() when initially accessing the<br /> front of the list (when an item is removed, the pointer to the new<br /> front iterm is obtained under the same lock).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix missing locking around retry adding new subreqs<br /> <br /> Fix netfs_retry_read_subrequests() and netfs_retry_write_stream() to take<br /> the appropriate lock when adding extra subrequests into<br /> stream-&gt;subrequests.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix cancellation of a DIO and single read subrequests<br /> <br /> When the preparation of a new subrequest for a read fails, if the<br /> subrequest has already been added to the stream-&gt;subrequests list, it can&amp;#39;t<br /> simply be put and abandoned as the collector may see it. Also, if it<br /> hasn&amp;#39;t been queued yet, it has two outstanding refs that both need to be<br /> put. Both DIO read and single-read dispatch fail at this; further, both<br /> differ in the order they do things to the way buffered read works.<br /> <br /> Fix cancellation of both DIO-read and single-read subrequests that failed<br /> preparation by the following steps:<br /> <br /> (1) Harmonise all three reads (buffered, dio, single) to queue the subreq<br /> before prepping it.<br /> <br /> (2) Make all three call netfs_queue_read() to do the queuing.<br /> <br /> (3) Set NETFS_RREQ_ALL_QUEUED independently of the queuing as we don&amp;#39;t<br /> know the length of the subreq at this point.<br /> <br /> (4) In all cases, set the error and NETFS_SREQ_FAILED flag on the subreq<br /> and then call netfs_read_subreq_terminated() to deal with it. This<br /> will pass responsibility off to the collector for dealing with it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/hv-gpci: fix preempt count leak in sysfs show paths<br /> <br /> Four sysfs show() callbacks in hv-gpci take get_cpu_var(hv_gpci_reqb)<br /> (which calls preempt_disable()) but only call the matching put_cpu_var()<br /> on the error path under the &amp;#39;out:&amp;#39; label. Every successful read leaks<br /> one preempt_disable():<br /> <br /> processor_bus_topology_show()<br /> processor_config_show()<br /> affinity_domain_via_virtual_processor_show()<br /> affinity_domain_via_domain_show()<br /> <br /> (affinity_domain_via_partition_show() was already correct.)<br /> <br /> On a CONFIG_PREEMPT=y kernel, repeated reads raise preempt_count and<br /> eventually return to userspace with preemption still disabled. The<br /> next user-mode page fault then hits faulthandler_disabled() == 1,<br /> gets forced to SIGSEGV, and the resulting coredump trips<br /> &amp;#39;BUG: scheduling while atomic&amp;#39; in call_usermodehelper_exec -&gt;<br /> wait_for_completion_state -&gt; schedule:<br /> <br /> BUG: scheduling while atomic: //0x00000004<br /> ...<br /> __schedule_bug+0x6c/0x90<br /> __schedule+0x58c/0x13a0<br /> schedule+0x48/0x1a0<br /> schedule_timeout+0x104/0x170<br /> wait_for_completion_state+0x16c/0x330<br /> call_usermodehelper_exec+0x254/0x2d0<br /> vfs_coredump+0x1050/0x2590<br /> get_signal+0xb9c/0xc80<br /> do_notify_resume+0xf8/0x470<br /> <br /> Add an out_success label that calls put_cpu_var() before returning<br /> the byte count, mirroring affinity_domain_via_partition_show().

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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).

*** Pendiente de traducción *** 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".