Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: KVM: Make kvm_get_vcpu_by_cpuid() more robust<br /> <br /> kvm_get_vcpu_by_cpuid() takes a cpuid parameter whose type is int, so<br /> cpuid can be negative. Let kvm_get_vcpu_by_cpuid() return NULL for this<br /> case so as to make it more robust.<br /> <br /> This fix an out-of-bounds access to kvm_arch::phyid_map::phys_map[].

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: move async event work off nvmet-wq<br /> <br /> For target nvmet_ctrl_free() flushes ctrl-&gt;async_event_work.<br /> If nvmet_ctrl_free() runs on nvmet-wq, the flush re-enters workqueue<br /> completion for the same worker:-<br /> <br /> A. Async event work queued on nvmet-wq (prior to disconnect):<br /> nvmet_execute_async_event()<br /> queue_work(nvmet_wq, &amp;ctrl-&gt;async_event_work)<br /> <br /> nvmet_add_async_event()<br /> queue_work(nvmet_wq, &amp;ctrl-&gt;async_event_work)<br /> <br /> B. Full pre-work chain (RDMA CM path):<br /> nvmet_rdma_cm_handler()<br /> nvmet_rdma_queue_disconnect()<br /> __nvmet_rdma_queue_disconnect()<br /> queue_work(nvmet_wq, &amp;queue-&gt;release_work)<br /> process_one_work()<br /> lock((wq_completion)nvmet-wq) async_event_work)<br /> __flush_work()<br /> touch_wq_lockdep_map()<br /> lock((wq_completion)nvmet-wq) release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x660<br /> #2: ffffffff82d4db60 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530<br /> <br /> Workqueue: nvmet-wq nvmet_rdma_release_queue_work [nvmet_rdma]<br /> Call Trace:<br /> __flush_work+0x268/0x530<br /> nvmet_ctrl_free+0x140/0x310 [nvmet]<br /> nvmet_cq_put+0x74/0x90 [nvmet]<br /> nvmet_rdma_free_queue+0x23/0xe0 [nvmet_rdma]<br /> nvmet_rdma_release_queue_work+0x19/0x50 [nvmet_rdma]<br /> process_one_work+0x206/0x660<br /> worker_thread+0x184/0x320<br /> kthread+0x10c/0x240<br /> ret_from_fork+0x319/0x390<br /> <br /> Move async event work to a dedicated nvmet-aen-wq to avoid reentrant<br /> flush on nvmet-wq.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-dw-dma: fix print error log when wait finish transaction<br /> <br /> If an error occurs, the device may not have a current message. In this<br /> case, the system will crash.<br /> <br /> In this case, it&amp;#39;s better to use dev from the struct ctlr (struct spi_controller*).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/cpu: Remove X86_CR4_FRED from the CR4 pinned bits mask<br /> <br /> Commit in Fixes added the FRED CR4 bit to the CR4 pinned bits mask so<br /> that whenever something else modifies CR4, that bit remains set. Which<br /> in itself is a perfectly fine idea.<br /> <br /> However, there&amp;#39;s an issue when during boot FRED is initialized: first on<br /> the BSP and later on the APs. Thus, there&amp;#39;s a window in time when<br /> exceptions cannot be handled.<br /> <br /> This becomes particularly nasty when running as SEV-{ES,SNP} or TDX<br /> guests which, when they manage to trigger exceptions during that short<br /> window described above, triple fault due to FRED MSRs not being set up<br /> yet.<br /> <br /> See Link tag below for a much more detailed explanation of the<br /> situation.<br /> <br /> So, as a result, the commit in that Link URL tried to address this<br /> shortcoming by temporarily disabling CR4 pinning when an AP is not<br /> online yet.<br /> <br /> However, that is a problem in itself because in this case, an attack on<br /> the kernel needs to only modify the online bit - a single bit in RW<br /> memory - and then disable CR4 pinning and then disable SM*P, leading to<br /> more and worse things to happen to the system.<br /> <br /> So, instead, remove the FRED bit from the CR4 pinning mask, thus<br /> obviating the need to temporarily disable CR4 pinning.<br /> <br /> If someone manages to disable FRED when poking at CR4, then<br /> idt_invalidate() would make sure the system would crash&amp;#39;n&amp;#39;burn on the<br /> first exception triggered, which is a much better outcome security-wise.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: dsi: Store driver data before invoking mipi_dsi_host_register<br /> <br /> The call to mipi_dsi_host_register triggers a callback to mtk_dsi_bind,<br /> which uses dev_get_drvdata to retrieve the mtk_dsi struct, so this<br /> structure needs to be stored inside the driver data before invoking it.<br /> <br /> As drvdata is currently uninitialized it leads to a crash when<br /> registering the DSI DRM encoder right after acquiring<br /> the mode_config.idr_mutex, blocking all subsequent DRM operations.<br /> <br /> Fixes the following crash during mediatek-drm probe (tested on Xiaomi<br /> Smart Clock x04g):<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address<br /> 0000000000000040<br /> [...]<br /> Modules linked in: mediatek_drm(+) drm_display_helper cec drm_client_lib<br /> drm_dma_helper drm_kms_helper panel_simple<br /> [...]<br /> Call trace:<br /> drm_mode_object_add+0x58/0x98 (P)<br /> __drm_encoder_init+0x48/0x140<br /> drm_encoder_init+0x6c/0xa0<br /> drm_simple_encoder_init+0x20/0x34 [drm_kms_helper]<br /> mtk_dsi_bind+0x34/0x13c [mediatek_drm]<br /> component_bind_all+0x120/0x280<br /> mtk_drm_bind+0x284/0x67c [mediatek_drm]<br /> try_to_bring_up_aggregate_device+0x23c/0x320<br /> __component_add+0xa4/0x198<br /> component_add+0x14/0x20<br /> mtk_dsi_host_attach+0x78/0x100 [mediatek_drm]<br /> mipi_dsi_attach+0x2c/0x50<br /> panel_simple_dsi_probe+0x4c/0x9c [panel_simple]<br /> mipi_dsi_drv_probe+0x1c/0x28<br /> really_probe+0xc0/0x3dc<br /> __driver_probe_device+0x80/0x160<br /> driver_probe_device+0x40/0x120<br /> __device_attach_driver+0xbc/0x17c<br /> bus_for_each_drv+0x88/0xf0<br /> __device_attach+0x9c/0x1cc<br /> device_initial_probe+0x54/0x60<br /> bus_probe_device+0x34/0xa0<br /> device_add+0x5b0/0x800<br /> mipi_dsi_device_register_full+0xdc/0x16c<br /> mipi_dsi_host_register+0xc4/0x17c<br /> mtk_dsi_probe+0x10c/0x260 [mediatek_drm]<br /> platform_probe+0x5c/0xa4<br /> really_probe+0xc0/0x3dc<br /> __driver_probe_device+0x80/0x160<br /> driver_probe_device+0x40/0x120<br /> __driver_attach+0xc8/0x1f8<br /> bus_for_each_dev+0x7c/0xe0<br /> driver_attach+0x24/0x30<br /> bus_add_driver+0x11c/0x240<br /> driver_register+0x68/0x130<br /> __platform_register_drivers+0x64/0x160<br /> mtk_drm_init+0x24/0x1000 [mediatek_drm]<br /> do_one_initcall+0x60/0x1d0<br /> do_init_module+0x54/0x240<br /> load_module+0x1838/0x1dc0<br /> init_module_from_file+0xd8/0xf0<br /> __arm64_sys_finit_module+0x1b4/0x428<br /> invoke_syscall.constprop.0+0x48/0xc8<br /> do_el0_svc+0x3c/0xb8<br /> el0_svc+0x34/0xe8<br /> el0t_64_sync_handler+0xa0/0xe4<br /> el0t_64_sync+0x198/0x19c<br /> Code: 52800022 941004ab 2a0003f3 37f80040 (29005a80)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: macb: Use dev_consume_skb_any() to free TX SKBs<br /> <br /> The napi_consume_skb() function is not intended to be called in an IRQ<br /> disabled context. However, after commit 6bc8a5098bf4 ("net: macb: Fix<br /> tx_ptr_lock locking"), the freeing of TX SKBs is performed with IRQs<br /> disabled. To resolve the following call trace, use dev_consume_skb_any()<br /> for freeing TX SKBs:<br /> WARNING: kernel/softirq.c:430 at __local_bh_enable_ip+0x174/0x188, CPU#0: ksoftirqd/0/15<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 15 Comm: ksoftirqd/0 Not tainted 7.0.0-rc4-next-20260319-yocto-standard-dirty #37 PREEMPT<br /> Hardware name: ZynqMP ZCU102 Rev1.1 (DT)<br /> pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __local_bh_enable_ip+0x174/0x188<br /> lr : local_bh_enable+0x24/0x38<br /> sp : ffff800082b3bb10<br /> x29: ffff800082b3bb10 x28: ffff0008031f3c00 x27: 000000000011ede0<br /> x26: ffff000800a7ff00 x25: ffff800083937ce8 x24: 0000000000017a80<br /> x23: ffff000803243a78 x22: 0000000000000040 x21: 0000000000000000<br /> x20: ffff000800394c80 x19: 0000000000000200 x18: 0000000000000001<br /> x17: 0000000000000001 x16: ffff000803240000 x15: 0000000000000000<br /> x14: ffffffffffffffff x13: 0000000000000028 x12: ffff000800395650<br /> x11: ffff8000821d1528 x10: ffff800081c2bc08 x9 : ffff800081c1e258<br /> x8 : 0000000100000301 x7 : ffff8000810426ec x6 : 0000000000000000<br /> x5 : 0000000000000001 x4 : 0000000000000001 x3 : 0000000000000000<br /> x2 : 0000000000000008 x1 : 0000000000000200 x0 : ffff8000810428dc<br /> Call trace:<br /> __local_bh_enable_ip+0x174/0x188 (P)<br /> local_bh_enable+0x24/0x38<br /> skb_attempt_defer_free+0x190/0x1d8<br /> napi_consume_skb+0x58/0x108<br /> macb_tx_poll+0x1a4/0x558<br /> __napi_poll+0x50/0x198<br /> net_rx_action+0x1f4/0x3d8<br /> handle_softirqs+0x16c/0x560<br /> run_ksoftirqd+0x44/0x80<br /> smpboot_thread_fn+0x1d8/0x338<br /> kthread+0x120/0x150<br /> ret_from_fork+0x10/0x20<br /> irq event stamp: 29751<br /> hardirqs last enabled at (29750): [] _raw_spin_unlock_irqrestore+0x44/0x88<br /> hardirqs last disabled at (29751): [] _raw_spin_lock_irqsave+0x38/0x98<br /> softirqs last enabled at (29150): [] handle_softirqs+0x504/0x560<br /> softirqs last disabled at (29153): [] run_ksoftirqd+0x44/0x80

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: KVM: Fix base address calculation in kvm_eiointc_regs_access()<br /> <br /> In function kvm_eiointc_regs_access(), the register base address is<br /> caculated from array base address plus offset, the offset is absolute<br /> value from the base address. The data type of array base address is<br /> u64, it should be converted into the "void *" type and then plus the<br /> offset.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Fix deadlock during netdev reset with active connections<br /> <br /> Resolve deadlock that occurs when user executes netdev reset while RDMA<br /> applications (e.g., rping) are active. The netdev reset causes ice<br /> driver to remove irdma auxiliary driver, triggering device_delete and<br /> subsequent client removal. During client removal, uverbs_client waits<br /> for QP reference count to reach zero while cma_client holds the final<br /> reference, creating circular dependency and indefinite wait in iWARP<br /> mode. Skip QP reference count wait during device reset to prevent<br /> deadlock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: scrub: unlock dquot before early return in quota scrub<br /> <br /> xchk_quota_item can return early after calling xchk_fblock_process_error.<br /> When that helper returns false, the function returned immediately without<br /> dropping dq-&gt;q_qlock, which can leave the dquot lock held and risk lock<br /> leaks or deadlocks in later quota operations.<br /> <br /> Fix this by unlocking dq-&gt;q_qlock before the early return.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> futex: Clear stale exiting pointer in futex_lock_pi() retry path<br /> <br /> Fuzzying/stressing futexes triggered:<br /> <br /> WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524<br /> <br /> When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY<br /> and stores a refcounted task pointer in &amp;#39;exiting&amp;#39;.<br /> <br /> After wait_for_owner_exiting() consumes that reference, the local pointer<br /> is never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns a<br /> different error, the bogus pointer is passed to wait_for_owner_exiting().<br /> <br /> CPU0 CPU1 CPU2<br /> futex_lock_pi(uaddr)<br /> // acquires the PI futex<br /> exit()<br /> futex_cleanup_begin()<br /> futex_state = EXITING;<br /> futex_lock_pi(uaddr)<br /> futex_lock_pi_atomic()<br /> attach_to_pi_owner()<br /> // observes EXITING<br /> *exiting = owner; // takes ref<br /> return -EBUSY<br /> wait_for_owner_exiting(-EBUSY, owner)<br /> put_task_struct(); // drops ref<br /> // exiting still points to owner<br /> goto retry;<br /> futex_lock_pi_atomic()<br /> lock_pi_update_atomic()<br /> cmpxchg(uaddr)<br /> *uaddr ^= WAITERS // whatever<br /> // value changed<br /> return -EAGAIN;<br /> wait_for_owner_exiting(-EAGAIN, exiting) // stale<br /> WARN_ON_ONCE(exiting)<br /> <br /> Fix this by resetting upon retry, essentially aligning it with requeue_pi.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> futex: Require sys_futex_requeue() to have identical flags<br /> <br /> Nicholas reported that his LLM found it was possible to create a UaF<br /> when sys_futex_requeue() is used with different flags. The initial<br /> motivation for allowing different flags was the variable sized futex,<br /> but since that hasn&amp;#39;t been merged (yet), simply mandate the flags are<br /> identical, as is the case for the old style sys_futex() requeue<br /> operations.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Fix the descriptor address in __kvm_at_swap_desc()<br /> <br /> Using "(u64 __user *)hva + offset" to get the virtual addresses of S1/S2<br /> descriptors looks really wrong, if offset is not zero. What we want to get<br /> for swapping is hva + offset, not hva + offset*8. ;-)<br /> <br /> Fix it.