Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm, swap: restore swap_space attr aviod kernel panic<br /> <br /> commit 8b47299a411a ("mm, swap: mark swap address space ro and add context<br /> debug check") made the swap address space read-only. It may lead to<br /> kernel panic if arch_prepare_to_swap returns a failure under heavy memory<br /> pressure as follows,<br /> <br /> el1_abort+0x40/0x64<br /> el1h_64_sync_handler+0x48/0xcc<br /> el1h_64_sync+0x84/0x88<br /> errseq_set+0x4c/0xb8 (P)<br /> __filemap_set_wb_err+0x20/0xd0<br /> shrink_folio_list+0xc20/0x11cc<br /> evict_folios+0x1520/0x1be4<br /> try_to_shrink_lruvec+0x27c/0x3dc<br /> shrink_one+0x9c/0x228<br /> shrink_node+0xb3c/0xeac<br /> do_try_to_free_pages+0x170/0x4f0<br /> try_to_free_pages+0x334/0x534<br /> __alloc_pages_direct_reclaim+0x90/0x158<br /> __alloc_pages_slowpath+0x334/0x588<br /> __alloc_frozen_pages_noprof+0x224/0x2fc<br /> __folio_alloc_noprof+0x14/0x64<br /> vma_alloc_zeroed_movable_folio+0x34/0x44<br /> do_pte_missing+0xad4/0x1040<br /> handle_mm_fault+0x4a4/0x790<br /> do_page_fault+0x288/0x5f8<br /> do_translation_fault+0x38/0x54<br /> do_mem_abort+0x54/0xa8<br /> <br /> Restore swap address space as not ro to avoid the panic.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: annotate data-races around slave-&gt;last_rx<br /> <br /> slave-&gt;last_rx and slave-&gt;target_last_arp_rx[...] can be read and written<br /> locklessly. Add READ_ONCE() and WRITE_ONCE() annotations.<br /> <br /> syzbot reported:<br /> <br /> BUG: KCSAN: data-race in bond_rcv_validate / bond_rcv_validate<br /> <br /> write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 1:<br /> bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335<br /> bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533<br /> __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039<br /> __netif_receive_skb_one_core net/core/dev.c:6150 [inline]<br /> __netif_receive_skb+0x59/0x270 net/core/dev.c:6265<br /> netif_receive_skb_internal net/core/dev.c:6351 [inline]<br /> netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410<br /> ...<br /> <br /> write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 0:<br /> bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335<br /> bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533<br /> __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039<br /> __netif_receive_skb_one_core net/core/dev.c:6150 [inline]<br /> __netif_receive_skb+0x59/0x270 net/core/dev.c:6265<br /> netif_receive_skb_internal net/core/dev.c:6351 [inline]<br /> netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410<br /> br_netif_receive_skb net/bridge/br_input.c:30 [inline]<br /> NF_HOOK include/linux/netfilter.h:318 [inline]<br /> ...<br /> <br /> value changed: 0x0000000100005365 -&gt; 0x0000000100005366

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: Disable MMIO access during SMU Mode 1 reset<br /> <br /> During Mode 1 reset, the ASIC undergoes a reset cycle and becomes<br /> temporarily inaccessible via PCIe. Any attempt to access MMIO registers<br /> during this window (e.g., from interrupt handlers or other driver threads)<br /> can result in uncompleted PCIe transactions, leading to NMI panics or<br /> system hangs.<br /> <br /> To prevent this, set the `no_hw_access` flag to true immediately after<br /> triggering the reset. This signals other driver components to skip<br /> register accesses while the device is offline.<br /> <br /> A memory barrier `smp_mb()` is added to ensure the flag update is<br /> globally visible to all cores before the driver enters the sleep/wait<br /> state.<br /> <br /> (cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: reject new transactions if the fs is fully read-only<br /> <br /> [BUG]<br /> There is a bug report where a heavily fuzzed fs is mounted with all<br /> rescue mount options, which leads to the following warnings during<br /> unmount:<br /> <br /> BTRFS: Transaction aborted (error -22)<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted<br /> 6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline]<br /> RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611<br /> Call Trace:<br /> <br /> btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705<br /> btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157<br /> btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517<br /> btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708<br /> btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130<br /> btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499<br /> btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628<br /> evict+0x5f4/0xae0 fs/inode.c:837<br /> __dentry_kill+0x209/0x660 fs/dcache.c:670<br /> finish_dput+0xc9/0x480 fs/dcache.c:879<br /> shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661<br /> generic_shutdown_super+0x67/0x2c0 fs/super.c:621<br /> kill_anon_super+0x3b/0x70 fs/super.c:1289<br /> btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127<br /> deactivate_locked_super+0xbc/0x130 fs/super.c:474<br /> cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318<br /> task_work_run+0x1d4/0x260 kernel/task_work.c:233<br /> exit_task_work include/linux/task_work.h:40 [inline]<br /> do_exit+0x694/0x22f0 kernel/exit.c:971<br /> do_group_exit+0x21c/0x2d0 kernel/exit.c:1112<br /> __do_sys_exit_group kernel/exit.c:1123 [inline]<br /> __se_sys_exit_group kernel/exit.c:1121 [inline]<br /> __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121<br /> x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x44f639<br /> Code: Unable to access opcode bytes at 0x44f60f.<br /> RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7<br /> RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639<br /> RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001<br /> RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0<br /> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001<br /> <br /> <br /> Since rescue mount options will mark the full fs read-only, there should<br /> be no new transaction triggered.<br /> <br /> But during unmount we will evict all inodes, which can trigger a new<br /> transaction, and triggers warnings on a heavily corrupted fs.<br /> <br /> [CAUSE]<br /> Btrfs allows new transaction even on a read-only fs, this is to allow<br /> log replay happen even on read-only mounts, just like what ext4/xfs do.<br /> <br /> However with rescue mount options, the fs is fully read-only and cannot<br /> be remounted read-write, thus in that case we should also reject any new<br /> transactions.<br /> <br /> [FIX]<br /> If we find the fs has rescue mount options, we should treat the fs as<br /> error, so that no new transaction can be started.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/vmware: Fix hypercall clobbers<br /> <br /> Fedora QA reported the following panic:<br /> <br /> BUG: unable to handle page fault for address: 0000000040003e54<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025<br /> RIP: 0010:vmware_hypercall4.constprop.0+0x52/0x90<br /> ..<br /> Call Trace:<br /> vmmouse_report_events+0x13e/0x1b0<br /> psmouse_handle_byte+0x15/0x60<br /> ps2_interrupt+0x8a/0xd0<br /> ...<br /> <br /> because the QEMU VMware mouse emulation is buggy, and clears the top 32<br /> bits of %rdi that the kernel kept a pointer in.<br /> <br /> The QEMU vmmouse driver saves and restores the register state in a<br /> "uint32_t data[6];" and as a result restores the state with the high<br /> bits all cleared.<br /> <br /> RDI originally contained the value of a valid kernel stack address<br /> (0xff5eeb3240003e54). After the vmware hypercall it now contains<br /> 0x40003e54, and we get a page fault as a result when it is dereferenced.<br /> <br /> The proper fix would be in QEMU, but this works around the issue in the<br /> kernel to keep old setups working, when old kernels had not happened to<br /> keep any state in %rdi over the hypercall.<br /> <br /> In theory this same issue exists for all the hypercalls in the vmmouse<br /> driver; in practice it has only been seen with vmware_hypercall3() and<br /> vmware_hypercall4(). For now, just mark RDI/RSI as clobbered for those<br /> two calls. This should have a minimal effect on code generation overall<br /> as it should be rare for the compiler to want to make RDI/RSI live<br /> across hypercalls.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count()<br /> <br /> In iscsit_dec_conn_usage_count(), the function calls complete() while<br /> holding the conn-&gt;conn_usage_lock. As soon as complete() is invoked, the<br /> waiter (such as iscsit_close_connection()) may wake up and proceed to free<br /> the iscsit_conn structure.<br /> <br /> If the waiter frees the memory before the current thread reaches<br /> spin_unlock_bh(), it results in a KASAN slab-use-after-free as the function<br /> attempts to release a lock within the already-freed connection structure.<br /> <br /> Fix this by releasing the spinlock before calling complete().

