Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "ipmi: fix msg stack when IPMI is disconnected"<br /> <br /> This reverts commit c608966f3f9c2dca596967501d00753282b395fc.<br /> <br /> This patch has a subtle bug that can cause the IPMI driver to go into an<br /> infinite loop if the BMC misbehaves in a certain way. Apparently<br /> certain BMCs do misbehave this way because several reports have come in<br /> recently about this.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xtensa: simdisk: add input size check in proc_write_simdisk<br /> <br /> A malicious user could pass an arbitrarily bad value<br /> to memdup_user_nul(), potentially causing kernel crash.<br /> <br /> This follows the same pattern as commit ee76746387f6<br /> ("netdevsim: prevent bad user input in nsim_dev_health_break_write()")

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request()<br /> <br /> The cpufreq_cpu_put() call in update_qos_request() takes place too early<br /> because the latter subsequently calls freq_qos_update_request() that<br /> indirectly accesses the policy object in question through the QoS request<br /> object passed to it.<br /> <br /> Fortunately, update_qos_request() is called under intel_pstate_driver_lock,<br /> so this issue does not matter for changing the intel_pstate operation<br /> mode, but it theoretically can cause a crash to occur on CPU device hot<br /> removal (which currently can only happen in virt, but it is formally<br /> supported nevertheless).<br /> <br /> Address this issue by modifying update_qos_request() to drop the<br /> reference to the policy later.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mount: handle NULL values in mnt_ns_release()<br /> <br /> When calling in listmount() mnt_ns_release() may be passed a NULL<br /> pointer. Handle that case gracefully.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()<br /> <br /> Unlike other strings in the ext4 superblock, we rely on tune2fs to<br /> make sure s_mount_opts is NUL terminated. Harden<br /> parse_apply_sb_mount_options() by treating s_mount_opts as a potential<br /> __nonstring.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6}<br /> <br /> Cilium has a BPF egress gateway feature which forces outgoing K8s Pod<br /> traffic to pass through dedicated egress gateways which then SNAT the<br /> traffic in order to interact with stable IPs outside the cluster.<br /> <br /> The traffic is directed to the gateway via vxlan tunnel in collect md<br /> mode. A recent BPF change utilized the bpf_redirect_neigh() helper to<br /> forward packets after the arrival and decap on vxlan, which turned out<br /> over time that the kmalloc-256 slab usage in kernel was ever-increasing.<br /> <br /> The issue was that vxlan allocates the metadata_dst object and attaches<br /> it through a fake dst entry to the skb. The latter was never released<br /> though given bpf_redirect_neigh() was merely setting the new dst entry<br /> via skb_dst_set() without dropping an existing one first.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Fix debug checking for np-guests using huge mappings<br /> <br /> When running with transparent huge pages and CONFIG_NVHE_EL2_DEBUG then<br /> the debug checking in assert_host_shared_guest() fails on the launch of an<br /> np-guest. This WARN_ON() causes a panic and generates the stack below.<br /> <br /> In __pkvm_host_relax_perms_guest() the debug checking assumes the mapping<br /> is a single page but it may be a block map. Update the checking so that<br /> the size is not checked and just assumes the correct size.<br /> <br /> While we&amp;#39;re here make the same fix in __pkvm_host_mkyoung_guest().<br /> <br /> Info: # lkvm run -k /share/arch/arm64/boot/Image -m 704 -c 8 --name guest-128<br /> Info: Removed ghost socket file "/.lkvm//guest-128.sock".<br /> [ 1406.521757] kvm [141]: nVHE hyp BUG at: arch/arm64/kvm/hyp/nvhe/mem_protect.c:1088!<br /> [ 1406.521804] kvm [141]: nVHE call trace:<br /> [ 1406.521828] kvm [141]: [] __kvm_nvhe_hyp_panic+0xb4/0xe8<br /> [ 1406.521946] kvm [141]: [] __kvm_nvhe_assert_host_shared_guest+0xb0/0x10c<br /> [ 1406.522049] kvm [141]: [] __kvm_nvhe___pkvm_host_relax_perms_guest+0x48/0x104<br /> [ 1406.522157] kvm [141]: [] __kvm_nvhe_handle___pkvm_host_relax_perms_guest+0x64/0x7c<br /> [ 1406.522250] kvm [141]: [] __kvm_nvhe_handle_trap+0x8c/0x1a8<br /> [ 1406.522333] kvm [141]: [] __kvm_nvhe___skip_pauth_save+0x4/0x4<br /> [ 1406.522454] kvm [141]: ---[ end nVHE call trace ]---<br /> [ 1406.522477] kvm [141]: Hyp Offset: 0xfffece8013600000<br /> [ 1406.522554] Kernel panic - not syncing: HYP panic:<br /> [ 1406.522554] PS:834003c9 PC:0000b1806db6d170 ESR:00000000f2000800<br /> [ 1406.522554] FAR:ffff8000804be420 HPFAR:0000000000804be0 PAR:0000000000000000<br /> [ 1406.522554] VCPU:0000000000000000<br /> [ 1406.523337] CPU: 3 UID: 0 PID: 141 Comm: kvm-vcpu-0 Not tainted 6.16.0-rc7 #97 PREEMPT<br /> [ 1406.523485] Hardware name: FVP Base RevC (DT)<br /> [ 1406.523566] Call trace:<br /> [ 1406.523629] show_stack+0x18/0x24 (C)<br /> [ 1406.523753] dump_stack_lvl+0xd4/0x108<br /> [ 1406.523899] dump_stack+0x18/0x24<br /> [ 1406.524040] panic+0x3d8/0x448<br /> [ 1406.524184] nvhe_hyp_panic_handler+0x10c/0x23c<br /> [ 1406.524325] kvm_handle_guest_abort+0x68c/0x109c<br /> [ 1406.524500] handle_exit+0x60/0x17c<br /> [ 1406.524630] kvm_arch_vcpu_ioctl_run+0x2e0/0x8c0<br /> [ 1406.524794] kvm_vcpu_ioctl+0x1a8/0x9cc<br /> [ 1406.524919] __arm64_sys_ioctl+0xac/0x104<br /> [ 1406.525067] invoke_syscall+0x48/0x10c<br /> [ 1406.525189] el0_svc_common.constprop.0+0x40/0xe0<br /> [ 1406.525322] do_el0_svc+0x1c/0x28<br /> [ 1406.525441] el0_svc+0x38/0x120<br /> [ 1406.525588] el0t_64_sync_handler+0x10c/0x138<br /> [ 1406.525750] el0t_64_sync+0x1ac/0x1b0<br /> [ 1406.525876] SMP: stopping secondary CPUs<br /> [ 1406.525965] Kernel Offset: disabled<br /> [ 1406.526032] CPU features: 0x0000,00000080,8e134ca1,9446773f<br /> [ 1406.526130] Memory Limit: none<br /> [ 1406.959099] ---[ end Kernel panic - not syncing: HYP panic:<br /> [ 1406.959099] PS:834003c9 PC:0000b1806db6d170 ESR:00000000f2000800<br /> [ 1406.959099] FAR:ffff8000804be420 HPFAR:0000000000804be0 PAR:0000000000000000<br /> [ 1406.959099] VCPU:0000000000000000 ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: ice_adapter: release xa entry on adapter allocation failure<br /> <br /> When ice_adapter_new() fails, the reserved XArray entry created by<br /> xa_insert() is not released. This causes subsequent insertions at<br /> the same index to return -EBUSY, potentially leading to<br /> NULL pointer dereferences.<br /> <br /> Reorder the operations as suggested by Przemek Kitszel:<br /> 1. Check if adapter already exists (xa_load)<br /> 2. Reserve the XArray slot (xa_reserve)<br /> 3. Allocate the adapter (ice_adapter_new)<br /> 4. Store the adapter (xa_store)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Don&amp;#39;t call reqsk_fastopen_remove() in tcp_conn_request().<br /> <br /> syzbot reported the splat below in tcp_conn_request(). [0]<br /> <br /> If a listener is close()d while a TFO socket is being processed in<br /> tcp_conn_request(), inet_csk_reqsk_queue_add() does not set reqsk-&gt;sk<br /> and calls inet_child_forget(), which calls tcp_disconnect() for the<br /> TFO socket.<br /> <br /> After the cited commit, tcp_disconnect() calls reqsk_fastopen_remove(),<br /> where reqsk_put() is called due to !reqsk-&gt;sk.<br /> <br /> Then, reqsk_fastopen_remove() in tcp_conn_request() decrements the<br /> last req-&gt;rsk_refcnt and frees reqsk, and __reqsk_free() at the<br /> drop_and_free label causes the refcount underflow for the listener<br /> and double-free of the reqsk.<br /> <br /> Let&amp;#39;s remove reqsk_fastopen_remove() in tcp_conn_request().<br /> <br /> Note that other callers make sure tp-&gt;fastopen_rsk is not NULL.<br /> <br /> [0]:<br /> refcount_t: underflow; use-after-free.<br /> WARNING: CPU: 12 PID: 5563 at lib/refcount.c:28 refcount_warn_saturate (lib/refcount.c:28)<br /> Modules linked in:<br /> CPU: 12 UID: 0 PID: 5563 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025<br /> RIP: 0010:refcount_warn_saturate (lib/refcount.c:28)<br /> Code: ab e8 8e b4 98 ff 0f 0b c3 cc cc cc cc cc 80 3d a4 e4 d6 01 00 75 9c c6 05 9b e4 d6 01 01 48 c7 c7 e8 df fb ab e8 6a b4 98 ff 0b e9 03 5b 76 00 cc 80 3d 7d e4 d6 01 00 0f 85 74 ff ff ff c6<br /> RSP: 0018:ffffa79fc0304a98 EFLAGS: 00010246<br /> RAX: d83af4db1c6b3900 RBX: ffff9f65c7a69020 RCX: d83af4db1c6b3900<br /> RDX: 0000000000000000 RSI: 00000000ffff7fff RDI: ffffffffac78a280<br /> RBP: 000000009d781b60 R08: 0000000000007fff R09: ffffffffac6ca280<br /> R10: 0000000000017ffd R11: 0000000000000004 R12: ffff9f65c7b4f100<br /> R13: ffff9f65c7d23c00 R14: ffff9f65c7d26000 R15: ffff9f65c7a64ef8<br /> FS: 00007f9f962176c0(0000) GS:ffff9f65fcf00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000200000000180 CR3: 000000000dbbe006 CR4: 0000000000372ef0<br /> Call Trace:<br /> <br /> tcp_conn_request (./include/linux/refcount.h:400 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 ./include/net/sock.h:1965 ./include/net/request_sock.h:131 net/ipv4/tcp_input.c:7301)<br /> tcp_rcv_state_process (net/ipv4/tcp_input.c:6708)<br /> tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670)<br /> tcp_v6_rcv (net/ipv6/tcp_ipv6.c:1906)<br /> ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:438)<br /> ip6_input (net/ipv6/ip6_input.c:500)<br /> ipv6_rcv (net/ipv6/ip6_input.c:311)<br /> __netif_receive_skb (net/core/dev.c:6104)<br /> process_backlog (net/core/dev.c:6456)<br /> __napi_poll (net/core/dev.c:7506)<br /> net_rx_action (net/core/dev.c:7569 net/core/dev.c:7696)<br /> handle_softirqs (kernel/softirq.c:579)<br /> do_softirq (kernel/softirq.c:480)<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce()<br /> <br /> If new_asoc-&gt;peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0<br /> and sctp_ulpevent_make_authkey() returns 0, then the variable<br /> ai_ev remains zero and the zero will be dereferenced<br /> in the sctp_ulpevent_free() function.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pwm: berlin: Fix wrong register in suspend/resume<br /> <br /> The &amp;#39;enable&amp;#39; register should be BERLIN_PWM_EN rather than<br /> BERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, there<br /> will be cpu exception then kernel panic during suspend/resume.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: lan78xx: Fix lost EEPROM read timeout error(-ETIMEDOUT) in lan78xx_read_raw_eeprom<br /> <br /> Syzbot reported read of uninitialized variable BUG with following call stack.<br /> <br /> lan78xx 8-1:1.0 (unnamed net_device) (uninitialized): EEPROM read operation timeout<br /> =====================================================<br /> BUG: KMSAN: uninit-value in lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1095 [inline]<br /> BUG: KMSAN: uninit-value in lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline]<br /> BUG: KMSAN: uninit-value in lan78xx_reset+0x999/0x2cd0 drivers/net/usb/lan78xx.c:3241<br /> lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1095 [inline]<br /> lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline]<br /> lan78xx_reset+0x999/0x2cd0 drivers/net/usb/lan78xx.c:3241<br /> lan78xx_bind+0x711/0x1690 drivers/net/usb/lan78xx.c:3766<br /> lan78xx_probe+0x225c/0x3310 drivers/net/usb/lan78xx.c:4707<br /> <br /> Local variable sig.i.i created at:<br /> lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1092 [inline]<br /> lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline]<br /> lan78xx_reset+0x77e/0x2cd0 drivers/net/usb/lan78xx.c:3241<br /> lan78xx_bind+0x711/0x1690 drivers/net/usb/lan78xx.c:3766<br /> <br /> The function lan78xx_read_raw_eeprom failed to properly propagate EEPROM<br /> read timeout errors (-ETIMEDOUT). In the fallthrough path, it first<br /> attempted to restore the pin configuration for LED outputs and then<br /> returned only the status of that restore operation, discarding the<br /> original timeout error.<br /> <br /> As a result, callers could mistakenly treat the data buffer as valid<br /> even though the EEPROM read had actually timed out with no data or partial<br /> data.<br /> <br /> To fix this, handle errors in restoring the LED pin configuration separately.<br /> If the restore succeeds, return any prior EEPROM timeout error correctly<br /> to the caller.