Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> keys: make keyring key-chunk byte order agree with keyring_diff_objects()<br /> <br /> keyring_get_key_chunk() loads description bytes into the index chunk low<br /> address first, while keyring_diff_objects() numbers the first differing<br /> bit from the low end and folds the absolute byte index into the level<br /> without removing the inline-prefix offset the level already carries.<br /> The two disagree on byte order and bit position, so the array can be<br /> told two keys first differ at a bit that does not differ in the chunk<br /> the walker uses, letting crafted descriptions collide into one node.<br /> <br /> Load the chunk in the order keyring_diff_objects() assumes and drop the<br /> inline-prefix length when folding the byte index into the level. This<br /> only changes the in-memory ordering used to place keys within a keyring;<br /> add, search and read of non-colliding keys are unaffected.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> keys: fix out-of-bounds read in keyring_get_key_chunk()<br /> <br /> For description-level chunks keyring_get_key_chunk() advances the read<br /> pointer by level * sizeof(long) past the inline prefix but only<br /> bounds-checks the prefix, so a long enough key description is read past<br /> its kmemdup(desc, desc_len + 1) allocation. Compute the full byte<br /> offset and bounds-check the description against it before reading.<br /> <br /> The walk only reaches a description-level chunk when two keys collide<br /> through the hash, x, type and domain_tag chunks, so this is reached from<br /> an unprivileged add_key(2) with a crafted pair of same-type keys whose<br /> index hashes collide; KASAN reports a slab-out-of-bounds read.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: vgic: Fix race between LPI release and re-registration<br /> <br /> Fix a potential race between decrementing an LPI&amp;#39;s reference count and<br /> evicting that structure from the LPI xarray.<br /> <br /> LPI structures are maintained in the VGIC LPI xarray (dist-&gt;lpi_xa).<br /> When the reference count of an LPI structure drops to zero,<br /> vgic_release_lpi_locked() removes the structure from the xarray and<br /> frees it under the xarray lock.<br /> <br /> However, the release of an LPI can race with a concurrent LPI<br /> re-registration with the same INTID via vgic_add_lpi() on another CPU,<br /> since the reference count drop and the xarray eviction are not performed<br /> in a single atomic step. This can happen e.g. if the guest issues a<br /> DISCARD while the LPI is still referenced from a vCPU&amp;#39;s active-pending<br /> list (ap_list), and the same INTID is re-mapped via MAPTI.<br /> <br /> Particularly, vgic_release_lpi_locked() is called from two distinct<br /> paths: direct release via vgic_put_irq(), and deferred release via<br /> vgic_release_deleted_lpis(). During direct release, the issue can result<br /> in deleting a newly registered LPI from the xarray:<br /> <br /> CPU0 (Releasing LPI) CPU1 (Adding new LPI)<br /> ==================== =====================<br /> vgic_put_irq()<br /> __vgic_put_irq()<br /> refcount_dec_and_test()<br /> vgic_add_lpi()<br /> xa_lock_irqsave()<br /> old_irq = xa_load(.., intid)<br /> vgic_try_get_irq_ref(old_irq) == false<br /> new IRQ inserted --&gt; __xa_store(.., intid, ..)<br /> xa_unlock_irqrestore()<br /> xa_lock_irqsave();<br /> vgic_release_lpi_locked()<br /> __xa_erase(.., irq-&gt;intid) pending_release = true<br /> vgic_add_lpi()<br /> xa_lock_irqsave()<br /> old_irq = xa_load(.., intid)<br /> vgic_try_get_irq_ref(oldirq) == false<br /> BUG: old IRQ overwritten --&gt; __xa_store(.., intid, ..)<br /> xa_unlock_irqrestore()<br /> <br /> vgic_release_deleted_lpis()<br /> xa_lock_irqsave()<br /> xa_for_each() { .. }

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack_sip: widen NAT rewrite delta to s32 in sip_help_tcp()<br /> <br /> sip_help_tcp() stores the size change of each NAT-rewritten SIP message<br /> in s16 diff and accumulates it in s16 tdiff, but a single message can<br /> grow by more than S16_MAX while the packet stays under the 65535<br /> enlarge_skb() limit: nf_nat_sip() rewrites every matching URI, and a long<br /> Contact list expands the message by tens of kilobytes. diff then wraps,<br /> and "datalen = datalen + diff - msglen" yields a huge unsigned datalen,<br /> so the next iteration&amp;#39;s ct_sip_get_header() reads past the linearized skb<br /> tail.<br /> <br /> Widen diff, tdiff and the seq_adjust hook to s32. Both are bounded by the<br /> 65535 byte packet limit, and the seqadj core is already s32<br /> (nf_ct_seqadj_set() takes s32), so no previously accepted input is<br /> rejected.<br /> <br /> BUG: KASAN: use-after-free in ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464)<br /> Read of size 1 at addr ffff888010800000 by task ksoftirqd/1/25<br /> ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464)<br /> sip_help_tcp (net/netfilter/nf_conntrack_sip.c:1694)<br /> nf_confirm (net/netfilter/nf_conntrack_proto.c:183)<br /> nf_hook_slow (net/netfilter/core.c:619)<br /> ip6_output (net/ipv6/ip6_output.c:246)<br /> ip6_forward (net/ipv6/ip6_output.c:690)<br /> ipv6_rcv (net/ipv6/ip6_input.c:351)<br /> __netif_receive_skb_one_core (net/core/dev.c:6212)<br /> process_backlog (net/core/dev.c:6676)<br /> __napi_poll (net/core/dev.c:7735)<br /> net_rx_action (net/core/dev.c:7955)<br /> handle_softirqs (kernel/softirq.c:622)<br /> run_ksoftirqd (kernel/softirq.c:1076)<br /> ...

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs: harden runlist realloc size calculations<br /> <br /> Add a shared helper to safely convert runlist element counts to byte sizes<br /> using overflow checks, and use it in both ntfs_rl_realloc() and<br /> ntfs_rl_realloc_nofail().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: skip global block reserve accounting for rescue mounts<br /> <br /> [BUG]<br /> Mounting with rescue=ibadroots after corrupting the block group tree<br /> root triggers a NULL pointer dereference:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000100<br /> RIP: 0010:btrfs_update_global_block_rsv+0x9d/0x1c0 [btrfs]<br /> Call Trace:<br /> fill_dummy_bgs+0xd4/0x120 [btrfs]<br /> open_ctree+0xc6e/0x1ca0 [btrfs]<br /> btrfs_get_tree+0x50d/0xa40 [btrfs]<br /> <br /> The same crash occurs with a corrupted raid stripe tree root, via<br /> btrfs_read_block_groups() instead of fill_dummy_bgs().<br /> <br /> [CAUSE]<br /> With rescue=ibadroots, btrfs_read_roots() allows the mount to continue<br /> when either root cannot be read, leaving the corresponding root pointer<br /> NULL while its on-disk feature bit remains set.<br /> <br /> btrfs_update_global_block_rsv() then dereferences the missing root based<br /> on the feature bit alone.<br /> <br /> [FIX]<br /> Rescue mounts are fully read-only and cannot start transactions, so the<br /> global reserve is never consumed. Under btrfs_is_full_ro(), mark the<br /> reserve as full and return before performing the accounting.<br /> <br /> And since we need to check if the fs is mount fully RO, export<br /> fs_is_full_ro() as btrfs_is_full_ro(), and move it to fs.h.<br /> <br /> [ Squash the fs_is_full_ro() export commit into this one. ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zoned: fix deadlock between metadata writeback and transaction commit<br /> <br /> When writing out metadata extent buffers in a zoned filesystem,<br /> btree_writepages() holds fs_info-&gt;zoned_meta_io_lock across the whole<br /> writeback loop, including the call to btrfs_check_meta_write_pointer() -&gt;<br /> check_bg_is_active().<br /> <br /> For the tree-log block group, check_bg_is_active() may fail to activate<br /> the zone and fall back to btrfs_zone_finish_one_bg() to free an active<br /> zone. That path waits for the running transaction to commit while still<br /> holding zoned_meta_io_lock, but the committer needs that same lock to<br /> write out the tree extents, so the two tasks deadlock:<br /> <br /> Task A (kworker, metadata writeback) Task B (fsstress, transaction commit)<br /> ------------------------------------ -------------------------------------<br /> wb_workfn() btrfs_commit_transaction(T)<br /> btree_writepages() btrfs_write_and_wait_transaction()<br /> btrfs_zoned_meta_io_lock() btrfs_write_marked_extents()<br /> btrfs_check_meta_write_pointer() btree_writepages()<br /> check_bg_is_active() [treelog_bg] btrfs_zoned_meta_io_lock()<br /> btrfs_zone_finish_one_bg() <br /> do_zone_finish()<br /> btrfs_inc_block_group_ro()<br /> btrfs_wait_for_commit()<br /> <br /> <br /> The sibling branch in check_bg_is_active() already drops zoned_meta_io_lock<br /> around do_zone_finish() for this exact reason. Do the same in the tree-log<br /> branch: release the lock around btrfs_zone_finish_one_bg() and re-acquire<br /> it afterwards. The lock only protects fs_info-&gt;active_{meta,system}_bg,<br /> which this branch does not touch, and ctx-&gt;zoned_bg keeps a reference to<br /> the block group across the unlock, so nothing is lost while the lock<br /> is dropped.<br /> <br /> This hang occasionally reproduces with fstests generic/475 on a zoned<br /> btrfs filesystem.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/arm-smmu-v3-iommufd: Require exactly one Stream ID for a vDEVICE<br /> <br /> arm_vsmmu_vsid_to_sid() maps a guest&amp;#39;s vSID to a single physical Stream ID<br /> taken from master-&gt;streams[0], assuming a device has exactly one stream. A<br /> device with several streams gets only its first one mapped, so a guest vSID<br /> invalidation cannot reach the others&amp;#39; ATC and IOTLB entries; a device with<br /> none makes master-&gt;streams a ZERO_SIZE_PTR, read out of bounds.<br /> <br /> Add an arm_vsmmu_vdevice_init() op to reject the vDEVICE with -EOPNOTSUPP<br /> when master-&gt;num_streams is not one, rather than mapping it silently.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection buffer<br /> <br /> iscsi_tcp_hdr_dissect() receives the data segment of several PDU types<br /> into the fixed-size conn-&gt;data buffer, which is allocated for<br /> ISCSI_DEF_MAX_RECV_SEG_LEN (8192) bytes. For the LOGIN_RSP, TEXT_RSP,<br /> REJECT and ASYNC_EVENT opcodes the dissect path already rejects a PDU<br /> whose DataSegmentLength exceeds that buffer.<br /> <br /> The SCSI Command Response (ISCSI_OP_SCSI_CMD_RSP) path also copies its<br /> data segment (sense/response data) into conn-&gt;data via<br /> iscsi_tcp_data_recv_prep(), but it does so without the same check. The<br /> only upstream bound on in.datalen is conn-&gt;max_recv_dlength, the<br /> initiator&amp;#39;s advertised MaxRecvDataSegmentLength, which is commonly<br /> negotiated well above 8192 (open-iscsi defaults to 262144). A target<br /> that returns a SCSI Response with a DataSegmentLength between 8193 and<br /> max_recv_dlength therefore overflows the 8192-byte conn-&gt;data buffer.<br /> <br /> Once the same bound applies, ISCSI_OP_SCSI_CMD_RSP is handled exactly<br /> like those responses: bound the data segment, receive it into conn-&gt;data<br /> when present, and otherwise complete the PDU with no data. Fold the<br /> opcode into that case group rather than duplicating the check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer<br /> <br /> iscsi_scsi_cmd_rsp() copies the sense data of a SCSI Response from the<br /> target-supplied data segment. The segment carries a 2-byte sense length<br /> followed by the sense bytes, so it must hold 2 + senselen bytes, but the<br /> bounds check only requires datalen &gt;= senselen:<br /> <br /> senselen = get_unaligned_be16(data);<br /> if (datalen sense_buffer, data + 2,<br /> min_t(uint16_t, senselen, SCSI_SENSE_BUFFERSIZE));<br /> <br /> A target that returns a SCSI Response whose datalen equals senselen<br /> (with senselen data contents and end up in the command&amp;#39;s sense buffer, which is<br /> returned to userspace.<br /> <br /> Account for the 2-byte sense length prefix in the check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: reclaim invalid Tx descriptors in ZC batch path<br /> <br /> The zero-copy Tx batch parser stops when it encounters an invalid<br /> descriptor. If this happens after one or more continuation descriptors,<br /> the Tx consumer can be advanced past fragments that are neither submitted<br /> to the driver nor returned to userspace through the completion ring.<br /> <br /> A similar problem occurs when a packet exceeds xdp_zc_max_segs. The<br /> descriptors consumed up to the limit are released without completion, and<br /> the remaining continuation descriptors can subsequently be interpreted<br /> as the beginning of another packet.<br /> <br /> Parse Tx batches in packet units and distinguish descriptors belonging to<br /> complete valid packets from descriptors consumed while draining an<br /> invalid or oversized packet. Return the former to the driver and append<br /> the latter to the CQ address area so userspace can reclaim their UMEM<br /> frames.<br /> <br /> Treat a standalone invalid descriptor as a one-descriptor reclaim-only<br /> packet. Advancing the Tx-ring consumer releases the ring slot, but does<br /> not by itself return ownership of the referenced UMEM frame to userspace.<br /> <br /> Once draining starts, continue until the packet&amp;#39;s end-of-packet<br /> descriptor is consumed. Preserve the drain state on the socket when EOP<br /> has not yet been supplied, so draining can continue during a later call.<br /> Leave incomplete but otherwise valid packets on the Tx ring.<br /> <br /> Shared-UMEM pools using multi-buffer Tx also need packet-framed parsing.<br /> Walk their Tx sockets one packet at a time, preserving the existing<br /> per-socket fairness scheme, instead of using the legacy one-descriptor<br /> fallback. Keep that fallback for shared pools that do not use<br /> multi-buffer Tx. Since the drain state is maintained per socket and both<br /> the singular and shared paths can resume an interrupted drain, changing<br /> the socket list from singular to shared requires no special bind-time<br /> transition.<br /> <br /> CQ entries are positional, and drivers may complete only part of the Tx<br /> work returned by xsk_tx_peek_release_desc_batch(). Therefore, reclaim-only<br /> entries cannot be published immediately when earlier driver-visible<br /> descriptors are still outstanding.<br /> <br /> Track the number of driver-visible CQ entries preceding the reclaim<br /> entries. Let xsk_tx_completed() publish partial hardware Tx completions,<br /> and publish the reclaim entries only after every earlier Tx descriptor<br /> has completed. Complete a reclaim-only batch immediately when there is no<br /> driver-visible work in front of it, and prevent another Tx batch from<br /> being appended while reclaim entries remain pending.<br /> <br /> Also cap batch processing by the size of the pool&amp;#39;s temporary descriptor<br /> array, as Tx rings belonging to sockets sharing a UMEM may have different<br /> sizes.<br /> <br /> This ensures that every invalid Tx descriptor consumed by the ZC batch<br /> path is either submitted to the driver as part of a valid packet or<br /> returned to userspace without violating CQ completion ordering.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: drain continuation descs after overflow in xsk_build_skb()<br /> <br /> Fix generic xmit path multi-buffer logic when packets are either too big<br /> (count of descriptors exceed MAX_SKB_FRAGS) or an invalid descriptor is<br /> included in fragmented packet. Introduce xdp_sock::drain_cont and act<br /> upon this flag - when it is set, keep on consuming descriptors from<br /> AF_XDP Tx ring and put them directly onto Cq. Previously these<br /> descriptors were silently lost and could never be reached again.