*** Pendiente de traducción *** The Advanced AJAX Product Filters plugin for WordPress is vulnerable to PHP Object Injection in all versions up to, and including, 3.1.9.6 via deserialization of untrusted input in the shortcode_check function within the Live Composer compatibility layer. This makes it possible for authenticated attackers, with Author-level access and above, to inject a PHP Object. No known POP chain is present in the vulnerable software, which means this vulnerability has no impact unless another plugin or theme containing a POP chain is installed on the site. If a POP chain is present via an additional plugin or theme installed on the target system, it may allow the attacker to perform actions like delete arbitrary files, retrieve sensitive data, or execute code depending on the POP chain present. Note: This vulnerability requires the Live Composer plugin to also be installed and active.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: suspend array while updating raid_disks via sysfs<br /> <br /> In raid1_reshape(), freeze_array() is called before modifying the r1bio<br /> memory pool (conf-&gt;r1bio_pool) and conf-&gt;raid_disks, and<br /> unfreeze_array() is called after the update is completed.<br /> <br /> However, freeze_array() only waits until nr_sync_pending and<br /> (nr_pending - nr_queued) of all buckets reaches zero. When an I/O error<br /> occurs, nr_queued is increased and the corresponding r1bio is queued to<br /> either retry_list or bio_end_io_list. As a result, freeze_array() may<br /> unblock before these r1bios are released.<br /> <br /> This can lead to a situation where conf-&gt;raid_disks and the mempool have<br /> already been updated while queued r1bios, allocated with the old<br /> raid_disks value, are later released. Consequently, free_r1bio() may<br /> access memory out of bounds in put_all_bios() and release r1bios of the<br /> wrong size to the new mempool, potentially causing issues with the<br /> mempool as well.<br /> <br /> Since only normal I/O might increase nr_queued while an I/O error occurs,<br /> suspending the array avoids this issue.<br /> <br /> Note: Updating raid_disks via ioctl SET_ARRAY_INFO already suspends<br /> the array. Therefore, we suspend the array when updating raid_disks<br /> via sysfs to avoid this issue too.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: Implement settime64 as stub for MVM/MLD PTP<br /> <br /> Since commit dfb073d32cac ("ptp: Return -EINVAL on ptp_clock_register if<br /> required ops are NULL"), PTP clock registered through ptp_clock_register<br /> is required to have ptp_clock_info.settime64 set, however, neither MVM<br /> nor MLD&amp;#39;s PTP clock implementation sets it, resulting in warnings when<br /> the interface starts up, like<br /> <br /> WARNING: drivers/ptp/ptp_clock.c:325 at ptp_clock_register+0x2c8/0x6b8, CPU#1: wpa_supplicant/469<br /> CPU: 1 UID: 0 PID: 469 Comm: wpa_supplicant Not tainted 6.18.0+ #101 PREEMPT(full)<br /> ra: ffff800002732cd4 iwl_mvm_ptp_init+0x114/0x188 [iwlmvm]<br /> ERA: 9000000002fdc468 ptp_clock_register+0x2c8/0x6b8<br /> iwlwifi 0000:01:00.0: Failed to register PHC clock (-22)<br /> <br /> I don&amp;#39;t find an appropriate firmware interface to implement settime64()<br /> for iwlwifi MLD/MVM, thus instead create a stub that returns<br /> -EOPTNOTSUPP only, suppressing the warning and allowing the PTP clock to<br /> be registered.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: don&amp;#39;t WARN for connections on invalid channels<br /> <br /> It&amp;#39;s not clear (to me) how exactly syzbot managed to hit this,<br /> but it seems conceivable that e.g. regulatory changed and has<br /> disabled a channel between scanning (channel is checked to be<br /> usable by cfg80211_get_ies_channel_number) and connecting on<br /> the channel later.<br /> <br /> With one scenario that isn&amp;#39;t covered elsewhere described above,<br /> the warning isn&amp;#39;t good, replace it with a (more informative)<br /> error message.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Set correct protection_map[] for VM_NONE/VM_SHARED<br /> <br /> For 32BIT platform _PAGE_PROTNONE is 0, so set a VMA to be VM_NONE or<br /> VM_SHARED will make pages non-present, then cause Oops with kernel page<br /> fault.<br /> <br /> Fix it by set correct protection_map[] for VM_NONE/VM_SHARED, replacing<br /> _PAGE_PROTNONE with _PAGE_PRESENT.

*** Pendiente de traducción *** The Ultimate Member – User Profile, Registration, Login, Member Directory, Content Restriction &amp; Membership Plugin plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the filter parameters (e.g., &amp;#39;filter_first_name&amp;#39;) in all versions up to, and including, 2.11.1 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link.