Vulnerabilidades

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rc: igorplugusb: fix control request setup packet<br /> <br /> Commit eac69475b01f ("media: rc: igorplugusb: heed coherency<br /> rules") changed the control request storage from an embedded struct to<br /> an allocated pointer so it can obey DMA coherency rules.<br /> <br /> However, the driver still passes &amp;ir-&gt;request to usb_fill_control_urb().<br /> That points the URB setup packet at the pointer field itself rather than<br /> at the allocated struct usb_ctrlrequest.<br /> <br /> USB core then interprets pointer bytes as the setup packet. This can<br /> produce an invalid bRequestType and trigger the control direction warning<br /> reported by syzbot:<br /> <br /> usb 2-1: BOGUS control dir, pipe 80003580 doesn&amp;#39;t match bRequestType 0<br /> <br /> Pass ir-&gt;request itself as the setup packet.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: rockchip: teardown bugs and resource leaks<br /> <br /> Address several teardown issues and resource leaks in the driver&amp;#39;s remove<br /> path and error handling:<br /> <br /> 1. Debounce clock reference leak: The debounce clock (bank-&gt;db_clk) is<br /> obtained using of_clk_get() which increments the clock&amp;#39;s reference<br /> count, but clk_put() is never called. Register a devm action to<br /> cleanly release it on unbind. Note that of_clk_get(..., 1) remains<br /> necessary over devm_clk_get() because the DT binding does not define<br /> clock-names, precluding name-based lookup.<br /> <br /> 2. Unregistered chained IRQ handler: The chained IRQ handler is not<br /> disconnected in remove(). If a stray interrupt fires after the driver<br /> is removed, the kernel attempts to execute a stale handler, leading<br /> to a panic. Fix this by clearing the handler in remove().<br /> <br /> 3. IRQ domain leak: The linear IRQ domain and its generic chips are<br /> allocated manually during probe but never removed. Remove the IRQ<br /> domain during driver teardown to free the associated generic chips<br /> and mappings.<br /> <br /> [Bartosz: don&amp;#39;t emit an error message on devres allocation failure]