Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR<br /> <br /> When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown<br /> path ends up calling pci_iounmap() on the same iomem with some offset,<br /> which is unnecessary and triggers a kernel warning like the following:<br /> <br /> Trying to vunmap() nonexistent vm area (0000000069a5ffe8)<br /> WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937<br /> [...]<br /> Call trace:<br /> vunmap+0x58/0x68 (P)<br /> iounmap+0x34/0x48<br /> pci_iounmap+0x2c/0x40<br /> ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf]<br /> pci_device_remove+0x48/0xf8<br /> device_remove+0x50/0x88<br /> device_release_driver_internal+0x1c8/0x228<br /> driver_detach+0x50/0xb0<br /> bus_remove_driver+0x74/0x100<br /> driver_unregister+0x34/0x68<br /> pci_unregister_driver+0x34/0xa0<br /> ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf]<br /> [...]<br /> <br /> Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mld: validate sta_mask before ffs() in BA session handlers<br /> <br /> Three BA session handlers use ffs(ba_data-&gt;sta_mask) - 1 to derive a<br /> station ID without checking that sta_mask is non-zero. When sta_mask is<br /> zero, ffs() returns 0 and the subtraction wraps to 0xFFFFFFFF, causing<br /> an out-of-bounds access on fw_id_to_link_sta[].<br /> <br /> Add WARN_ON_ONCE(!ba_data-&gt;sta_mask) guards before each ffs() call,<br /> consistent with the existing check in iwl_mld_ampdu_rx_start().

