Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false<br /> <br /> A UAF issue occurs when the virtio_net driver is configured with napi_tx=N<br /> and the device&amp;#39;s IFF_XMIT_DST_RELEASE flag is cleared<br /> (e.g., during the configuration of tc route filter rules).<br /> <br /> When IFF_XMIT_DST_RELEASE is removed from the net_device, the network stack<br /> expects the driver to hold the reference to skb-&gt;dst until the packet<br /> is fully transmitted and freed. In virtio_net with napi_tx=N,<br /> skbs may remain in the virtio transmit ring for an extended period.<br /> <br /> If the network namespace is destroyed while these skbs are still pending,<br /> the corresponding dst_ops structure has freed. When a subsequent packet<br /> is transmitted, free_old_xmit() is triggered to clean up old skbs.<br /> It then calls dst_release() on the skb associated with the stale dst_entry.<br /> Since the dst_ops (referenced by the dst_entry) has already been freed,<br /> a UAF kernel paging request occurs.<br /> <br /> fix it by adds skb_dst_drop(skb) in start_xmit to explicitly release<br /> the dst reference before the skb is queued in virtio_net.<br /> <br /> Call Trace:<br /> Unable to handle kernel paging request at virtual address ffff80007e150000<br /> CPU: 2 UID: 0 PID: 6236 Comm: ping Kdump: loaded Not tainted 7.0.0-rc1+ #6 PREEMPT<br /> ...<br /> percpu_counter_add_batch+0x3c/0x158 lib/percpu_counter.c:98 (P)<br /> dst_release+0xe0/0x110 net/core/dst.c:177<br /> skb_release_head_state+0xe8/0x108 net/core/skbuff.c:1177<br /> sk_skb_reason_drop+0x54/0x2d8 net/core/skbuff.c:1255<br /> dev_kfree_skb_any_reason+0x64/0x78 net/core/dev.c:3469<br /> napi_consume_skb+0x1c4/0x3a0 net/core/skbuff.c:1527<br /> __free_old_xmit+0x164/0x230 drivers/net/virtio_net.c:611 [virtio_net]<br /> free_old_xmit drivers/net/virtio_net.c:1081 [virtio_net]<br /> start_xmit+0x7c/0x530 drivers/net/virtio_net.c:3329 [virtio_net]<br /> ...<br /> <br /> Reproduction Steps:<br /> NETDEV="enp3s0"<br /> <br /> config_qdisc_route_filter() {<br /> tc qdisc del dev $NETDEV root<br /> tc qdisc add dev $NETDEV root handle 1: prio<br /> tc filter add dev $NETDEV parent 1:0 \<br /> protocol ip prio 100 route to 100 flowid 1:1<br /> ip route add 192.168.1.100/32 dev $NETDEV realm 100<br /> }<br /> <br /> test_ns() {<br /> ip netns add testns<br /> ip link set $NETDEV netns testns<br /> ip netns exec testns ifconfig $NETDEV 10.0.32.46/24<br /> ip netns exec testns ping -c 1 10.0.32.1<br /> ip netns del testns<br /> }<br /> <br /> config_qdisc_route_filter<br /> <br /> test_ns<br /> sleep 2<br /> test_ns

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virt: tdx-guest: Fix handling of host controlled &amp;#39;quote&amp;#39; buffer length<br /> <br /> Validate host controlled value `quote_buf-&gt;out_len` that determines how<br /> many bytes of the quote are copied out to guest userspace. In TDX<br /> environments with remote attestation, quotes are not considered private,<br /> and can be forwarded to an attestation server.<br /> <br /> Catch scenarios where the host specifies a response length larger than<br /> the guest&amp;#39;s allocation, or otherwise races modifying the response while<br /> the guest consumes it.<br /> <br /> This prevents contents beyond the pages allocated for `quote_buf`<br /> (up to TSM_REPORT_OUTBLOB_MAX) from being read out to guest userspace,<br /> and possibly forwarded in attestation requests.<br /> <br /> Recall that some deployments want per-container configs-tsm-report<br /> interfaces, so the leak may cross container protection boundaries, not<br /> just local root.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: iptfs: only publish mode_data after clone setup<br /> <br /> iptfs_clone_state() stores x-&gt;mode_data before allocating the reorder<br /> window. If that allocation fails, the code frees the cloned state and<br /> returns -ENOMEM, leaving x-&gt;mode_data pointing at freed memory.<br /> <br /> The xfrm clone unwind later runs destroy_state() through x-&gt;mode_data,<br /> so the failed clone path tears down IPTFS state that clone_state()<br /> already freed.<br /> <br /> Keep the cloned IPTFS state private until all allocations succeed so<br /> failed clones leave x-&gt;mode_data unset. The destroy path already<br /> handles a NULL mode_data pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: iptfs: validate inner IPv4 header length in IPTFS payload<br /> <br /> Add validation of the inner IPv4 packet tot_len and ihl fields parsed<br /> from decrypted IPTFS payloads in __input_process_payload(). A crafted<br /> ESP packet containing an inner IPv4 header with tot_len=0 causes an<br /> infinite loop: iplen=0 leads to capturelen=min(0, remaining)=0, so the<br /> data offset never advances and the while(data

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutex<br /> <br /> MEDIA_REQUEST_IOC_REINIT can run concurrently with VIDIOC_REQBUFS(0)<br /> queue teardown paths. This can race request object cleanup against vb2<br /> queue cancellation and lead to use-after-free reports.<br /> <br /> We already serialize request queueing against STREAMON/OFF with<br /> req_queue_mutex. Extend that serialization to REQBUFS, and also take<br /> the same mutex in media_request_ioctl_reinit() so REINIT is in the<br /> same exclusion domain.<br /> <br /> This keeps request cleanup and queue cancellation from running in<br /> parallel for request-capable devices.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iomap: fix invalid folio access when i_blkbits differs from I/O granularity<br /> <br /> Commit aa35dd5cbc06 ("iomap: fix invalid folio access after<br /> folio_end_read()") partially addressed invalid folio access for folios<br /> without an ifs attached, but it did not handle the case where<br /> 1 cur_folio = NULL;<br /> <br /> in iomap_read_folio_iter() will not invalidate ctx-&gt;cur_folio, and<br /> iomap_read_end() will still be called on the folio even though the IO<br /> helper owns it and will finish the read on it.<br /> <br /> Fix this by unconditionally invalidating ctx-&gt;cur_folio for the !ifs<br /> case.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done()<br /> <br /> A malicious or compromised VIO server can return a num_written value in the<br /> discover targets MAD response that exceeds max_targets. This value is<br /> stored directly in vhost-&gt;num_targets without validation, and is then used<br /> as the loop bound in ibmvfc_alloc_targets() to index into disc_buf[], which<br /> is only allocated for max_targets entries. Indices at or beyond max_targets<br /> access kernel memory outside the DMA-coherent allocation. The<br /> out-of-bounds data is subsequently embedded in Implicit Logout and PLOGI<br /> MADs that are sent back to the VIO server, leaking kernel memory.<br /> <br /> Fix by clamping num_written to max_targets before storing it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> writeback: don&amp;#39;t block sync for filesystems with no data integrity guarantees<br /> <br /> Add a SB_I_NO_DATA_INTEGRITY superblock flag for filesystems that cannot<br /> guarantee data persistence on sync (eg fuse). For superblocks with this<br /> flag set, sync kicks off writeback of dirty inodes but does not wait<br /> for the flusher threads to complete the writeback.<br /> <br /> This replaces the per-inode AS_NO_DATA_INTEGRITY mapping flag added in<br /> commit f9a49aa302a0 ("fs/writeback: skip AS_NO_DATA_INTEGRITY mappings<br /> in wait_sb_inodes()"). The flag belongs at the superblock level because<br /> data integrity is a filesystem-wide property, not a per-inode one.<br /> Having this flag at the superblock level also allows us to skip having<br /> to iterate every dirty inode in wait_sb_inodes() only to skip each inode<br /> individually.<br /> <br /> Prior to this commit, mappings with no data integrity guarantees skipped<br /> waiting on writeback completion but still waited on the flusher threads<br /> to finish initiating the writeback. Waiting on the flusher threads is<br /> unnecessary. This commit kicks off writeback but does not wait on the<br /> flusher threads. This change properly addresses a recent report [1] for<br /> a suspend-to-RAM hang seen on fuse-overlayfs that was caused by waiting<br /> on the flusher threads to finish:<br /> <br /> Workqueue: pm_fs_sync pm_fs_sync_work_fn<br /> Call Trace:<br /> <br /> __schedule+0x457/0x1720<br /> schedule+0x27/0xd0<br /> wb_wait_for_completion+0x97/0xe0<br /> sync_inodes_sb+0xf8/0x2e0<br /> __iterate_supers+0xdc/0x160<br /> ksys_sync+0x43/0xb0<br /> pm_fs_sync_work_fn+0x17/0xa0<br /> process_one_work+0x193/0x350<br /> worker_thread+0x1a1/0x310<br /> kthread+0xfc/0x240<br /> ret_from_fork+0x243/0x280<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> On fuse this is problematic because there are paths that may cause the<br /> flusher thread to block (eg if systemd freezes the user session cgroups<br /> first, which freezes the fuse daemon, before invoking the kernel<br /> suspend. The kernel suspend triggers -&gt;write_node() which on fuse issues<br /> a synchronous setattr request, which cannot be processed since the<br /> daemon is frozen. Or if the daemon is buggy and cannot properly complete<br /> writeback, initiating writeback on a dirty folio already under writeback<br /> leads to writeback_get_folio() -&gt; folio_prepare_writeback() -&gt;<br /> unconditional wait on writeback to finish, which will cause a hang).<br /> This commit restores fuse to its prior behavior before tmp folios were<br /> removed, where sync was essentially a no-op.<br /> <br /> [1] https://lore.kernel.org/linux-fsdevel/CAJnrk1a-asuvfrbKXbEwwDSctvemF+6zfhdnuzO65Pt8HsFSRw@mail.gmail.com/T/#m632c4648e9cafc4239299887109ebd880ac6c5c1

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/huge_memory: fix folio isn&amp;#39;t locked in softleaf_to_folio()<br /> <br /> On arm64 server, we found folio that get from migration entry isn&amp;#39;t locked<br /> in softleaf_to_folio(). This issue triggers when mTHP splitting and<br /> zap_nonpresent_ptes() races, and the root cause is lack of memory barrier<br /> in softleaf_to_folio(). The race is as follows:<br /> <br /> CPU0 CPU1<br /> <br /> deferred_split_scan() zap_nonpresent_ptes()<br /> lock folio<br /> split_folio()<br /> unmap_folio()<br /> change ptes to migration entries<br /> __split_folio_to_order() softleaf_to_folio()<br /> set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry))<br /> smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio))<br /> prep_compound_page() for tail pages<br /> <br /> In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages<br /> are visible before the tail page becomes non-compound. smp_wmb() should<br /> be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a<br /> result, if zap_nonpresent_ptes() accesses migration entry that stores tail<br /> pfn, softleaf_to_folio() may see the updated compound_head of tail page<br /> before page-&gt;flags.<br /> <br /> This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio()<br /> because of the race between folio split and zap_nonpresent_ptes()<br /> leading to a folio incorrectly undergoing modification without a folio<br /> lock being held.<br /> <br /> This is a BUG_ON() before commit 93976a20345b ("mm: eliminate further<br /> swapops predicates"), which in merged in v6.19-rc1.<br /> <br /> To fix it, add missing smp_rmb() if the softleaf entry is migration entry<br /> in softleaf_to_folio() and softleaf_to_page().<br /> <br /> [tujinjiang@huawei.com: update function name and comments]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: add GFP_NOIO in the bio completion if needed<br /> <br /> The bio completion path in the process context (e.g. dm-verity)<br /> will directly call into decompression rather than trigger another<br /> workqueue context for minimal scheduling latencies, which can<br /> then call vm_map_ram() with GFP_KERNEL.<br /> <br /> Due to insufficient memory, vm_map_ram() may generate memory<br /> swapping I/O, which can cause submit_bio_wait to deadlock<br /> in some scenarios.<br /> <br /> Trimmed down the call stack, as follows:<br /> <br /> f2fs_submit_read_io<br /> submit_bio //bio_list is initialized.<br /> mmc_blk_mq_recovery<br /> z_erofs_endio<br /> vm_map_ram<br /> __pte_alloc_kernel<br /> __alloc_pages_direct_reclaim<br /> shrink_folio_list<br /> __swap_writepage<br /> submit_bio_wait //bio_list is non-NULL, hang!!!<br /> <br /> Use memalloc_noio_{save,restore}() to wrap up this path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs: check contexts-&gt;nr in repeat_call_fn<br /> <br /> damon_sysfs_repeat_call_fn() calls damon_sysfs_upd_tuned_intervals(),<br /> damon_sysfs_upd_schemes_stats(), and<br /> damon_sysfs_upd_schemes_effective_quotas() without checking contexts-&gt;nr. <br /> If nr_contexts is set to 0 via sysfs while DAMON is running, these<br /> functions dereference contexts_arr[0] and cause a NULL pointer<br /> dereference. Add the missing check.<br /> <br /> For example, the issue can be reproduced using DAMON sysfs interface and<br /> DAMON user-space tool (damo) [1] like below.<br /> <br /> $ sudo damo start --refresh_interval 1s<br /> $ echo 0 | sudo tee \<br /> /sys/kernel/mm/damon/admin/kdamonds/0/contexts/nr_contexts

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs: check contexts-&gt;nr before accessing contexts_arr[0]<br /> <br /> Multiple sysfs command paths dereference contexts_arr[0] without first<br /> verifying that kdamond-&gt;contexts-&gt;nr == 1. A user can set nr_contexts to<br /> 0 via sysfs while DAMON is running, causing NULL pointer dereferences.<br /> <br /> In more detail, the issue can be triggered by privileged users like<br /> below.<br /> <br /> First, start DAMON and make contexts directory empty<br /> (kdamond-&gt;contexts-&gt;nr == 0).<br /> <br /> # damo start<br /> # cd /sys/kernel/mm/damon/admin/kdamonds/0<br /> # echo 0 &gt; contexts/nr_contexts<br /> <br /> Then, each of below commands will cause the NULL pointer dereference.<br /> <br /> # echo update_schemes_stats &gt; state<br /> # echo update_schemes_tried_regions &gt; state<br /> # echo update_schemes_tried_bytes &gt; state<br /> # echo update_schemes_effective_quotas &gt; state<br /> # echo update_tuned_intervals &gt; state<br /> <br /> Guard all commands (except OFF) at the entry point of<br /> damon_sysfs_handle_cmd().