Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libfs: set SB_I_NOEXEC and SB_I_NODEV by default in init_pseudo()<br /> <br /> Since commit 1e7ab6f67824 ("anon_inode: rework assertions"),<br /> path_noexec() warns when an anonymous-inode file is mmap&amp;#39;d from a<br /> superblock that has not set SB_I_NOEXEC. dma-buf backs its files this<br /> way and never set the flag, so mmap of any exported buffer trips the<br /> warning on a CONFIG_DEBUG_VFS=y kernel:<br /> <br /> WARNING: CPU: 11 PID: 121813 at fs/exec.c:118 path_noexec+0x47/0x50<br /> do_mmap+0x2b5/0x680<br /> vm_mmap_pgoff+0x129/0x210<br /> ksys_mmap_pgoff+0x177/0x240<br /> __x64_sys_mmap+0x33/0x70<br /> <br /> init_pseudo() sets up internal SB_NOUSER mounts that are never<br /> path-reachable. Set both flags here so every pseudo filesystem gets<br /> them by default instead of each caller setting them.<br /> <br /> SB_I_NODEV is inert for unreachable mounts. SB_I_NOEXEC has one<br /> visible effect: an executable mapping of a pseudo-fs fd, such as a<br /> dma-buf, now fails with -EPERM, which is the invariant the assertion<br /> enforces. No in-tree caller maps these executable.<br /> <br /> Reproduce on CONFIG_DEBUG_VFS=y:<br /> <br /> make -C tools/testing/selftests/dmabuf-heaps<br /> sudo ./tools/testing/selftests/dmabuf-heaps/dmabuf-heap -t system

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix double-free in SMB2_close() replay<br /> <br /> A response-bearing attempt can return a replayable error and free its<br /> response buffer. If SMB2_close_init() fails before the next send, cleanup<br /> retains the previous buffer type and frees that response again.<br /> <br /> Reset response bookkeeping before each attempt to prevent the stale free.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb/client: Fix error code in smb2_aead_req_alloc()<br /> <br /> The "*num_sgs" variable is a u32 so "ERR_PTR(*num_sgs)" doesn&amp;#39;t work.<br /> We would have to do something similar to the previous line where it&amp;#39;s<br /> cast to int and then long. However, it&amp;#39;s simpler to store the return in<br /> an int ret variable.<br /> <br /> This bug would eventually result in a crash when dereference the invalid<br /> error pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: amlogic - avoid double cleanup in meson_crypto_probe()<br /> <br /> When meson_allocate_chanlist() fails after a partial allocation, it already<br /> unwinds the allocated chanlist state through its local error path.<br /> meson_crypto_probe() then jump to error_flow and calls<br /> meson_free_chanlist() again, causing the same per-flow resources to be torn<br /> down twice. In the reproduced failure path, the second teardown<br /> re-entered crypto_engine_exit() on an already destroyed worker and KASAN<br /> reported a slab-use-after-free in kthread_destroy_worker().<br /> <br /> Prevent double-free by handling partial allocation failures locally within<br /> meson_allocate_chanlist() and skipping the outer cleanup path.<br /> <br /> The bug was first flagged by an experimental analysis tool we are<br /> developing for kernel memory-management bugs while analyzing<br /> v6.13-rc1. The tool is still under development and is not yet publicly<br /> available.<br /> <br /> The bug was reproduced in a QEMU x86_64 guest booted with KASAN on v7.1,<br /> using the reproducer under tools/testing/meson_crypto_probe. The reproducer<br /> forces the second dma_alloc_attrs() call in the gxl-crypto probe path to<br /> return NULL, making meson_allocate_chanlist() fail after partial<br /> initialization. On the unpatched kernel this reliably triggered a<br /> slab-use-after-free. With this fix applied, the same reproducer no longer<br /> emits any KASAN report and the probe fails cleanly with -ENOMEM.<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in kthread_destroy_worker+0xb2/0xd0<br /> Read of size 8 at addr ff1100010c057a68 by task insmod/265<br /> <br /> CPU: 1 UID: 0 PID: 265 Comm: insmod Tainted: G O 7.1.0-rc2-00376-g810af9adc907-dirty #10 PREEMPT(lazy)<br /> Tainted: [O]=OOT_MODULE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x68/0xa0<br /> print_report+0xcb/0x5e0<br /> ? __virt_addr_valid+0x21d/0x3f0<br /> ? kthread_destroy_worker+0xb2/0xd0<br /> ? kthread_destroy_worker+0xb2/0xd0<br /> kasan_report+0xca/0x100<br /> ? kthread_destroy_worker+0xb2/0xd0<br /> kthread_destroy_worker+0xb2/0xd0<br /> meson_crypto_probe+0x4d0/0xc10 [amlogic_gxl_crypto]<br /> platform_probe+0x99/0x140<br /> really_probe+0x1c6/0x6a0<br /> ? __pfx___device_attach_driver+0x10/0x10<br /> __driver_probe_device+0x248/0x310<br /> ? acpi_driver_match_device+0xb0/0x100<br /> driver_probe_device+0x48/0x210<br /> ? __pfx___device_attach_driver+0x10/0x10<br /> __device_attach_driver+0x160/0x320<br /> bus_for_each_drv+0x104/0x190<br /> ? __pfx_bus_for_each_drv+0x10/0x10<br /> ? _raw_spin_unlock_irqrestore+0x2c/0x50<br /> __device_attach+0x19d/0x3b0<br /> ? __pfx___device_attach+0x10/0x10<br /> ? do_raw_spin_unlock+0x53/0x220<br /> device_initial_probe+0x78/0xa0<br /> bus_probe_device+0x5b/0x130<br /> device_add+0xcfd/0x1430<br /> ? __pfx_device_add+0x10/0x10<br /> ? insert_resource+0x34/0x50<br /> ? lock_release+0xc9/0x290<br /> platform_device_add+0x24e/0x590<br /> ? __pfx_meson_crypto_probe_repro_init+0x10/0x10 [meson_crypto_probe_repro]<br /> meson_crypto_probe_repro_init+0x330/0xff0 [meson_crypto_probe_repro]<br /> do_one_initcall+0xc0/0x450<br /> ? __pfx_do_one_initcall+0x10/0x10<br /> ? _raw_spin_unlock_irqrestore+0x2c/0x50<br /> ? __create_object+0x59/0x80<br /> ? kasan_unpoison+0x27/0x60<br /> do_init_module+0x27b/0x7d0<br /> ? __pfx_do_init_module+0x10/0x10<br /> ? kasan_quarantine_put+0x84/0x1d0<br /> ? kfree+0x32c/0x510<br /> ? load_module+0x561e/0x5ff0<br /> load_module+0x54fe/0x5ff0<br /> ? __pfx_load_module+0x10/0x10<br /> ? security_file_permission+0x20/0x40<br /> ? kernel_read_file+0x23d/0x6e0<br /> ? mmap_region+0x235/0x4a0<br /> ? __pfx_kernel_read_file+0x10/0x10<br /> ? __file_has_perm+0x2c0/0x3e0<br /> init_module_from_file+0x158/0x180<br /> ? __pfx_init_module_from_file+0x10/0x10<br /> ? __lock_acquire+0x45a/0x1ba0<br /> ? idempotent_init_module+0x315/0x610<br /> ? lock_release+0xc9/0x290<br /> ? lock<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: us144mkii: capture_urb_complete: redundant usb_anchor_urb corrupts anchor list on each resubmission<br /> <br /> In capture_urb_complete(), usb_anchor_urb() is called on every<br /> completion callback, but the URB is already anchored from the<br /> initial submission in tascam_trigger_start(). Each redundant call<br /> corrupts the anchor&amp;#39;s doubly-linked list and inflates the URB<br /> refcount. When usb_kill_anchored_urbs() traverses the list during<br /> stream stop / suspend / disconnect, the corrupted list leads to<br /> use-after-free.<br /> <br /> Remove the redundant usb_anchor_urb() from the resubmit path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: spear: Initialize completion before requesting IRQ<br /> <br /> In the report from Jaeyoung Chung:<br /> <br /> "spear_adc_probe() in drivers/iio/adc/spear_adc.c registers its<br /> interrupt handler with devm_request_irq() before it initializes<br /> st-&gt;completion with init_completion(). If an interrupt arrives after<br /> devm_request_irq() and before init_completion(), the handler calls<br /> complete() on an uninitialized completion, causing a kernel panic.<br /> <br /> The probe path, in spear_adc_probe():<br /> <br /> iodev = devm_iio_device_alloc(&amp;pdev-&gt;dev, sizeof(*st)); /* st kzalloc-zeroed */<br /> ...<br /> retval = devm_request_irq(&amp;pdev-&gt;dev, irq, spear_adc_isr, 0,<br /> LPC32XXAD_NAME, st); /* register handler */<br /> ...<br /> init_completion(&amp;st-&gt;completion); /* initialize completion */<br /> <br /> spear_adc_isr() calls complete():<br /> <br /> complete(&amp;st-&gt;completion);<br /> <br /> If the device raises an interrupt before init_completion() runs,<br /> complete() acquires the uninitialized wait.lock and walks the zeroed<br /> task_list in swake_up_locked(). The zeroed task_list makes list_empty()<br /> return false, so swake_up_locked() dereferences a NULL list entry,<br /> triggering a KASAN wild-memory-access."<br /> <br /> Fix the chance of a spurious IRQ causing an uninitialized pointer<br /> dereference by moving init_completion() above devm_request_irq().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse-uring: fix data races on ring-&gt;ready<br /> <br /> On weakly-ordered architectures, the store to fiq-&gt;ops can be<br /> reordered past the store to ring-&gt;ready, allowing a CPU that sees<br /> ring-&gt;ready == true via fuse_uring_ready() to dispatch requests<br /> through a stale fiq-&gt;ops pointer. Upgrade the store to<br /> smp_store_release() and the load in fuse_uring_ready() to<br /> smp_load_acquire() so that the preceding WRITE_ONCE(fiq-&gt;ops, ...)<br /> is visible to any CPU that observes ring-&gt;ready == true.<br /> <br /> Additionally, fuse_uring_do_register() publishes ring-&gt;ready with<br /> WRITE_ONCE() but the fast-path check reads it with a plain load.<br /> This is a marked-vs-unmarked access that KCSAN will flag. Wrap it in<br /> READ_ONCE() to mark it without adding unnecessary ordering.<br /> <br /> Also wrap the fc-&gt;ring load in fuse_uring_ready() in READ_ONCE() to<br /> prevent the compiler from reloading it between the NULL check and the<br /> dereference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: core: fix NULL-deref on adapter registration failure<br /> <br /> If adapter registration ever fails the release callback would trigger a<br /> NULL-pointer dereference as the completion struct has not been<br /> initialised.<br /> <br /> Note that before the offending commit this would instead have resulted<br /> in a minor memory leak of the adapter name.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning<br /> <br /> When CONFIG_DMA_API_DEBUG_SG is enabled, importing a udmabuf into a DRM<br /> driver (e.g. amdgpu for video playback in GNOME Videos / Showtime)<br /> triggers a spurious warning:<br /> <br /> DMA-API: amdgpu 0000:03:00.0: cacheline tracking EEXIST, \<br /> overlapping mappings aren&amp;#39;t supported<br /> WARNING: kernel/dma/debug.c:619 at add_dma_entry+0x473/0x5f0<br /> <br /> The call chain is:<br /> <br /> amdgpu_cs_ioctl<br /> -&gt; amdgpu_ttm_backend_bind<br /> -&gt; dma_buf_map_attachment<br /> -&gt; [udmabuf] map_udmabuf -&gt; get_sg_table<br /> -&gt; dma_map_sgtable(dev, sg, direction, 0) // attrs=0<br /> -&gt; debug_dma_map_sg -&gt; add_dma_entry -&gt; EEXIST<br /> <br /> This happens because udmabuf builds a per-page scatter-gather list via<br /> sg_set_folio(). When begin_cpu_udmabuf() has already created an sg<br /> table mapped for the misc device, and an importer such as amdgpu maps<br /> the same pages for its own device via map_udmabuf(), the DMA debug<br /> infrastructure sees two active mappings whose physical addresses share<br /> cacheline boundaries and warns about the overlap.<br /> <br /> The DMA_ATTR_SKIP_CPU_SYNC flag suppresses this check in<br /> add_dma_entry() because it signals that no CPU cache maintenance is<br /> performed at map/unmap time, making the cacheline overlap harmless.<br /> <br /> All other major dma-buf exporters already pass this flag:<br /> - drm_gem_map_dma_buf() passes DMA_ATTR_SKIP_CPU_SYNC<br /> - amdgpu_dma_buf_map() passes DMA_ATTR_SKIP_CPU_SYNC<br /> <br /> The CPU sync at map/unmap time is also redundant for udmabuf:<br /> begin_cpu_udmabuf() and end_cpu_udmabuf() already perform explicit<br /> cache synchronization via dma_sync_sgtable_for_cpu/device() when CPU<br /> access is requested through the dma-buf interface.<br /> <br /> Pass DMA_ATTR_SKIP_CPU_SYNC to dma_map_sgtable() and<br /> dma_unmap_sgtable() in udmabuf to suppress the spurious warning and<br /> skip the redundant sync.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Avoid WARNING in sva unbind path<br /> <br /> The Intel IOMMU driver allows SVA on devices even if they do not support<br /> PCI/PRI. Commit 39c20c4e83b9 ("iommu/vt-d: Only handle IOPF for SVA when<br /> PRI is supported") modified the SVA bind path to allow this configuration<br /> by skipping IOPF enablement when PRI is missing. However, it failed to<br /> update the unbind path.<br /> <br /> This creates an imbalance: the unbind path attempts to disable IOPF for<br /> a device that never had it enabled, triggering a WARNING in<br /> intel_iommu_disable_iopf():<br /> <br /> WARNING: drivers/iommu/intel/iommu.c:3475 at intel_iommu_disable_iopf+0x4f/0x90d<br /> Call Trace:<br /> <br /> blocking_domain_set_dev_pasid+0x50/0x70<br /> iommu_detach_device_pasid+0x89/0xc0<br /> iommu_sva_unbind_device+0x73/0x150<br /> xe_vm_close_and_put+0x4d2/0x1200 [xe]<br /> <br /> Fix this by bypassing IOPF operations for SVA domains on non-PRI hardware<br /> in both the bind and unbind paths.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: mm: Unconditionally sfence.vma for spurious fault<br /> <br /> Svvptc does not guarantee that it&amp;#39;s safe to just return here. Since we<br /> have already cleared our bit, if, theoretically, the bounded timeframe<br /> for the accessed page to become valid still hasn&amp;#39;t happened after sret,<br /> we could fault again and actually crash.<br /> <br /> Hopefully, these spurious faults should be rare enough that this is an<br /> acceptable slowdown.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not trim a device which is not writeable<br /> <br /> [BUG]<br /> There is a bug report that btrfs/242 can randomly fail with the<br /> following NULL pointer dereference:<br /> <br /> run fstests btrfs/242 at 2026-06-01 10:25:08<br /> BTRFS: device fsid d4d7f234-487c-4787-88e4-47a8b68c9874 devid 1 transid 9 /dev/sdc (8:32) scanned by mount (122609)<br /> BTRFS info (device sdc): first mount of filesystem d4d7f234-487c-4787-88e4-47a8b68c9874<br /> BTRFS info (device sdc): using crc32c checksum algorithm<br /> BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing<br /> BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing<br /> BTRFS info (device sdc): allowing degraded mounts<br /> BTRFS info (device sdc): turning on async discard<br /> BTRFS info (device sdc): enabling free space tree<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=000000013fd6b000<br /> CPU: 4 UID: 0 PID: 122625 Comm: fstrim Not tainted 7.0.10-2-default #1 PREEMPT(full) openSUSE Tumbleweed e9a5f6b24978fba3bf015a992f865837fdfff3dd<br /> Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250812-19.fc42 08/12/2025<br /> pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> pc : btrfs_trim_fs+0x34c/0xa00 [btrfs]<br /> lr : btrfs_trim_fs+0x1f0/0xa00 [btrfs]<br /> Call trace:<br /> btrfs_trim_fs+0x34c/0xa00 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] (P)<br /> btrfs_ioctl_fitrim+0xe8/0x178 [btrfs f02c1d570ceea621c69d302ba75dd61868083840]<br /> btrfs_ioctl+0xdd4/0x2bd8 [btrfs f02c1d570ceea621c69d302ba75dd61868083840]<br /> __arm64_sys_ioctl+0xac/0x108<br /> invoke_syscall.constprop.0+0x5c/0xd0<br /> el0_svc_common.constprop.0+0x40/0xf0<br /> do_el0_svc+0x24/0x40<br /> el0_svc+0x40/0x1d0<br /> el0t_64_sync_handler+0xa0/0xe8<br /> el0t_64_sync+0x1b0/0x1b8<br /> Code: 17ffff83 f94017e0 f9002be0 f9402ea0 (f9400c00)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Also the reporter is very kind to test the following ASSERT() added to<br /> btrfs_trim_free_extents_throttle():<br /> <br /> ASSERT(device-&gt;bdev,<br /> "devid=%llu path=%s dev_state=0x%lx\n",<br /> device-&gt;devid, btrfs_dev_name(device), device-&gt;dev_state);<br /> <br /> And it shows the following output:<br /> <br /> assertion failed: device-&gt;bdev, in extent-tree.c:6630 (devid=2 path=/dev/sdd dev_state=0x82)<br /> <br /> Which means the device-&gt;bdev is NULL, and the dev_state is<br /> BTRFS_DEV_STATE_IN_FS_METADATA | BTRFS_DEV_STATE_ITEM_FOUND, without<br /> BTRFS_DEV_STATE_WRITEABLE flag set.<br /> <br /> [CAUSE]<br /> The pc points to the following call chain:<br /> <br /> btrfs_trim_fs()<br /> |- btrfs_trim_free_extents()<br /> |- btrfs_trim_free_extents_throttle()<br /> |- bdev_max_discard_sectors(device-&gt;bdev)<br /> <br /> So the NULL pointer dereference is caused by device-&gt;bdev being NULL.<br /> <br /> This looks impossible by a quick glance, as just before calling<br /> btrfs_trim_free_extents_throttle(), we have skipped any device that has<br /> BTRFS_DEV_STATE_MISSING flag set.<br /> <br /> However in this particular case, there is a window where the missing<br /> device is later re-scanned, causing btrfs to remove the<br /> BTRFS_DEV_STATE_MISSING flag:<br /> <br /> btrfs_control_ioctl()<br /> |- btrfs_scan_one_device()<br /> |- device_list_add()<br /> |- rcu_assign_pointer(device-&gt;name, name);<br /> | This updates the missing device&amp;#39;s path to the new good path.<br /> |<br /> |- clear_bit(BTRFS_DEV_STATE_MISSING, &amp;device-&gt;dev_state)<br /> This removes the BTRFS_DEV_STATE_MISSING flag.<br /> <br /> This allows the missing device to re-appear and clear the<br /> BTRFS_DEV_STATE_MISSING flag. However the device still does not have<br /> the BTRFS_DEV_STATE_WRITEABLE flag set, nor is its bdev pointer updated.<br /> <br /> The bdev pointer remains NULL, triggering the crash later.<br /> <br /> [FIX]<br /> This is a big de-synchronization between BTRFS_DEV_STATE_MISSING and<br /> device-&gt;bdev pointer, and shows a gap in btrfs&amp;#39;s re-appearing-device<br /> handling.<br /> <br /> The proper handling of re-appearing device will need quite some extra<br /> work, which is out of the context of this small<br /> ---truncated---