Vulnerabilidades

*** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slab: Avoid race on slab-&gt;obj_exts in alloc_slab_obj_exts<br /> <br /> If two competing threads enter alloc_slab_obj_exts() and one of them<br /> fails to allocate the object extension vector, it might override the<br /> valid slab-&gt;obj_exts allocated by the other thread with<br /> OBJEXTS_ALLOC_FAIL. This will cause the thread that lost this race and<br /> expects a valid pointer to dereference a NULL pointer later on.<br /> <br /> Update slab-&gt;obj_exts atomically using cmpxchg() to avoid<br /> slab-&gt;obj_exts overrides by racing threads.<br /> <br /> Thanks for Vlastimil and Suren&amp;#39;s help with debugging.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfs: validate record offset in hfsplus_bmap_alloc<br /> <br /> hfsplus_bmap_alloc can trigger a crash if a<br /> record offset or length is larger than node_size<br /> <br /> [ 15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0<br /> [ 15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183<br /> [ 15.265949]<br /> [ 15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary)<br /> [ 15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 15.266167] Call Trace:<br /> [ 15.266168] <br /> [ 15.266169] dump_stack_lvl+0x53/0x70<br /> [ 15.266173] print_report+0xd0/0x660<br /> [ 15.266181] kasan_report+0xce/0x100<br /> [ 15.266185] hfsplus_bmap_alloc+0x887/0x8b0<br /> [ 15.266208] hfs_btree_inc_height.isra.0+0xd5/0x7c0<br /> [ 15.266217] hfsplus_brec_insert+0x870/0xb00<br /> [ 15.266222] __hfsplus_ext_write_extent+0x428/0x570<br /> [ 15.266225] __hfsplus_ext_cache_extent+0x5e/0x910<br /> [ 15.266227] hfsplus_ext_read_extent+0x1b2/0x200<br /> [ 15.266233] hfsplus_file_extend+0x5a7/0x1000<br /> [ 15.266237] hfsplus_get_block+0x12b/0x8c0<br /> [ 15.266238] __block_write_begin_int+0x36b/0x12c0<br /> [ 15.266251] block_write_begin+0x77/0x110<br /> [ 15.266252] cont_write_begin+0x428/0x720<br /> [ 15.266259] hfsplus_write_begin+0x51/0x100<br /> [ 15.266262] cont_write_begin+0x272/0x720<br /> [ 15.266270] hfsplus_write_begin+0x51/0x100<br /> [ 15.266274] generic_perform_write+0x321/0x750<br /> [ 15.266285] generic_file_write_iter+0xc3/0x310<br /> [ 15.266289] __kernel_write_iter+0x2fd/0x800<br /> [ 15.266296] dump_user_range+0x2ea/0x910<br /> [ 15.266301] elf_core_dump+0x2a94/0x2ed0<br /> [ 15.266320] vfs_coredump+0x1d85/0x45e0<br /> [ 15.266349] get_signal+0x12e3/0x1990<br /> [ 15.266357] arch_do_signal_or_restart+0x89/0x580<br /> [ 15.266362] irqentry_exit_to_user_mode+0xab/0x110<br /> [ 15.266364] asm_exc_page_fault+0x26/0x30<br /> [ 15.266366] RIP: 0033:0x41bd35<br /> [ 15.266367] Code: bc d1 f3 0f 7f 27 f3 0f 7f 6f 10 f3 0f 7f 77 20 f3 0f 7f 7f 30 49 83 c0 0f 49 29 d0 48 8d 7c 17 31 e9 9f 0b 00 00 66 0f ef c0 0f 6f 0e f3 0f 6f 56 10 66 0f 74 c1 66 0f d7 d0 49 83 f8f<br /> [ 15.266369] RSP: 002b:00007ffc9e62d078 EFLAGS: 00010283<br /> [ 15.266371] RAX: 00007ffc9e62d100 RBX: 0000000000000000 RCX: 0000000000000000<br /> [ 15.266372] RDX: 00000000000000e0 RSI: 0000000000000000 RDI: 00007ffc9e62d100<br /> [ 15.266373] RBP: 0000400000000040 R08: 00000000000000e0 R09: 0000000000000000<br /> [ 15.266374] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> [ 15.266375] R13: 0000000000000000 R14: 0000000000000000 R15: 0000400000000000<br /> [ 15.266376] <br /> <br /> When calling hfsplus_bmap_alloc to allocate a free node, this function<br /> first retrieves the bitmap from header node and map node using node-&gt;page<br /> together with the offset and length from hfs_brec_lenoff<br /> <br /> ```<br /> len = hfs_brec_lenoff(node, 2, &amp;off16);<br /> off = off16;<br /> <br /> off += node-&gt;page_offset;<br /> pagep = node-&gt;page + (off &gt;&gt; PAGE_SHIFT);<br /> data = kmap_local_page(*pagep);<br /> ```<br /> <br /> However, if the retrieved offset or length is invalid(i.e. exceeds<br /> node_size), the code may end up accessing pages outside the allocated<br /> range for this node.<br /> <br /> This patch adds proper validation of both offset and length before use,<br /> preventing out-of-bounds page access. Move is_bnode_offset_valid and<br /> check_and_correct_requested_length to hfsplus_fs.h, as they may be<br /> required by other functions.