Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fpu: Ensure XFD state on signal delivery<br /> <br /> Sean reported [1] the following splat when running KVM tests:<br /> <br /> WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70<br /> Call Trace:<br /> <br /> fpu__clear_user_states+0x9c/0x100<br /> arch_do_signal_or_restart+0x142/0x210<br /> exit_to_user_mode_loop+0x55/0x100<br /> do_syscall_64+0x205/0x2c0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Chao further identified [2] a reproducible scenario involving signal<br /> delivery: a non-AMX task is preempted by an AMX-enabled task which<br /> modifies the XFD MSR.<br /> <br /> When the non-AMX task resumes and reloads XSTATE with init values,<br /> a warning is triggered due to a mismatch between fpstate::xfd and the<br /> CPU&amp;#39;s current XFD state. fpu__clear_user_states() does not currently<br /> re-synchronize the XFD state after such preemption.<br /> <br /> Invoke xfd_update_state() which detects and corrects the mismatch if<br /> there is a dynamic feature.<br /> <br /> This also benefits the sigreturn path, as fpu__restore_sig() may call<br /> fpu__clear_user_states() when the sigframe is inaccessible.<br /> <br /> [ dhansen: minor changelog munging ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/mellanox: mlxbf-pmc: add sysfs_attr_init() to count_clock init<br /> <br /> The lock-related debug logic (CONFIG_LOCK_STAT) in the kernel is noting<br /> the following warning when the BlueField-3 SOC is booted:<br /> <br /> BUG: key ffff00008a3402a8 has not been registered!<br /> ------------[ cut here ]------------<br /> DEBUG_LOCKS_WARN_ON(1)<br /> WARNING: CPU: 4 PID: 592 at kernel/locking/lockdep.c:4801 lockdep_init_map_type+0x1d4/0x2a0<br /> <br /> Call trace:<br /> lockdep_init_map_type+0x1d4/0x2a0<br /> __kernfs_create_file+0x84/0x140<br /> sysfs_add_file_mode_ns+0xcc/0x1cc<br /> internal_create_group+0x110/0x3d4<br /> internal_create_groups.part.0+0x54/0xcc<br /> sysfs_create_groups+0x24/0x40<br /> device_add+0x6e8/0x93c<br /> device_register+0x28/0x40<br /> __hwmon_device_register+0x4b0/0x8a0<br /> devm_hwmon_device_register_with_groups+0x7c/0xe0<br /> mlxbf_pmc_probe+0x1e8/0x3e0 [mlxbf_pmc]<br /> platform_probe+0x70/0x110<br /> <br /> The mlxbf_pmc driver must call sysfs_attr_init() during the<br /> initialization of the "count_clock" data structure to avoid<br /> this warning.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: mte: Do not warn if the page is already tagged in copy_highpage()<br /> <br /> The arm64 copy_highpage() assumes that the destination page is newly<br /> allocated and not MTE-tagged (PG_mte_tagged unset) and warns<br /> accordingly. However, following commit 060913999d7a ("mm: migrate:<br /> support poisoned recover from migrate folio"), folio_mc_copy() is called<br /> before __folio_migrate_mapping(). If the latter fails (-EAGAIN), the<br /> copy will be done again to the same destination page. Since<br /> copy_highpage() already set the PG_mte_tagged flag, this second copy<br /> will warn.<br /> <br /> Replace the WARN_ON_ONCE(page already tagged) in the arm64<br /> copy_highpage() with a comment.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: increase max link count and fix link-&gt;enc NULL pointer access<br /> <br /> [why]<br /> 1.) dc-&gt;links[MAX_LINKS] array size smaller than actual requested.<br /> max_connector + max_dpia + 4 virtual = 14.<br /> increase from 12 to 14.<br /> <br /> 2.) hw_init() access null LINK_ENC for dpia non display_endpoint.<br /> <br /> (cherry picked from commit d7f5a61e1b04ed87b008c8d327649d184dc5bb45)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sysfs: check visibility before changing group attribute ownership<br /> <br /> Since commit 0c17270f9b92 ("net: sysfs: Implement is_visible for<br /> phys_(port_id, port_name, switch_id)"), __dev_change_net_namespace() can<br /> hit WARN_ON() when trying to change owner of a file that isn&amp;#39;t visible.<br /> See the trace below:<br /> <br /> WARNING: CPU: 6 PID: 2938 at net/core/dev.c:12410 __dev_change_net_namespace+0xb89/0xc30<br /> CPU: 6 UID: 0 PID: 2938 Comm: incusd Not tainted 6.17.1-1-mainline #1 PREEMPT(full) 4b783b4a638669fb644857f484487d17cb45ed1f<br /> Hardware name: Framework Laptop 13 (AMD Ryzen 7040Series)/FRANMDCP07, BIOS 03.07 02/19/2025<br /> RIP: 0010:__dev_change_net_namespace+0xb89/0xc30<br /> [...]<br /> Call Trace:<br /> <br /> ? if6_seq_show+0x30/0x50<br /> do_setlink.isra.0+0xc7/0x1270<br /> ? __nla_validate_parse+0x5c/0xcc0<br /> ? security_capable+0x94/0x1a0<br /> rtnl_newlink+0x858/0xc20<br /> ? update_curr+0x8e/0x1c0<br /> ? update_entity_lag+0x71/0x80<br /> ? sched_balance_newidle+0x358/0x450<br /> ? psi_task_switch+0x113/0x2a0<br /> ? __pfx_rtnl_newlink+0x10/0x10<br /> rtnetlink_rcv_msg+0x346/0x3e0<br /> ? sched_clock+0x10/0x30<br /> ? __pfx_rtnetlink_rcv_msg+0x10/0x10<br /> netlink_rcv_skb+0x59/0x110<br /> netlink_unicast+0x285/0x3c0<br /> ? __alloc_skb+0xdb/0x1a0<br /> netlink_sendmsg+0x20d/0x430<br /> ____sys_sendmsg+0x39f/0x3d0<br /> ? import_iovec+0x2f/0x40<br /> ___sys_sendmsg+0x99/0xe0<br /> __sys_sendmsg+0x8a/0xf0<br /> do_syscall_64+0x81/0x970<br /> ? __sys_bind+0xe3/0x110<br /> ? syscall_exit_work+0x143/0x1b0<br /> ? do_syscall_64+0x244/0x970<br /> ? sock_alloc_file+0x63/0xc0<br /> ? syscall_exit_work+0x143/0x1b0<br /> ? do_syscall_64+0x244/0x970<br /> ? alloc_fd+0x12e/0x190<br /> ? put_unused_fd+0x2a/0x70<br /> ? do_sys_openat2+0xa2/0xe0<br /> ? syscall_exit_work+0x143/0x1b0<br /> ? do_syscall_64+0x244/0x970<br /> ? exc_page_fault+0x7e/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [...]<br /> <br /> <br /> Fix this by checking is_visible() before trying to touch the attribute.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: rockchip-sfc: Fix DMA-API usage<br /> <br /> Use DMA-API dma_map_single() call for getting the DMA address of the<br /> transfer buffer instead of hacking with virt_to_phys().<br /> <br /> This fixes the following DMA-API debug warning:<br /> ------------[ cut here ]------------<br /> DMA-API: rockchip-sfc fe300000.spi: device driver tries to sync DMA memory it has not allocated [device address=0x000000000cf70000] [size=288 bytes]<br /> WARNING: kernel/dma/debug.c:1106 at check_sync+0x1d8/0x690, CPU#2: systemd-udevd/151<br /> Modules linked in: ...<br /> Hardware name: Hardkernel ODROID-M1 (DT)<br /> pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : check_sync+0x1d8/0x690<br /> lr : check_sync+0x1d8/0x690<br /> ..<br /> Call trace:<br /> check_sync+0x1d8/0x690 (P)<br /> debug_dma_sync_single_for_cpu+0x84/0x8c<br /> __dma_sync_single_for_cpu+0x88/0x234<br /> rockchip_sfc_exec_mem_op+0x4a0/0x798 [spi_rockchip_sfc]<br /> spi_mem_exec_op+0x408/0x498<br /> spi_nor_read_data+0x170/0x184<br /> spi_nor_read_sfdp+0x74/0xe4<br /> spi_nor_parse_sfdp+0x120/0x11f0<br /> spi_nor_sfdp_init_params_deprecated+0x3c/0x8c<br /> spi_nor_scan+0x690/0xf88<br /> spi_nor_probe+0xe4/0x304<br /> spi_mem_probe+0x6c/0xa8<br /> spi_probe+0x94/0xd4<br /> really_probe+0xbc/0x298<br /> ...

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix general protection fault in __smc_diag_dump<br /> <br /> The syzbot report a crash:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xfbd5a5d5a0000003: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: maybe wild-memory-access in range [0xdead4ead00000018-0xdead4ead0000001f]<br /> CPU: 1 UID: 0 PID: 6949 Comm: syz.0.335 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025<br /> RIP: 0010:smc_diag_msg_common_fill net/smc/smc_diag.c:44 [inline]<br /> RIP: 0010:__smc_diag_dump.constprop.0+0x3ca/0x2550 net/smc/smc_diag.c:89<br /> Call Trace:<br /> <br /> smc_diag_dump_proto+0x26d/0x420 net/smc/smc_diag.c:217<br /> smc_diag_dump+0x27/0x90 net/smc/smc_diag.c:234<br /> netlink_dump+0x539/0xd30 net/netlink/af_netlink.c:2327<br /> __netlink_dump_start+0x6d6/0x990 net/netlink/af_netlink.c:2442<br /> netlink_dump_start include/linux/netlink.h:341 [inline]<br /> smc_diag_handler_dump+0x1f9/0x240 net/smc/smc_diag.c:251<br /> __sock_diag_cmd net/core/sock_diag.c:249 [inline]<br /> sock_diag_rcv_msg+0x438/0x790 net/core/sock_diag.c:285<br /> netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]<br /> netlink_unicast+0x5a7/0x870 net/netlink/af_netlink.c:1346<br /> netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1896<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> __sock_sendmsg net/socket.c:729 [inline]<br /> ____sys_sendmsg+0xa95/0xc70 net/socket.c:2614<br /> ___sys_sendmsg+0x134/0x1d0 net/socket.c:2668<br /> __sys_sendmsg+0x16d/0x220 net/socket.c:2700<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0x4e0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> The process like this:<br /> <br /> (CPU1) | (CPU2)<br /> ---------------------------------|-------------------------------<br /> inet_create() |<br /> // init clcsock to NULL |<br /> sk = sk_alloc() |<br /> |<br /> // unexpectedly change clcsock |<br /> inet_init_csk_locks() |<br /> |<br /> // add sk to hash table |<br /> smc_inet_init_sock() |<br /> smc_sk_init() |<br /> smc_hash_sk() |<br /> | // traverse the hash table<br /> | smc_diag_dump_proto<br /> | __smc_diag_dump()<br /> | // visit wrong clcsock<br /> | smc_diag_msg_common_fill()<br /> // alloc clcsock |<br /> smc_create_clcsk |<br /> sock_create_kern |<br /> <br /> With CONFIG_DEBUG_LOCK_ALLOC=y, the smc-&gt;clcsock is unexpectedly changed<br /> in inet_init_csk_locks(). The INET_PROTOSW_ICSK flag is no need by smc,<br /> just remove it.<br /> <br /> After removing the INET_PROTOSW_ICSK flag, this patch alse revert<br /> commit 6fd27ea183c2 ("net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC")<br /> to avoid casting smc_sock to inet_connection_sock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: stacktrace: Disable KASAN checks for non-current tasks<br /> <br /> Unwinding the stack of a task other than current, KASAN would report<br /> "BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460"<br /> <br /> There is a same issue on x86 and has been resolved by the commit<br /> 84936118bdf3 ("x86/unwind: Disable KASAN checks for non-current tasks")<br /> The solution could be applied to RISC-V too.<br /> <br /> This patch also can solve the issue:<br /> https://seclists.org/oss-sec/2025/q4/23<br /> <br /> [pjw@kernel.org: clean up checkpatch issues]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/intel: Fix KASAN global-out-of-bounds warning<br /> <br /> When running "perf mem record" command on CWF, the below KASAN<br /> global-out-of-bounds warning is seen.<br /> <br /> ==================================================================<br /> BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0<br /> Read of size 4 at addr ffffffffb721d000 by task dtlb/9850<br /> <br /> Call Trace:<br /> <br /> kasan_report+0xb8/0xf0<br /> cmt_latency_data+0x176/0x1b0<br /> setup_arch_pebs_sample_data+0xf49/0x2560<br /> intel_pmu_drain_arch_pebs+0x577/0xb00<br /> handle_pmi_common+0x6c4/0xc80<br /> <br /> The issue is caused by below code in __grt_latency_data(). The code<br /> tries to access x86_hybrid_pmu structure which doesn&amp;#39;t exist on<br /> non-hybrid platform like CWF.<br /> <br /> WARN_ON_ONCE(hybrid_pmu(event-&gt;pmu)-&gt;pmu_type == hybrid_big)<br /> <br /> So add is_hybrid() check before calling this WARN_ON_ONCE to fix the<br /> global-out-of-bounds access issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sysfb: Do not dereference NULL pointer in plane reset<br /> <br /> The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not<br /> deref that pointer, but forward NULL to the other plane-reset helpers.<br /> Clears plane-&gt;state to NULL.<br /> <br /> v2:<br /> - fix typo in commit description (Javier)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()<br /> <br /> Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity()<br /> which causes the code to proceed with NULL clock pointers. The current<br /> logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both<br /> valid pointers and NULL, leading to potential NULL pointer dereference<br /> in clk_get_rate().<br /> <br /> Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:<br /> "The error code within @ptr if it is an error pointer; 0 otherwise."<br /> <br /> This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL<br /> pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed)<br /> when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be<br /> called when of_clk_get() returns NULL.<br /> <br /> Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid<br /> pointers, preventing potential NULL pointer dereference in clk_get_rate().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: enetc: fix the deadlock of enetc_mdio_lock<br /> <br /> After applying the workaround for err050089, the LS1028A platform<br /> experiences RCU stalls on RT kernel. This issue is caused by the<br /> recursive acquisition of the read lock enetc_mdio_lock. Here list some<br /> of the call stacks identified under the enetc_poll path that may lead to<br /> a deadlock:<br /> <br /> enetc_poll<br /> -&gt; enetc_lock_mdio<br /> -&gt; enetc_clean_rx_ring OR napi_complete_done<br /> -&gt; napi_gro_receive<br /> -&gt; enetc_start_xmit<br /> -&gt; enetc_lock_mdio<br /> -&gt; enetc_map_tx_buffs<br /> -&gt; enetc_unlock_mdio<br /> -&gt; enetc_unlock_mdio<br /> <br /> After enetc_poll acquires the read lock, a higher-priority writer attempts<br /> to acquire the lock, causing preemption. The writer detects that a<br /> read lock is already held and is scheduled out. However, readers under<br /> enetc_poll cannot acquire the read lock again because a writer is already<br /> waiting, leading to a thread hang.<br /> <br /> Currently, the deadlock is avoided by adjusting enetc_lock_mdio to prevent<br /> recursive lock acquisition.