Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: wm_adsp: Fix NULL dereference when removing firmware controls<br /> <br /> In wm_adsp_control_remove() check that the priv pointer is not NULL<br /> before attempting to cleanup what it points to.<br /> <br /> When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that<br /> wm_adsp can create its own private control data. There are two cases<br /> where private data is not created:<br /> <br /> 1. The control is a SYSTEM control, so an ALSA control is not created.<br /> <br /> 2. The codec driver has registered a control_add() callback that<br /> hides the control, so wm_adsp_control_add() is not called.<br /> <br /> When cs_dsp_remove destroys its control list it calls<br /> wm_adsp_control_remove() for each control. But wm_adsp_control_remove()<br /> was attempting to cleanup the private data pointed to by cs_ctl-&gt;priv<br /> without checking the pointer for NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv/ptrace: Use USER_REGSET_NOTE_TYPE for REGSET_CFI<br /> <br /> Fixes a warning while dumping core:<br /> <br /> [54983.546369][ C7] WARNING: [!note_name] fs/binfmt_elf.c:1771 at elf_core_dump+0x910/0xf68, CPU#7: abort01/31982

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads()<br /> <br /> When a multi-threaded process receives a stop signal (e.g., SIGSTOP),<br /> do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all<br /> threads and sets signal-&gt;group_stop_count to the number of threads. If<br /> one of the threads concurrently calls execve(), de_thread() invokes<br /> zap_other_threads() to kill all other threads. zap_other_threads()<br /> aborts the pending group stop by resetting signal-&gt;group_stop_count to 0<br /> and clears the JOBCTL_PENDING_MASK for all other threads. However, it<br /> fails to clear the job control flags for the calling thread.<br /> <br /> When execve() completes, the calling thread returns to user mode and<br /> checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag,<br /> it calls do_signal_stop(), which invokes task_participate_group_stop().<br /> Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the<br /> already-zero signal-&gt;group_stop_count, triggering a warning:<br /> <br /> sig-&gt;group_stop_count == 0<br /> WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373<br /> task_participate_group_stop+0x215/0x2d0<br /> Call Trace:<br /> <br /> do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619<br /> get_signal+0xa8c/0x1330 kernel/signal.c:2884<br /> arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337<br /> exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98<br /> do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> Fix this race condition by clearing the JOBCTL_PENDING_MASK for the<br /> calling thread in zap_other_threads(), ensuring it does not retain any<br /> stale job control state after the thread group is destroyed. This aligns<br /> with other functions that tear down a thread group and abort group<br /> stops, such as zap_process() and complete_signal(), which correctly<br /> clear these flags for all threads including the current one.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hsr: Remove WARN_ONCE() in hsr_addr_is_self().<br /> <br /> syzbot reported the warning [0] in hsr_addr_is_self(),<br /> whose assumption is simply wrong.<br /> <br /> hsr-&gt;self_node is cleared in hsr_del_self_node(), which<br /> is called from hsr_dellink().<br /> <br /> Since dev-&gt;rtnl_link_ops-&gt;dellink() is called before<br /> unregister_netdevice_many(), there is a window when<br /> user can find the device but without hsr-&gt;self_node.<br /> <br /> Let&amp;#39;s remove WARN_ONCE() in hsr_addr_is_self().<br /> <br /> [0]:<br /> HSR: No self node<br /> WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)}<br /> Tainted: [L]=SOFTLOCKUP<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026<br /> RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39<br /> Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96<br /> RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283<br /> RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000<br /> RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700<br /> RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000<br /> R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000<br /> FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0<br /> DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002<br /> DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> check_local_dest net/hsr/hsr_forward.c:592 [inline]<br /> fill_frame_info net/hsr/hsr_forward.c:728 [inline]<br /> hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739<br /> hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236<br /> __netdev_start_xmit include/linux/netdevice.h:5368 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:5377 [inline]<br /> xmit_one net/core/dev.c:3888 [inline]<br /> dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904<br /> __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870<br /> neigh_output include/net/neighbour.h:556 [inline]<br /> ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237<br /> ip_send_skb net/ipv4/ip_output.c:1510 [inline]<br /> ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530<br /> raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659<br /> sock_sendmsg_nosec net/socket.c:787 [inline]<br /> __sock_sendmsg net/socket.c:802 [inline]<br /> ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698<br /> ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752<br /> __sys_sendmsg net/socket.c:2784 [inline]<br /> __do_sys_sendmsg net/socket.c:2789 [inline]<br /> __se_sys_sendmsg net/socket.c:2787 [inline]<br /> __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f6feb62ce59<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59<br /> RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004<br /> RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: rds: clear i_sends on setup unwind<br /> <br /> The RDS IB connection teardown path is written so it can run during<br /> partial startup and on repeated shutdown attempts. It uses NULL<br /> pointers to distinguish resources that are still owned from resources<br /> that have already been released.<br /> <br /> When rds_ib_setup_qp() fails after allocating i_sends but before<br /> allocating i_recvs, the sends_out path frees i_sends without clearing<br /> the pointer. A later shutdown pass can still treat that stale pointer<br /> as a live send ring allocation.<br /> <br /> Clear i_sends after vfree() in the error unwind path so the existing<br /> shutdown logic continues to use the correct ownership state.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: errata: Mitigate TLBI errata on various Arm CPUs<br /> <br /> A number of CPUs developed by Arm suffer from errata whereby a broadcast<br /> TLBI;DSB sequence may complete before the global observation of writes<br /> which are translated by an affected TLB entry.<br /> <br /> These errata ONLY affect the completion of memory accesses which have<br /> been translated by an invalidated TLB entry, and these errata DO NOT<br /> affect the actual invalidation of TLB entries. TLB entries are removed<br /> correctly.<br /> <br /> This issue has been assigned CVE ID CVE-2025-10263.<br /> <br /> To mitigate this issue, Arm recommends that software follows any<br /> affected TLBI;DSB sequence with an additional TLBI;DSB, which will<br /> ensure that all memory write effects affected by the first TLBI have<br /> been globally observed. The additional TLBI can use any operation that<br /> is broadcast to affected CPUs, and the additional DSB can use any option<br /> that is sufficient to complete the additional TLBI.<br /> <br /> The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate<br /> the issue. Enable this workaround for affected CPUs, and update the<br /> silicon errata documentation accordingly.<br /> <br /> Note that due to the manner in which Arm develops IP and tracks errata,<br /> some CPUs share a common erratum number.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: imx: fix clock and pinctrl state inconsistency in runtime PM<br /> <br /> In i2c_imx_runtime_suspend(), the clock is disabled before switching<br /> the pinctrl state to sleep. If pinctrl_pm_select_sleep_state() fails,<br /> the runtime suspend is aborted but the clock remains disabled, causing<br /> a system crash when the hardware is subsequently accessed.<br /> <br /> Fix this by switching the pinctrl state before disabling the clock so<br /> that a pinctrl failure leaves the clock enabled and the hardware<br /> accessible.<br /> <br /> In i2c_imx_runtime_resume(), restore the pinctrl state back to sleep<br /> if clk_enable() fails to keep the consistent.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: mm: call pagetable dtor when freeing hot-removed page tables<br /> <br /> Since 5e8eb9aeeda3 ("arm64: mm: always call PTE/PMD ctor in<br /> __create_pgd_mapping()") page-table allocation on ARM64 always calls<br /> pagetable_{pte,pmd,pud,p4d}_ctor(). This sets the page_type to<br /> PGTY_table, increments NR_PAGETABLE and possible allocates a PTL. However<br /> the matching pagetable_dtor() calls were never added.<br /> <br /> With DEBUG_VM enabled on kernel versions prior to v6.17 without<br /> 2dfcd1608f3a9 ("mm/page_alloc: let page freeing clear any set page type")<br /> this leads to the following warning when freeing these pages due to<br /> page-&gt;page_type sharing page-&gt;_mapcount:<br /> <br /> BUG: Bad page state in process ... pfn:284fbb<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x284fbb<br /> flags: 0x17fffc000000000(node=0|zone=2|lastcpupid=0x1ffff)<br /> page_type: f2(table)<br /> page dumped because: nonzero mapcount<br /> Call trace:<br /> bad_page+0x13c/0x160<br /> __free_frozen_pages+0x6cc/0x860<br /> ___free_pages+0xf4/0x180<br /> free_pages+0x54/0x80<br /> free_hotplug_page_range.part.0+0x58/0x90<br /> free_empty_tables+0x438/0x500<br /> __remove_pgd_mapping.constprop.0+0x60/0xa8<br /> arch_remove_memory+0x48/0x80<br /> try_remove_memory+0x158/0x1d8<br /> offline_and_remove_memory+0x138/0x180<br /> <br /> It can also lead to leaking the ptl allocation if ALLOC_SPLIT_PTLOCKS is<br /> defined and incorrect NR_PAGETABLE stats. Fix this by calling<br /> pagetable_dtor() in free_hotplug_pgtable_page() prior to freeing the page<br /> to undo the effects of calling pagetable_*_ctor().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow<br /> <br /> Commit 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from<br /> VMAP shadow") added a dummy read from the KASAN VMAP stack shadow in<br /> __switch_to(). The read uses ldr, but the KASAN shadow address is<br /> byte-granular and is not guaranteed to be word aligned.<br /> <br /> ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and<br /> CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to()<br /> with an alignment exception before reaching init.<br /> <br /> Use ldrb for the dummy shadow access. The code only needs to fault in the<br /> shadow mapping if the stack shadow is missing, so a byte load is sufficient<br /> and matches the granularity of KASAN shadow memory.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: mcp23s08: Initialize mcp-&gt;dev and mcp-&gt;addr before regmap init<br /> <br /> Regmap initialization triggers regcache_maple_populate() which attempts<br /> SPI read to populate cache. SPI read requires mcp-&gt;dev and mcp-&gt;addr to<br /> be set, without them, NULL pointer dereference occurs during probe.<br /> <br /> Move initialization before mcp23s08_spi_regmap_init() call.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust: arm64: set uwtable llvm module flag for CONFIG_UNWIND_TABLES<br /> <br /> Due to a rustc bug [1] the -Cforce-unwind-tables=y flag only emits the<br /> uwtable annotation for functions, but not for the module. This means<br /> that compiler-generated functions such as &amp;#39;asan.module_ctor&amp;#39; do not<br /> receive the uwtable annotation.<br /> <br /> When CONFIG_UNWIND_PATCH_PAC_INTO_SCS is enabled, this leads to boot<br /> failures because the dwarf information emitted for the kasan<br /> constructors is wrong, which causes the SCS boot patching code to<br /> patch the constructor in an illegal manner. Specifically, the paciasp<br /> instruction is patched, but the autiasp instruction is not. This<br /> mismatch leads to a crash when the constructor is called during boot.<br /> <br /> ==================================================================<br /> BUG: KASAN: global-out-of-bounds in do_basic_setup+0x4c/0x90<br /> Read of size 8 at addr ffffffe3cc7eb488 by task swapper/0/1<br /> <br /> Specifically the faulting instruction is the (*fn)() to invoke the<br /> constructor in do_ctors() of the init/main.c file.<br /> <br /> Once the fix lands in rustc, this flag can be made conditional on the<br /> rustc version. Note that passing the flag on a rustc with the fix<br /> present has no effect.<br /> <br /> [ The fix [1] has landed for Rust 1.98.0 (expected release on<br /> 2026-08-20).<br /> <br /> Thus add a version check as discussed.<br /> <br /> - Miguel ]<br /> <br /> [ Adjusted link and comment. - Miguel ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/virtio: Fix driver removal with disabled KMS<br /> <br /> DRM atomic and modesetting aren&amp;#39;t initialized if virtio-gpu driver built<br /> with disabled KMS, leading to access of uninitialized data on driver<br /> removal/unbinding and crashing kernel. Fix it by skipping shutting down<br /> atomic core with unavailable KMS.