Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: cleanup remaining SKBs in PTP flows<br /> <br /> When the driver requests Tx timestamp value, one of the first steps is<br /> to clone SKB using skb_get. It increases the reference counter for that<br /> SKB to prevent unexpected freeing by another component.<br /> However, there may be a case where the index is requested, SKB is<br /> assigned and never consumed by PTP flows - for example due to reset during<br /> running PTP apps.<br /> <br /> Add a check in release timestamping function to verify if the SKB<br /> assigned to Tx timestamp latch was freed, and release remaining SKBs.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tls: wait for pending async decryptions if tls_strp_msg_hold fails<br /> <br /> Async decryption calls tls_strp_msg_hold to create a clone of the<br /> input skb to hold references to the memory it uses. If we fail to<br /> allocate that clone, proceeding with async decryption can lead to<br /> various issues (UAF on the skb, writing into userspace memory after<br /> the recv() call has returned).<br /> <br /> In this case, wait for all pending decryption requests.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/qaic: Fix bootlog initialization ordering<br /> <br /> As soon as we queue MHI buffers to receive the bootlog from the device,<br /> we could be receiving data. Therefore all the resources needed to<br /> process that data need to be setup prior to queuing the buffers.<br /> <br /> We currently initialize some of the resources after queuing the buffers<br /> which creates a race between the probe() and any data that comes back<br /> from the device. If the uninitialized resources are accessed, we could<br /> see page faults.<br /> <br /> Fix the init ordering to close the race.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: detect invalid INLINE_DATA + EXTENTS flag combination<br /> <br /> syzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verity<br /> file on a corrupted ext4 filesystem mounted without a journal.<br /> <br /> The issue is that the filesystem has an inode with both the INLINE_DATA<br /> and EXTENTS flags set:<br /> <br /> EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15:<br /> comm syz.0.17: corrupted extent tree: lblk 0

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match().<br /> <br /> smc_clc_prfx_match() is called from smc_listen_work() and<br /> not under RCU nor RTNL.<br /> <br /> Using sk_dst_get(sk)-&gt;dev could trigger UAF.<br /> <br /> Let&amp;#39;s use __sk_dst_get() and dst_dev_rcu().<br /> <br /> Note that the returned value of smc_clc_prfx_match() is not<br /> used in the caller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Reject negative offsets for ALU ops<br /> <br /> When verifying BPF programs, the check_alu_op() function validates<br /> instructions with ALU operations. The &amp;#39;offset&amp;#39; field in these<br /> instructions is a signed 16-bit integer.<br /> <br /> The existing check &amp;#39;insn-&gt;off &gt; 1&amp;#39; was intended to ensure the offset is<br /> either 0, or 1 for BPF_MOD/BPF_DIV. However, because &amp;#39;insn-&gt;off&amp;#39; is<br /> signed, this check incorrectly accepts all negative values (e.g., -1).<br /> <br /> This commit tightens the validation by changing the condition to<br /> &amp;#39;(insn-&gt;off != 0 &amp;&amp; insn-&gt;off != 1)&amp;#39;. This ensures that any value<br /> other than the explicitly permitted 0 and 1 is rejected, hardening the<br /> verifier against malformed BPF programs.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: use dst_dev_rcu() in sk_setup_caps()<br /> <br /> Use RCU to protect accesses to dst-&gt;dev from sk_setup_caps()<br /> and sk_dst_gso_max_size().<br /> <br /> Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),<br /> and ip_dst_mtu_maybe_forward().<br /> <br /> ip4_dst_hoplimit() can use dst_dev_net_rcu().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-fc: move lsop put work to nvmet_fc_ls_req_op<br /> <br /> It’s possible for more than one async command to be in flight from<br /> __nvmet_fc_send_ls_req. For each command, a tgtport reference is taken.<br /> <br /> In the current code, only one put work item is queued at a time, which<br /> results in a leaked reference.<br /> <br /> To fix this, move the work item to the nvmet_fc_ls_req_op struct, which<br /> already tracks all resources related to the command.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages()<br /> <br /> Currently, if find_and_map_user_pages() takes a DMA xfer request from the<br /> user with a length field set to 0, or in a rare case, the host receives<br /> QAIC_TRANS_DMA_XFER_CONT from the device where resources-&gt;xferred_dma_size<br /> is equal to the requested transaction size, the function will return 0<br /> before allocating an sgt or setting the fields of the dma_xfer struct.<br /> In that case, encode_addr_size_pairs() will try to access the sgt which<br /> will lead to a general protection fault.<br /> <br /> Return an EINVAL in case the user provides a zero-sized ALP, or the device<br /> requests continuation after all of the bytes have been transferred.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/ip6_tunnel: Prevent perpetual tunnel growth<br /> <br /> Similarly to ipv4 tunnel, ipv6 version updates dev-&gt;needed_headroom, too.<br /> While ipv4 tunnel headroom adjustment growth was limited in<br /> commit 5ae1e9922bbd ("net: ip_tunnel: prevent perpetual headroom growth"),<br /> ipv6 tunnel yet increases the headroom without any ceiling.<br /> <br /> Reflect ipv4 tunnel headroom adjustment limit on ipv6 version.<br /> <br /> Credits to Francesco Ruggeri, who was originally debugging this issue<br /> and wrote local Arista-specific patch and a reproducer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm: Fix SMP ordering in switch_mm_irqs_off()<br /> <br /> Stephen noted that it is possible to not have an smp_mb() between<br /> the loaded_mm store and the tlb_gen load in switch_mm(), meaning the<br /> ordering against flush_tlb_mm_range() goes out the window, and it<br /> becomes possible for switch_mm() to not observe a recent tlb_gen<br /> update and fail to flush the TLBs.<br /> <br /> [ dhansen: merge conflict fixed by Ingo ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: Harden userspace-supplied xdp_desc validation<br /> <br /> Turned out certain clearly invalid values passed in xdp_desc from<br /> userspace can pass xp_{,un}aligned_validate_desc() and then lead<br /> to UBs or just invalid frames to be queued for xmit.<br /> <br /> desc-&gt;len close to ``U32_MAX`` with a non-zero pool-&gt;tx_metadata_len<br /> can cause positive integer overflow and wraparound, the same way low<br /> enough desc-&gt;addr with a non-zero pool-&gt;tx_metadata_len can cause<br /> negative integer overflow. Both scenarios can then pass the<br /> validation successfully.<br /> This doesn&amp;#39;t happen with valid XSk applications, but can be used<br /> to perform attacks.<br /> <br /> Always promote desc-&gt;len to ``u64`` first to exclude positive<br /> overflows of it. Use explicit check_{add,sub}_overflow() when<br /> validating desc-&gt;addr (which is ``u64`` already).<br /> <br /> bloat-o-meter reports a little growth of the code size:<br /> <br /> add/remove: 0/0 grow/shrink: 2/1 up/down: 60/-16 (44)<br /> Function old new delta<br /> xskq_cons_peek_desc 299 330 +31<br /> xsk_tx_peek_release_desc_batch 973 1002 +29<br /> xsk_generic_xmit 3148 3132 -16<br /> <br /> but hopefully this doesn&amp;#39;t hurt the performance much.