Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: lwtunnel: Drop skb metadata before LWT encapsulation<br /> <br /> skb metadata is meant for passing information between XDP and TC. It lives<br /> in the skb headroom, immediately before skb-&gt;data. LWT programs cannot<br /> access the __sk_buff-&gt;data_meta pseudo-pointer to metadata.<br /> <br /> However, LWT encapsulation prepends outer headers, moving skb-&gt;data back<br /> over the headroom where the metadata sits. On an RX-originated (forwarded)<br /> packet that still carries XDP metadata this goes wrong in two different<br /> ways, depending on the encap type:<br /> <br /> 1. Non-BPF LWT encaps (mpls, seg6, ioam6 ...) call skb_push()/skb_pull()<br /> and silently overwrite the metadata that sits in the headroom.<br /> <br /> 2) BPF LWT xmit calls bpf_skb_change_head(), which uses skb_data_move().<br /> That helper expects metadata immediately before skb-&gt;data. But since<br /> the IP output path runs LWT xmit before neighbour output has built<br /> the outgoing L2 header, for forwarded packets skb-&gt;data points at the<br /> L3 header while skb_mac_header() still points at the old L2 header.<br /> skb_data_move() sees metadata ending at skb_mac_header(), not before<br /> skb-&gt;data, warns and clears metadata:<br /> <br /> WARNING: CPU: 21 PID: 454557 at include/linux/skbuff.h:4609 skb_data_move+0x47/0x90<br /> CPU: 21 UID: 0 PID: 454557 Comm: napi/iconduit-g Tainted: G O 6.18.21 #1<br /> RIP: 0010:skb_data_move+0x47/0x90<br /> Call Trace:<br /> <br /> bpf_skb_change_head+0xe6/0x1a0<br /> bpf_prog_...+0x213/0x2e3<br /> run_lwt_bpf.isra.0+0x1d3/0x360<br /> bpf_xmit+0x46/0xe0<br /> lwtunnel_xmit+0xa1/0xf0<br /> ip_finish_output2+0x1e7/0x5e0<br /> ip_output+0x63/0x100<br /> __netif_receive_skb_one_core+0x85/0xa0<br /> process_backlog+0x9c/0x150<br /> __napi_poll+0x2b/0x190<br /> net_rx_action+0x40b/0x7f0<br /> handle_softirqs+0xd2/0x270<br /> do_softirq+0x3f/0x60<br /> <br /> <br /> That is what happens, as for how to fix it - a received packet that<br /> carries metadata can reach an encap through any of the three LWT<br /> redirect modes:<br /> <br /> LWTUNNEL_STATE_INPUT_REDIRECT<br /> ip6_rcv_finish<br /> dst_input<br /> lwtunnel_input<br /> <br /> LWTUNNEL_STATE_OUTPUT_REDIRECT<br /> ip6_rcv_finish<br /> dst_input<br /> ip6_forward<br /> ip6_forward_finish<br /> dst_output<br /> lwtunnel_output<br /> <br /> LWTUNNEL_STATE_XMIT_REDIRECT<br /> ip6_rcv_finish<br /> dst_input<br /> ip6_forward<br /> ip6_forward_finish<br /> dst_output<br /> ip6_output<br /> ip6_finish_output<br /> ip6_finish_output2<br /> lwtunnel_xmit<br /> <br /> Every encap funnels through the three LWT dispatch helpers, so drop the<br /> metadata there, right before handing the skb to the encap op. This<br /> single chokepoint covers all encap types and all three redirect modes:<br /> <br /> - lwtunnel_input(): seg6, rpl, ila, seg6_local<br /> - lwtunnel_output(): ioam6<br /> - lwtunnel_xmit(): mpls, LWT BPF xmit<br /> <br /> Alternatively, we could clear the metadata right after TC ingress hook.<br /> That would require a compromise, however. Metadata would become<br /> inaccessible from TC egress (in setups where it actually reaches the<br /> hook it tact, that is without any L2 tunnels on path).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> veth: fix NAPI leak in XDP enable error path<br /> <br /> During XDP enablement in veth, if xdp_rxq_info_reg() or<br /> xdp_rxq_info_reg_mem_model() fails, the driver rolls back the changes.<br /> <br /> However, the rollback loop:<br /> for (i--; i &gt;= start; i--) {<br /> <br /> decrements the loop index &amp;#39;i&amp;#39; before the first iteration. This<br /> correctly skips unregistering the rxq for the failed index &amp;#39;i&amp;#39; (as<br /> registration failed or was already cleaned up), but it also<br /> erroneously skips calling netif_napi_deli() for rq[i].xdp_napi.<br /> <br /> Since netif_napi_add() was already called for index &amp;#39;i&amp;#39;, this leaves<br /> a dangling napi_struct in the device&amp;#39;s napi_list. When the veth<br /> device is later destroyed, the freed queue memory (which contains the<br /> leaked NAPI structure) can be reused.<br /> <br /> The subsequent device teardown iterates the NAPI list and<br /> corrupts the reallocated memory, leading to UAF.<br /> <br /> Fix this by explicitly deleting the NAPI association for the failed<br /> index &amp;#39;i&amp;#39; before rolling back the successfully configured queues.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: emac: Fix NULL pointer dereference in emac_probe<br /> <br /> Move devm_request_irq() after devm_platform_ioremap_resource() so that<br /> dev-&gt;emacp is mapped before the interrupt handler can fire. An early<br /> interrupt hitting emac_irq() would dereference the NULL dev-&gt;emacp and<br /> crash.<br /> <br /> Also remove redundant error message. devm_platform_ioremap_resource()<br /> already returns an error message with dev_err_probe().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dst_metadata: fix false-positive memcpy overflow in tun_dst_unclone<br /> <br /> kmalloc_flex() in metadata_dst_alloc() sets __counted_by for the<br /> structure to the options_len, which is then initialized to zero.<br /> Later, we&amp;#39;re initializing the structure by copying the tunnel info<br /> together with the options, and this triggers a warning for a potential<br /> memcpy overflow, since the compiler estimates that the options can&amp;#39;t<br /> fit into the structure, even though the memory for them is actually<br /> allocated.<br /> <br /> memcpy: detected buffer overflow: 104 byte write of buffer size 96<br /> WARNING: CPU: X PID: Y at lib/string_helpers.c:1036 __fortify_report<br /> skb_tunnel_info_unclone+0x179/0x190<br /> geneve_xmit+0x7fe/0xe00<br /> <br /> The issue is triggered when built with clang and source fortification.<br /> <br /> Fix that by doing the copy in two stages: first - the main data with<br /> the options_len, then the options. This way the correct length should<br /> be known at the time of the copy.<br /> <br /> It would be better if the options_len never changed after allocation,<br /> but the allocation code is a little separate from the initialization<br /> and it would be awkward and potentially dangerous to return a struct<br /> with options_len set to a non-zero value from the metadata_dst_alloc().<br /> <br /> Another option would be to use ip_tunnel_info_opts_set(), but it is<br /> doing too many unnecessary operations for the use case here.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ieee802154: Avoid calling WARN_ON() on -ENOMEM in cfg802154_switch_netns()<br /> <br /> It&amp;#39;s pointless to call WARN_ON() in case of an allocation failure in<br /> dev_change_net_namespace() and device_rename(), since it only leads to<br /> useless splats caused by deliberate fault injections, so avoid it.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: airoha: fix foe_check_time allocation size<br /> <br /> foe_check_time is declared as u16 pointer but was allocated with<br /> only ppe_num_entries bytes instead of ppe_num_entries * sizeof(u16).<br /> <br /> When airoha_ppe_foe_verify_entry() is called with hash &gt;= ppe_num_entries/2,<br /> it writes beyond the allocated buffer, causing heap buffer overflow and<br /> potential kernel crash.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free<br /> <br /> amdgpu_amdkfd_gpuvm_free_memory_of_gpu() unpinned DOORBELL and MMIO<br /> remap BOs (which are pinned at allocation time) before checking whether<br /> the BO is still mapped to the GPU. When the BO is still mapped, the<br /> function returns -EBUSY and leaves the BO alive, but it has already<br /> been unpinned. The BO is then unpinned again when it is finally freed<br /> during process teardown, triggering a ttm_bo_unpin() underflow warning:<br /> <br /> WARNING: CPU: 18 PID: 15066 at ttm/ttm_bo.c:650 amdttm_bo_unpin+0x6d/0x80 [amdttm]<br /> Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu]<br /> RIP: 0010:amdttm_bo_unpin+0x6d/0x80 [amdttm]<br /> Call Trace:<br /> amdgpu_bo_unpin+0x1a/0x90 [amdgpu]<br /> amdgpu_amdkfd_gpuvm_unpin_bo+0x31/0xb0 [amdgpu]<br /> amdgpu_amdkfd_gpuvm_free_memory_of_gpu+0x3bf/0x460 [amdgpu]<br /> kfd_process_free_outstanding_kfd_bos+0xd4/0x170 [amdgpu]<br /> kfd_process_wq_release+0x109/0x1b0 [amdgpu]<br /> process_one_work+0x1e2/0x3b0<br /> worker_thread+0x50/0x3a0<br /> kthread+0xdd/0x100<br /> ret_from_fork+0x29/0x50<br /> <br /> Move the unpin after the mapped_to_gpu_memory check so it only happens<br /> once we are committed to freeing the BO.<br /> <br /> (cherry picked from commit 927c5b2defb9b09856444d94bebfd056a002bd75)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: fix potential UAF in aa_replace_profiles<br /> <br /> The function aa_replace_profiles was accessing udata-&gt;size after calling<br /> aa_put_loaddata(udata), causing a potential UAF.<br /> <br /> Fixed this by saving the size to a local variable before dropping the<br /> reference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/amd/lbr: Fix kernel address leakage<br /> <br /> A user-only branch stack can contain branches that originate from<br /> the kernel. As a result, kernel addresses are exposed to user space<br /> even when PERF_SAMPLE_BRANCH_USER is requested. On AMD processors<br /> supporting X86_FEATURE_AMD_LBR_V2, perf can still report SYSRET/ERET<br /> entries for which the branch-from addresses are in the kernel.<br /> <br /> E.g.<br /> <br /> $ perf record -e cycles -o - -j any,save_type,u -- \<br /> perf bench syscall basic --loop 1000 | \<br /> perf script -i - -F brstack|tr &amp;#39; &amp;#39; &amp;#39;\n&amp;#39;| \<br /> grep -E &amp;#39;0x[89a-f][0-9a-f]{15}&amp;#39;<br /> <br /> ...<br /> 0xffffffff81001268/0x717a90a38f1a/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH<br /> 0xffffffff81001268/0x717a90a39157/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH<br /> 0xffffffff81001268/0x717a90a2c628/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH<br /> 0xffffffff81001268/0x717a90a41b60/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH<br /> 0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH<br /> 0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH<br /> 0xffffffff81001268/0x717a8bef1c30/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH<br /> 0xffffffff81001268/0x717a8e4d3c90/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH<br /> ...<br /> <br /> The reason is that the hardware filter only considers the privilege<br /> level applicable to the branch target. Extend software filtering to<br /> also validate the branch-from addresses against br_sel, so that any<br /> branch record whose branch-from address is in the kernel is dropped<br /> when PERF_SAMPLE_BRANCH_USER is requested.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack_irc: fix parse_dcc() off-by-one OOB read<br /> <br /> parse_dcc() treats data_end as an inclusive end pointer, but its only<br /> caller passes data_limit = ib_ptr + datalen, which points one past the<br /> last valid byte.<br /> <br /> The newline search loop iterates while tmp

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: core: Fix OOB read in hid_get_report for numbered reports<br /> <br /> When a caller passes a size of 0 to hid_report_raw_event() for a<br /> numbered report, the function originally called hid_get_report() before<br /> performing any size validation.<br /> <br /> Inside hid_get_report(), if the report is numbered (report_enum-&gt;numbered<br /> is true), it unconditionally dereferences data[0] to extract the report ID.<br /> With a size of 0, this results in an out-of-bounds read or kernel panic.<br /> <br /> Fix this by moving the numbered report size validation check before the<br /> call to hid_get_report(), ensuring that size is at least 1 before<br /> dereferencing the data pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: picolcd: prevent NULL pointer dereference in picolcd_send_and_wait()<br /> <br /> In picolcd_send_and_wait(), an integer overflow of the signed loop counter<br /> &amp;#39;k&amp;#39; can theoretically lead to a NULL pointer dereference of &amp;#39;raw_data&amp;#39;.<br /> If the loop executes more than INT_MAX times, &amp;#39;k&amp;#39; becomes negative,<br /> making the condition &amp;#39;k