*** Pendiente de traducción *** Suna before 0.9.102 contains a broken access control vulnerability in the message queue API that allows authenticated attackers to access and manipulate queue resources belonging to other users by exploiting missing ownership and account isolation checks. Attackers can read pending prompt queues of all users, read or delete individual sessions, and inject arbitrary prompts into another user&amp;#39;s session queue, causing the background drainer to forward malicious messages to the victim&amp;#39;s running AI agent with the victim&amp;#39;s credentials and permissions.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init()<br /> <br /> Move of_node_put(dn) after the of_match_node() call, which still needs<br /> the node pointer. The node reference is correctly released after use.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: hyper-v: Bound the bank index when querying sparse banks<br /> <br /> When checking if a VP ID is included in a sparse bank set, explicitly check<br /> that the ID can actually be contained in a sparse bank (the TLFS allows for<br /> a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB<br /> flush for L2, the VP ID is copied verbatim from the enlightened VMCS,<br /> without any bounds check, i.e. isn&amp;#39;t guaranteed to be under the limit of<br /> 4096.<br /> <br /> Failure to check the bounds of the VP ID leads to an out-of-bounds read<br /> when testing the sparse bank, and super strictly speaking could lead to KVM<br /> performing an unnecessary TLB flush for an L2 vCPU.<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm]<br /> Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802<br /> <br /> CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x51/0x60<br /> print_report+0xcb/0x5d0<br /> kasan_report+0xb4/0xe0<br /> kasan_check_range+0x35/0x1b0<br /> hv_is_vp_in_sparse_set+0x85/0x100 [kvm]<br /> kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm]<br /> kvm_hv_hypercall+0xe6b/0x1e60 [kvm]<br /> vmx_handle_exit+0x485/0x1b60 [kvm_intel]<br /> kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm]<br /> kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm]<br /> __x64_sys_ioctl+0x129/0x1a0<br /> do_syscall_64+0xb9/0xcf0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f0e62d1a9bf<br /> <br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f<br /> flags: 0x4000000000000000(zone=1)<br /> raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> &gt;ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ^<br /> ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ==================================================================<br /> Disabling lock debugging due to kernel taint<br /> <br /> Opportunistically add a compile time assertion to ensure the maximum number<br /> of sparse banks exactly matches the number of possible bits in the passed<br /> in mask.<br /> <br /> [sean: add KASAN splat, drop comment, add assert, massage changelog]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: smp: report dying CPU to RCU in stop_this_cpu()<br /> <br /> smp_send_stop() parks all secondary CPUs in stop_this_cpu(). The function<br /> marks the CPU offline for the scheduler via set_cpu_online(false) but<br /> never informs RCU, so RCU keeps expecting a quiescent state from CPUs<br /> that are now spinning forever with interrupts disabled.<br /> <br /> As long as nothing waits for an RCU grace period after smp_send_stop()<br /> this is harmless, which is why it went unnoticed. Since commit<br /> 91840be8f710 ("irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT")<br /> however, irq_work_sync() calls synchronize_rcu() on architectures without<br /> an irq_work self-IPI, i.e. where arch_irq_work_has_interrupt() returns<br /> false. That is the asm-generic default used by MIPS. Any irq_work_sync()<br /> issued in the reboot/shutdown path after smp_send_stop() then blocks on<br /> a grace period that can never complete, hanging the reboot:<br /> <br /> WARNING: CPU: 0 PID: 15 at kernel/irq_work.c:144 irq_work_queue_on<br /> ...<br /> rcu: INFO: rcu_sched detected stalls on CPUs/tasks:<br /> rcu: Offline CPU 1 blocking current GP.<br /> rcu: Offline CPU 2 blocking current GP.<br /> rcu: Offline CPU 3 blocking current GP.<br /> <br /> This issue was noticed on several Realtek MIPS switch SoCs (MIPS<br /> interAptiv) and came up during kernel bump downstream in OpenWrt from<br /> 6.18.33 to 6.18.34, after the backport of the patch to the 6.18 stable<br /> branch. The patch also has been backported all the way back to 6.1.<br /> <br /> Call rcutree_report_cpu_dead() once interrupts are disabled, mirroring the<br /> generic CPU-hotplug offline path, so RCU stops waiting on the parked CPUs<br /> and grace periods can still complete. MIPS shuts down all CPUs here<br /> without going through the CPU-hotplug mechanism, so this report is not<br /> otherwise issued. Reporting a dying CPU to RCU outside the regular hotplug<br /> offline path is not unprecedented: arm64 does the same in cpu_die_early().<br /> There it is an exception for a CPU that was coming online and is aborting<br /> bringup, rather than the default shutdown action as on MIPS.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fpga: region: fix use-after-free in child_regions_with_firmware()<br /> <br /> Move of_node_put(child_region) after the error print to avoid accessing<br /> freed memory when pr_err() references child_region.<br /> <br /> [ Yilun: Fix the Fixes tag ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Report dying CPU to RCU in stop_this_cpu()<br /> <br /> This is a port of MIPS commit 9f3f3bdc6d9dac1 ("MIPS: smp: report dying<br /> CPU to RCU in stop_this_cpu()"). smp_send_stop() parks all secondary<br /> CPUs in stop_this_cpu(). And the function marks the CPU offline for the<br /> scheduler via set_cpu_online(false) but never informs RCU, so RCU keeps<br /> expecting a quiescent state from CPUs that are now spinning forever with<br /> interrupts disabled.<br /> <br /> As long as nothing waits for an RCU grace period after smp_send_stop()<br /> this is harmless, which is why it went unnoticed. However, since commit<br /> 91840be8f710370 ("irq_work: Fix use-after-free in irq_work_single() on<br /> PREEMPT_RT"), irq_work_sync() calls synchronize_rcu() on architectures<br /> without an irq_work self-IPI, i.e. where arch_irq_work_has_interrupt()<br /> returns false. Any irq_work_sync() issued in the reboot/shutdown/halt<br /> path after smp_send_stop() then blocks on a grace period that can never<br /> complete, hanging the reboot:<br /> <br /> WARNING: CPU: 0 PID: 15 at kernel/irq_work.c:144 irq_work_queue_on<br /> ...<br /> rcu: INFO: rcu_sched detected stalls on CPUs/tasks:<br /> rcu: Offline CPU 1 blocking current GP.<br /> rcu: Offline CPU 2 blocking current GP.<br /> rcu: Offline CPU 3 blocking current GP.<br /> <br /> This issue needs some hacks to reproduce, and it was not noticed on<br /> LoongArch because arch_irq_work_has_interrupt() usually returns true.<br /> <br /> Call rcutree_report_cpu_dead() once interrupts are disabled, mirroring<br /> the generic CPU-hotplug offline path, so RCU stops waiting on the parked<br /> CPUs and grace periods can still complete. LoongArch shuts down all CPUs<br /> here without going through the CPU-hotplug mechanism, so this report is<br /> not otherwise issued.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pwrseq: core: fix use-after-free in pwrseq_debugfs_seq_next()<br /> <br /> pwrseq_debugfs_seq_next() declares &amp;#39;next&amp;#39; with __free(put_device),<br /> which causes put_device() to be called on the returned pointer when<br /> the variable goes out of scope. This results in a use-after-free<br /> since the seq_file framework receives a pointer whose reference has<br /> already been dropped.<br /> <br /> Simply removing __free(put_device) would fix the UAF but would leak<br /> the reference acquired by bus_find_next_device(), as stop() only<br /> calls up_read(&amp;pwrseq_sem) and never releases the device reference.<br /> <br /> Fix this by making the reference counting consistent across all<br /> seq_file callbacks, matching the standard pattern used by PCI and<br /> SCSI:<br /> <br /> - start(): use get_device() so it returns a referenced pointer.<br /> - next(): explicitly put_device(curr) to release the previous<br /> device&amp;#39;s reference (no NULL check needed - the seq_file framework<br /> only calls next() while the previous return was non-NULL).<br /> - stop(): put_device(data) to release the last iterated device&amp;#39;s<br /> reference, with a NULL guard since stop() may be called with NULL<br /> when start() returned NULL or next() reached end-of-sequence.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: DEC: Prevent initial console buffer from landing in XKPHYS<br /> <br /> In 64-bit configurations calling the initial console output handler from<br /> a kernel thread other than the initial one will result in a situation<br /> where the stack has been placed in the XKPHYS 64-bit memory segment and<br /> consequently so has been the buffer allocated there that is used as the<br /> argument corresponding to the `%s&amp;#39; output conversion specifier for the<br /> firmware&amp;#39;s printf() entry point.<br /> <br /> This 64-bit address will then be truncated by 32-bit firmware, resulting<br /> in an attempt to access the wrong memory location, which in turn will<br /> cause all kinds of unpredictable behaviour, such as a kernel crash:<br /> <br /> Console: colour dummy device 160x64<br /> Calibrating delay loop... 49.36 BogoMIPS (lpj=192512)<br /> pid_max: default: 32768 minimum: 301<br /> CPU 0 Unable to handle kernel paging request at virtual address 000000000203bd00, epc == ffffffffbfc08364, ra == ffffffffbfc08800<br /> Oops[#1]:<br /> CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc2-00254-gfb649bda6f56-dirty #121<br /> $ 0 : 0000000000000000 0000000000000001 0000000000000023 ffffffff80684ba0<br /> $ 4 : 000000000203bd00 ffffffffbfc0f3b4 ffffffffffffffff 0000000000000073<br /> $ 8 : 0a303d7469000000 0000000000000000 0000000000000073 ffffffffbfc0f473<br /> $12 : 0000000000000002 0000000000000000 ffffffff80684c1c 0000000000000000<br /> $16 : 0000000000000000 ffffffff80596dc9 0000000000000000 ffffffffbfc09240<br /> $20 : ffffffff80684c40 ffffffffbfc0f400 000000000000002d 000000000000002b<br /> $24 : ffffffffffffffbf 000000000203bd00<br /> $28 : ffffffff805f0000 ffffffff80684b58 0000000000000030 ffffffffbfc08800<br /> Hi : 0000000000000000<br /> Lo : 0000000000000aa8<br /> epc : ffffffffbfc08364 0xffffffffbfc08364<br /> ra : ffffffffbfc08800 0xffffffffbfc08800<br /> Status: 140120e2 KX SX UX KERNEL EXL<br /> Cause : 00000008 (ExcCode 02)<br /> BadVA : 000000000203bd00<br /> PrId : 00000430 (R4000SC)<br /> Modules linked in:<br /> Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000)<br /> Stack : 0000000000000000 0000000000000000 0000000000000000 0000004d0000004d<br /> 80684cc0806a2a40 80596dc80000004d 8061000000000000 bfc0850c80684c38<br /> 0000000000000000 000000000203bd00 0000000000000000 0000000000000000<br /> 0000000000000000 00000000bfc0f3b4 0000000000000000 0000000000000000<br /> 0000000000000000 0000000000000000 0000000000000000 0000000000000000<br /> 0000000000000000 0000000000000000 0000000000000000 0000000000000000<br /> 0000002500000000 0000000000000000 0000000000000000 802c1a7400000000<br /> 0203bd0080596dc8 0203bd4d69000000 6c61632000000018 5f746567646e6172<br /> 6c616320625f6d6f 5f736e5f6d6f7266 206361323778302b 303d74696e726320<br /> 806a0a38806b0000 806a0a38806b0000 00000000806b0000 80683c58806b0000<br /> ...<br /> Call Trace:<br /> <br /> Code: a082ffff 03e00008 00601021 00001821 10400005 24840001 80820000 24630001<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Fatal exception in interrupt<br /> <br /> KN04 V2.1k (PC: 0xa0026768, SP: 0x806848e8)<br /> &gt;&gt;<br /> <br /> In this case the pointer in $4 was truncated from 0x980000000203bd00 to<br /> 0x000000000203bd00.<br /> <br /> This may happen when no final console driver has been enabled in the<br /> configuration and consequently the initial console continues being used<br /> late into bootstrap or with an upcoming change that will switch the zs<br /> driver to use a platform device, which in turn will make the console<br /> handover happen only after other kernel threads have already been<br /> started.<br /> <br /> Fix the issue by making the buffer static and initdata, and therefore<br /> placed in the CKSEG0 32-bit compatibility segment, observing that the<br /> console output handler is called with the console lock held, implying<br /> no need for this code to be reentrant. Add an assertion to verify the<br /> buffer actually has been placed in a compatibility segment.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: shared: fix deadlock on shared proxy&amp;#39;s parent removal<br /> <br /> Commit 710abda58055 ("gpio: shared: call gpio_chip::of_xlate() if set")<br /> used the mutex embedded in struct gpio_shared_entry to protect the<br /> offset field which now can be modified after assignment. The critical<br /> section however is too wide and introduced a potential deadlock on the<br /> removal of the shared GPIO proxy&amp;#39;s parent.<br /> <br /> Make the critical section shorter - only protect the offset when it&amp;#39;s<br /> being read.<br /> <br /> While at it: mention the fact that the entry lock is now also used to<br /> protect against concurrent access to the offset field in the structure&amp;#39;s<br /> documentation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs-schemes: delete tried region in regions_rmdirs()<br /> <br /> DAMON sysfs maintains the DAMOS tried region directory objects via a<br /> linked list. When the user requests refresh of the directories, DAMON<br /> sysfs removes all the region directories first, and then generate updated<br /> regions directory on the empty space. The removal function<br /> (damon_sysfs_scheme_regions_rm_dirs()) only puts the kobj objects. <br /> Deletion of the container region object from the linked list is done<br /> inside the kobj release callback function.<br /> <br /> If somehow the callback invocation is delayed, the list will contain<br /> regions list that gonna be freed. If the updated region directories<br /> creation is started in this situation, the list can be corrupted and<br /> use-after-free can happen.<br /> <br /> Because the kobj objects are managed by only DAMON sysfs, the issue cannot<br /> happen in normal situation. But, such delays can be made on kernels that<br /> built with CONFIG_DEBUG_KOBJECT_RELEASE. On the kernel, the issue can<br /> indeed be reproduced like below.<br /> <br /> # damo start --damos_action stat<br /> # cd /sys/kernel/mm/damon/admin/kdamonds/0/<br /> # for i in {1..10}; do echo update_schemes_tried_regions &gt; state; done<br /> # dmesg | grep underflow<br /> [ 89.296152] refcount_t: underflow; use-after-free.<br /> <br /> Fix the issue by removing the region object from the list when<br /> decrementing the reference count.<br /> <br /> Also update damos_sysfs_populate_region_dir() to add the region object to<br /> the list only after the kobject_init_and_add() is success, so that fail of<br /> kobject_init_and_add() is not leaving the deallocated object on the list.<br /> <br /> The issue was discovered [1] by Sashiko.