Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/zcrx: fix overshooting recv limit<br /> <br /> It&amp;#39;s reported that sometimes a zcrx request can receive more than was<br /> requested. It&amp;#39;s caused by io_zcrx_recv_skb() adjusting desc-&gt;count for<br /> all received buffers including frag lists, but then doing recursive<br /> calls to process frag list skbs, which leads to desc-&gt;count double<br /> accounting and underflow.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/waitid: always prune wait queue entry in io_waitid_wait()<br /> <br /> For a successful return, always remove our entry from the wait queue<br /> entry list. Previously this was skipped if a cancelation was in<br /> progress, but this can race with another invocation of the wait queue<br /> entry callback.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uio_hv_generic: Let userspace take care of interrupt mask<br /> <br /> Remove the logic to set interrupt mask by default in uio_hv_generic<br /> driver as the interrupt mask value is supposed to be controlled<br /> completely by the user space. If the mask bit gets changed<br /> by the driver, concurrently with user mode operating on the ring,<br /> the mask bit may be set when it is supposed to be clear, and the<br /> user-mode driver will miss an interrupt which will cause a hang.<br /> <br /> For eg- when the driver sets inbound ring buffer interrupt mask to 1,<br /> the host does not interrupt the guest on the UIO VMBus channel.<br /> However, setting the mask does not prevent the host from putting a<br /> message in the inbound ring buffer. So let’s assume that happens,<br /> the host puts a message into the ring buffer but does not interrupt.<br /> <br /> Subsequently, the user space code in the guest sets the inbound ring<br /> buffer interrupt mask to 0, saying “Hey, I’m ready for interrupts”.<br /> User space code then calls pread() to wait for an interrupt.<br /> Then one of two things happens:<br /> <br /> * The host never sends another message. So the pread() waits forever.<br /> * The host does send another message. But because there’s already a<br /> message in the ring buffer, it doesn’t generate an interrupt.<br /> This is the correct behavior, because the host should only send an<br /> interrupt when the inbound ring buffer transitions from empty to<br /> not-empty. Adding an additional message to a ring buffer that is not<br /> empty is not supposed to generate an interrupt on the guest.<br /> Since the guest is waiting in pread() and not removing messages from<br /> the ring buffer, the pread() waits forever.<br /> <br /> This could be easily reproduced in hv_fcopy_uio_daemon if we delay<br /> setting interrupt mask to 0.<br /> <br /> Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1,<br /> there’s a race condition. Once user space empties the inbound ring<br /> buffer, but before user space sets interrupt_mask to 0, the host could<br /> put another message in the ring buffer but it wouldn’t interrupt.<br /> Then the next pread() would hang.<br /> <br /> Fix these by removing all instances where interrupt_mask is changed,<br /> while keeping the one in set_event() unchanged to enable userspace<br /> control the interrupt mask by writing 0/1 to /dev/uioX.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: Fix race condition in RPC handle list access<br /> <br /> The &amp;#39;sess-&gt;rpc_handle_list&amp;#39; XArray manages RPC handles within a ksmbd<br /> session. Access to this list is intended to be protected by<br /> &amp;#39;sess-&gt;rpc_lock&amp;#39; (an rw_semaphore). However, the locking implementation was<br /> flawed, leading to potential race conditions.<br /> <br /> In ksmbd_session_rpc_open(), the code incorrectly acquired only a read lock<br /> before calling xa_store() and xa_erase(). Since these operations modify<br /> the XArray structure, a write lock is required to ensure exclusive access<br /> and prevent data corruption from concurrent modifications.<br /> <br /> Furthermore, ksmbd_session_rpc_method() accessed the list using xa_load()<br /> without holding any lock at all. This could lead to reading inconsistent<br /> data or a potential use-after-free if an entry is concurrently removed and<br /> the pointer is dereferenced.<br /> <br /> Fix these issues by:<br /> 1. Using down_write() and up_write() in ksmbd_session_rpc_open()<br /> to ensure exclusive access during XArray modification, and ensuring<br /> the lock is correctly released on error paths.<br /> 2. Adding down_read() and up_read() in ksmbd_session_rpc_method()<br /> to safely protect the lookup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/ksm: fix flag-dropping behavior in ksm_madvise<br /> <br /> syzkaller discovered the following crash: (kernel BUG)<br /> <br /> [ 44.607039] ------------[ cut here ]------------<br /> [ 44.607422] kernel BUG at mm/userfaultfd.c:2067!<br /> [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI<br /> [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)<br /> [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> [ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460<br /> <br /> <br /> <br /> [ 44.617726] Call Trace:<br /> [ 44.617926] <br /> [ 44.619284] userfaultfd_release+0xef/0x1b0<br /> [ 44.620976] __fput+0x3f9/0xb60<br /> [ 44.621240] fput_close_sync+0x110/0x210<br /> [ 44.622222] __x64_sys_close+0x8f/0x120<br /> [ 44.622530] do_syscall_64+0x5b/0x2f0<br /> [ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 44.623244] RIP: 0033:0x7f365bb3f227<br /> <br /> Kernel panics because it detects UFFD inconsistency during<br /> userfaultfd_release_all(). Specifically, a VMA which has a valid pointer<br /> to vma-&gt;vm_userfaultfd_ctx, but no UFFD flags in vma-&gt;vm_flags.<br /> <br /> The inconsistency is caused in ksm_madvise(): when user calls madvise()<br /> with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,<br /> it accidentally clears all flags stored in the upper 32 bits of<br /> vma-&gt;vm_flags.<br /> <br /> Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and<br /> int are 32-bit wide. This setup causes the following mishap during the &amp;=<br /> ~VM_MERGEABLE assignment.<br /> <br /> VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000&amp;#39;0000. <br /> After ~ is applied, it becomes 0x7fff&amp;#39;ffff unsigned int, which is then<br /> promoted to unsigned long before the &amp; operation. This promotion fills<br /> upper 32 bits with leading 0s, as we&amp;#39;re doing unsigned conversion (and<br /> even for a signed conversion, this wouldn&amp;#39;t help as the leading bit is 0).<br /> &amp; operation thus ends up AND-ing vm_flags with 0x0000&amp;#39;0000&amp;#39;7fff&amp;#39;ffff<br /> instead of intended 0xffff&amp;#39;ffff&amp;#39;7fff&amp;#39;ffff and hence accidentally clears<br /> the upper 32-bits of its value.<br /> <br /> Fix it by changing `VM_MERGEABLE` constant to unsigned long, using the<br /> BIT() macro.<br /> <br /> Note: other VM_* flags are not affected: This only happens to the<br /> VM_MERGEABLE flag, as the other VM_* flags are all constants of type int<br /> and after ~ operation, they end up with leading 1 and are thus converted<br /> to unsigned long with leading 1s.<br /> <br /> Note 2:<br /> After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is<br /> no longer a kernel BUG, but a WARNING at the same place:<br /> <br /> [ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067<br /> <br /> but the root-cause (flag-drop) remains the same.<br /> <br /> [akpm@linux-foundation.org: rust bindgen wasn&amp;#39;t able to handle BIT(), from Miguel]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before release<br /> <br /> The fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can be<br /> NULL even after EPF initialization. Then it is prudent to check that<br /> they have non-NULL values before releasing the channels. Add the checks<br /> in pci_epf_test_clean_dma_chan().<br /> <br /> Without the checks, NULL pointer dereferences happen and they can lead<br /> to a kernel panic in some cases:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050<br /> Call trace:<br /> dma_release_channel+0x2c/0x120 (P)<br /> pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test]<br /> pci_epc_deinit_notify+0x74/0xc0<br /> tegra_pcie_ep_pex_rst_irq+0x250/0x5d8<br /> irq_thread_fn+0x34/0xb8<br /> irq_thread+0x18c/0x2e8<br /> kthread+0x14c/0x210<br /> ret_from_fork+0x10/0x20<br /> <br /> [mani: trimmed the stack trace]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: pru: Fix potential NULL pointer dereference in pru_rproc_set_ctable()<br /> <br /> pru_rproc_set_ctable() accessed rproc-&gt;priv before the IS_ERR_OR_NULL<br /> check, which could lead to a null pointer dereference. Move the pru<br /> assignment, ensuring we never dereference a NULL rproc pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/AER: Avoid NULL pointer dereference in aer_ratelimit()<br /> <br /> When platform firmware supplies error information to the OS, e.g., via the<br /> ACPI APEI GHES mechanism, it may identify an error source device that<br /> doesn&amp;#39;t advertise an AER Capability and therefore dev-&gt;aer_info, which<br /> contains AER stats and ratelimiting data, is NULL.<br /> <br /> pci_dev_aer_stats_incr() already checks dev-&gt;aer_info for NULL, but<br /> aer_ratelimit() did not, leading to NULL pointer dereferences like this one<br /> from the URL below:<br /> <br /> {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0<br /> {1}[Hardware Error]: event severity: corrected<br /> {1}[Hardware Error]: device_id: 0000:00:00.0<br /> {1}[Hardware Error]: vendor_id: 0x8086, device_id: 0x2020<br /> {1}[Hardware Error]: aer_cor_status: 0x00001000, aer_cor_mask: 0x00002000<br /> BUG: kernel NULL pointer dereference, address: 0000000000000264<br /> RIP: 0010:___ratelimit+0xc/0x1b0<br /> pci_print_aer+0x141/0x360<br /> aer_recover_work_func+0xb5/0x130<br /> <br /> [8086:2020] is an Intel "Sky Lake-E DMI3 Registers" device that claims to<br /> be a Root Port but does not advertise an AER Capability.<br /> <br /> Add a NULL check in aer_ratelimit() to avoid the NULL pointer dereference.<br /> Note that this also prevents ratelimiting these events from GHES.<br /> <br /> [bhelgaas: add crash details to commit log]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak<br /> <br /> Struct ff_effect_compat is embedded twice inside<br /> uinput_ff_upload_compat, contains internal padding. In particular, there<br /> is a hole after struct ff_replay to satisfy alignment requirements for<br /> the following union member. Without clearing the structure,<br /> copy_to_user() may leak stack data to userspace.<br /> <br /> Initialize ff_up_compat to zero before filling valid fields.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: fix possible map leak in fastrpc_put_args<br /> <br /> copy_to_user() failure would cause an early return without cleaning up<br /> the fdlist, which has been updated by the DSP. This could lead to map<br /> leak. Fix this by redirecting to a cleanup path on failure, ensuring<br /> that all mapped buffers are properly released before returning.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: simplefb: Fix use after free in simplefb_detach_genpds()<br /> <br /> The pm_domain cleanup can not be devres managed as it uses struct<br /> simplefb_par which is allocated within struct fb_info by<br /> framebuffer_alloc(). This allocation is explicitly freed by<br /> unregister_framebuffer() in simplefb_remove().<br /> Devres managed cleanup runs after the device remove call and thus can no<br /> longer access struct simplefb_par.<br /> Call simplefb_detach_genpds() explicitly from simplefb_destroy() like<br /> the cleanup functions for clocks and regulators.<br /> <br /> Fixes an use after free on M2 Mac mini during<br /> aperture_remove_conflicting_devices() using the downstream asahi kernel<br /> with Debian&amp;#39;s kernel config. For unknown reasons this started to<br /> consistently dereference an invalid pointer in v6.16.3 based kernels.<br /> <br /> [ 6.736134] BUG: KASAN: slab-use-after-free in simplefb_detach_genpds+0x58/0x220<br /> [ 6.743545] Read of size 4 at addr ffff8000304743f0 by task (udev-worker)/227<br /> [ 6.750697]<br /> [ 6.752182] CPU: 6 UID: 0 PID: 227 Comm: (udev-worker) Tainted: G S 6.16.3-asahi+ #16 PREEMPTLAZY<br /> [ 6.752186] Tainted: [S]=CPU_OUT_OF_SPEC<br /> [ 6.752187] Hardware name: Apple Mac mini (M2, 2023) (DT)<br /> [ 6.752189] Call trace:<br /> [ 6.752190] show_stack+0x34/0x98 (C)<br /> [ 6.752194] dump_stack_lvl+0x60/0x80<br /> [ 6.752197] print_report+0x17c/0x4d8<br /> [ 6.752201] kasan_report+0xb4/0x100<br /> [ 6.752206] __asan_report_load4_noabort+0x20/0x30<br /> [ 6.752209] simplefb_detach_genpds+0x58/0x220<br /> [ 6.752213] devm_action_release+0x50/0x98<br /> [ 6.752216] release_nodes+0xd0/0x2c8<br /> [ 6.752219] devres_release_all+0xfc/0x178<br /> [ 6.752221] device_unbind_cleanup+0x28/0x168<br /> [ 6.752224] device_release_driver_internal+0x34c/0x470<br /> [ 6.752228] device_release_driver+0x20/0x38<br /> [ 6.752231] bus_remove_device+0x1b0/0x380<br /> [ 6.752234] device_del+0x314/0x820<br /> [ 6.752238] platform_device_del+0x3c/0x1e8<br /> [ 6.752242] platform_device_unregister+0x20/0x50<br /> [ 6.752246] aperture_detach_platform_device+0x1c/0x30<br /> [ 6.752250] aperture_detach_devices+0x16c/0x290<br /> [ 6.752253] aperture_remove_conflicting_devices+0x34/0x50<br /> ...<br /> [ 6.752343]<br /> [ 6.967409] Allocated by task 62:<br /> [ 6.970724] kasan_save_stack+0x3c/0x70<br /> [ 6.974560] kasan_save_track+0x20/0x40<br /> [ 6.978397] kasan_save_alloc_info+0x40/0x58<br /> [ 6.982670] __kasan_kmalloc+0xd4/0xd8<br /> [ 6.986420] __kmalloc_noprof+0x194/0x540<br /> [ 6.990432] framebuffer_alloc+0xc8/0x130<br /> [ 6.994444] simplefb_probe+0x258/0x2378<br /> ...<br /> [ 7.054356]<br /> [ 7.055838] Freed by task 227:<br /> [ 7.058891] kasan_save_stack+0x3c/0x70<br /> [ 7.062727] kasan_save_track+0x20/0x40<br /> [ 7.066565] kasan_save_free_info+0x4c/0x80<br /> [ 7.070751] __kasan_slab_free+0x6c/0xa0<br /> [ 7.074675] kfree+0x10c/0x380<br /> [ 7.077727] framebuffer_release+0x5c/0x90<br /> [ 7.081826] simplefb_destroy+0x1b4/0x2c0<br /> [ 7.085837] put_fb_info+0x98/0x100<br /> [ 7.089326] unregister_framebuffer+0x178/0x320<br /> [ 7.093861] simplefb_remove+0x3c/0x60<br /> [ 7.097611] platform_remove+0x60/0x98<br /> [ 7.101361] device_remove+0xb8/0x160<br /> [ 7.105024] device_release_driver_internal+0x2fc/0x470<br /> [ 7.110256] device_release_driver+0x20/0x38<br /> [ 7.114529] bus_remove_device+0x1b0/0x380<br /> [ 7.118628] device_del+0x314/0x820<br /> [ 7.122116] platform_device_del+0x3c/0x1e8<br /> [ 7.126302] platform_device_unregister+0x20/0x50<br /> [ 7.131012] aperture_detach_platform_device+0x1c/0x30<br /> [ 7.136157] aperture_detach_devices+0x16c/0x290<br /> [ 7.140779] aperture_remove_conflicting_devices+0x34/0x50<br /> ...

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn&amp;#39;t valid<br /> <br /> Skip the WRMSR and HLT fastpaths in SVM&amp;#39;s VM-Exit handler if the next RIP<br /> isn&amp;#39;t valid, e.g. because KVM is running with nrips=false. SVM must<br /> decode and emulate to skip the instruction if the CPU doesn&amp;#39;t provide the<br /> next RIP, and getting the instruction bytes to decode requires reading<br /> guest memory. Reading guest memory through the emulator can fault, i.e.<br /> can sleep, which is disallowed since the fastpath handlers run with IRQs<br /> disabled.<br /> <br /> BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106<br /> in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu<br /> preempt_count: 1, expected: 0<br /> INFO: lockdep is turned off.<br /> irq event stamp: 30580<br /> hardirqs last enabled at (30579): [] vcpu_run+0x1787/0x1db0 [kvm]<br /> hardirqs last disabled at (30580): [] __schedule+0x1e2/0xed0<br /> softirqs last enabled at (30570): [] fpu_swap_kvm_fpstate+0x44/0x210<br /> softirqs last disabled at (30568): [] fpu_swap_kvm_fpstate+0x44/0x210<br /> CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G U 6.16.0-smp--e6c618b51cfe-sleep #782 NONE<br /> Tainted: [U]=USER<br /> Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x7d/0xb0<br /> __might_resched+0x271/0x290<br /> __might_fault+0x28/0x80<br /> kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm]<br /> kvm_fetch_guest_virt+0x92/0xc0 [kvm]<br /> __do_insn_fetch_bytes+0xf3/0x1e0 [kvm]<br /> x86_decode_insn+0xd1/0x1010 [kvm]<br /> x86_emulate_instruction+0x105/0x810 [kvm]<br /> __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd]<br /> handle_fastpath_invd+0xc4/0x1a0 [kvm]<br /> vcpu_run+0x11a1/0x1db0 [kvm]<br /> kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm]<br /> kvm_vcpu_ioctl+0x578/0x6a0 [kvm]<br /> __se_sys_ioctl+0x6d/0xb0<br /> do_syscall_64+0x8a/0x2c0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f479d57a94b<br /> <br /> <br /> Note, this is essentially a reapply of commit 5c30e8101e8d ("KVM: SVM:<br /> Skip WRMSR fastpath on VM-Exit if next RIP isn&amp;#39;t valid"), but with<br /> different justification (KVM now grabs SRCU when skipping the instruction<br /> for other reasons).