Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/mmcid: Fix OOB clear_bit when CID is MM_CID_UNSET in fixup path<br /> <br /> In mm_cid_fixup_cpus_to_tasks(), when rq-&gt;curr has the target mm and<br /> mm_cid.active is set, the CID is checked with cid_in_transit() before<br /> setting the transition bit. In per-CPU mode a newly forked or exec&amp;#39;d<br /> task can be running with mm_cid.cid == MM_CID_UNSET because CIDs are<br /> assigned lazily on schedule-in. With cid_in_transit() the guard passes<br /> for MM_CID_UNSET (no transit bit), converts it to MM_CID_UNSET |<br /> MM_CID_TRANSIT and stores it back; later mm_cid_schedout() feeds this<br /> to clear_bit() with MM_CID_UNSET as the bit number, triggering an<br /> out-of-bounds write.<br /> <br /> Symptoms: this is genuine memory corruption, but a bounded out-of-bounds<br /> write, not an arbitrary one. MM_CID_UNSET is the fixed sentinel BIT(31),<br /> so once the bad value reaches mm_cid_schedout() the cid_from_transit_cid()<br /> strip leaves MM_CID_UNSET, which fails the "cid clear_bit(MM_CID_UNSET,<br /> mm_cidmask(mm)). The cid bitmap is embedded in the mm_struct slab object<br /> (after cpu_bitmap and mm_cpus_allowed) and is only num_possible_cpus()<br /> bits wide, so clearing bit 31 is a deterministic OOB bit-clear at a<br /> fixed offset of 2^31 / 8 == 256 MiB past the bitmap base. The address is<br /> not attacker-influenced (fixed sentinel -&gt; fixed offset) and the op only<br /> clears a single bit; what sits 256 MiB further along the direct map is<br /> whatever kernel object happens to live there, so this corrupts one bit of<br /> unpredictable kernel memory -- it is not an arbitrary-address or<br /> arbitrary-value write.<br /> <br /> It triggers only in per-CPU CID mode, when a CPU is running an active<br /> task of the target mm whose cid is still MM_CID_UNSET -- the<br /> fork()/execve() window before that task&amp;#39;s next schedule-in assigns it a<br /> real CID -- and a per-CPU -&gt; per-task fixup walks over it (the mode<br /> fallback driven by a thread exit, sched_mm_cid_exit(), or by the deferred<br /> max_cids recompute in mm_cid_work_fn()).<br /> <br /> In practice syzkaller surfaced it as a KASAN use-after-free reported in<br /> __schedule -&gt; mm_cid_switch_to, where the offending clear_bit() is inlined<br /> via mm_cid_schedout() -&gt; mm_drop_cid().<br /> <br /> Guard the transition-bit assignment against MM_CID_UNSET, in addition to<br /> the existing cid_in_transit() check, so the bit is only set on a genuine<br /> task-owned CID. A CPU-owned (MM_CID_ONCPU) CID of a running active task<br /> is handled by the cid_on_cpu(pcp-&gt;cid) branch above and never reaches<br /> this path, so excluding MM_CID_UNSET (and the already-transitioning case)<br /> is sufficient.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pNFS: Fix use-after-free in pnfs_update_layout()<br /> <br /> When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(),<br /> the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds,<br /> pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(),<br /> which still references &amp;#39;lo&amp;#39;. This results in a use-after-free when the<br /> tracepoint accesses lo&amp;#39;s fields.<br /> <br /> Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done<br /> <br /> tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to<br /> crypto_aead_decrypt(req) without taking a reference on the netns, unlike<br /> the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously<br /> (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs<br /> tipc_aead_decrypt_done() later. If the bearer&amp;#39;s netns is torn down in the<br /> meantime, cleanup_net() -&gt; tipc_exit_net() -&gt; tipc_crypto_stop() frees the<br /> per-netns tipc_crypto, and the completion then reads it:<br /> tipc_aead_decrypt_done() dereferences aead-&gt;crypto-&gt;stats and<br /> aead-&gt;crypto-&gt;net, and tipc_crypto_rcv_complete() dereferences<br /> aead-&gt;crypto-&gt;aead[] and the node table -- reading freed memory.<br /> <br /> Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO):<br /> <br /> BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999)<br /> Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51<br /> Workqueue: events_unbound<br /> Call Trace:<br /> tipc_aead_decrypt_done (net/tipc/crypto.c:999)<br /> process_one_work (kernel/workqueue.c:3314)<br /> worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)<br /> kthread (kernel/kthread.c:436)<br /> ret_from_fork (arch/x86/kernel/process.c:158)<br /> ret_from_fork_asm (arch/x86/entry/entry_64.S:245)<br /> <br /> Allocated by task 169:<br /> __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415)<br /> tipc_crypto_start (net/tipc/crypto.c:1502)<br /> tipc_init_net (net/tipc/core.c:72)<br /> ops_init (net/core/net_namespace.c:137)<br /> setup_net (net/core/net_namespace.c:446)<br /> copy_net_ns (net/core/net_namespace.c:579)<br /> create_new_namespaces (kernel/nsproxy.c:132)<br /> __x64_sys_unshare (kernel/fork.c:3316)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)<br /> <br /> Freed by task 8:<br /> kfree (mm/slub.c:6566)<br /> tipc_exit_net (net/tipc/core.c:119)<br /> cleanup_net (net/core/net_namespace.c:704)<br /> process_one_work (kernel/workqueue.c:3314)<br /> kthread (kernel/kthread.c:436)<br /> <br /> This is the same class of bug that commit e279024617134 ("net/tipc: fix<br /> slab-use-after-free Read in tipc_aead_encrypt_done") fixed for the encrypt<br /> side. The encrypt path takes maybe_get_net(aead-&gt;crypto-&gt;net) before<br /> crypto_aead_encrypt() and drops it with put_net() on the synchronous<br /> return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY<br /> return keeps the reference for the async callback to release. The decrypt<br /> path was left without the equivalent guard.<br /> <br /> Mirror the encrypt-side fix on the decrypt path: take a net reference<br /> before crypto_aead_decrypt() (failing with -ENODEV and the matching<br /> bearer put if it cannot be acquired), keep it across the<br /> -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the<br /> synchronous success/error return and at the end of<br /> tipc_aead_decrypt_done().<br /> <br /> Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is<br /> flooded with crafted encrypted frames from an unknown peer (driving the<br /> cluster-key decrypt path) while the bearer&amp;#39;s netns is repeatedly torn<br /> down. The completion must run asynchronously to outlive<br /> tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts<br /> synchronously, so the async path was exercised via cryptd offload. The<br /> unguarded aead-&gt;crypto dereference in tipc_aead_decrypt_done() is the<br /> unpatched upstream path; tipc_aead_decrypt() still lacks<br /> maybe_get_net(aead-&gt;crypto-&gt;net), so the completion can outlive the free<br /> on any config where crypto_aead_decrypt() goes async.<br /> <br /> Found by 0sec automated security-research tooling (https://0sec.ai).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-cgroup: fix UAF in __blkcg_rstat_flush()<br /> <br /> When multiple blkgs in the same blkcg are released concurrently,<br /> a use-after-free can occur. The race happens when one blkg&amp;#39;s<br /> __blkcg_rstat_flush() removes another blkg&amp;#39;s iostat entries via<br /> llist_del_all(). The second blkg sees an empty list and proceeds<br /> to free itself while the first is still iterating over its entries.<br /> <br /> Move the flush from __blkg_release() (RCU callback) to blkg_release()<br /> (before call_rcu). This ensures the RCU grace period waits for any<br /> concurrent flush&amp;#39;s rcu_read_lock() section to complete before freeing.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hdlc_ppp: sync per-proto timers before freeing hdlc state<br /> <br /> Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp<br /> registers a timer via timer_setup(). That struct ppp is the<br /> hdlc-&gt;state allocation, which detach_hdlc_protocol() frees with kfree()<br /> in both teardown paths: unregister_hdlc_device() and the re-attach inside<br /> attach_hdlc_protocol().<br /> <br /> The ppp proto never registered a .detach callback, so<br /> detach_hdlc_protocol() performs no timer synchronization before the<br /> kfree(). The only cancel, timer_delete(&amp;proto-&gt;timer) in ppp_cp_event(),<br /> is partial (it does not wait for a running callback) and only runs on the<br /> -&gt;CLOSED transition; ppp_stop()/ppp_close() do not sync either. A<br /> ppp_timer callback already executing (blocked on ppp-&gt;lock) survives the<br /> kfree and then dereferences proto-&gt;state / ppp-&gt;lock in freed memory,<br /> leading to a use-after-free.<br /> <br /> Fix this by adding a .detach helper that calls timer_shutdown_sync() on<br /> every per-proto timer. detach_hdlc_protocol() invokes proto-&gt;detach(dev)<br /> before kfree(hdlc-&gt;state), so timer_shutdown_sync()<br /> now runs on both free paths.<br /> timer_shutdown_sync() is used instead of timer_delete_sync() because the<br /> keepalive path re-arms the timer through add_timer()/mod_timer() and<br /> shutdown blocks any re-activation during teardown.<br /> <br /> Initialize the per-protocol timers in ppp_ioctl() when the protocol is<br /> attached, and remove the now-redundant timer_setup() from ppp_start(), so<br /> that the timers are initialized exactly once at attach time and<br /> ppp_timer_release() never operates on uninitialized timer_list<br /> structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so<br /> struct ppp&amp;#39;s protos[i].timer is uninitialized garbage until the first<br /> timer_setup(); without this init-at-attach, attaching the PPP protocol<br /> without ever bringing the device up would leave timer_shutdown_sync()<br /> operating on uninitialized memory in .detach. Moving the init out of<br /> ppp_start() (which only runs on NETDEV_UP) into the attach path makes the<br /> initialization unconditional and avoids initializing the same timer_list<br /> twice.<br /> <br /> This bug was found by static analysis.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path<br /> <br /> In sev_dbg_crypt(), the per-iteration transfer length is bounded by<br /> the source page offset (PAGE_SIZE - s_off) but not by the destination<br /> page offset (PAGE_SIZE - d_off). When d_off &gt; s_off, the encrypt<br /> path (__sev_dbg_encrypt_user) performs a read-modify-write using a<br /> single-page intermediate buffer (dst_tpage):<br /> <br /> 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off &amp; 15), 16)<br /> before issuing the PSP command. If len + (d_off &amp; 15) &gt; PAGE_SIZE,<br /> the PSP writes beyond the end of the 4096-byte dst_tpage allocation.<br /> <br /> 2. The subsequent memcpy()/copy_from_user() into<br /> page_address(dst_tpage) + (d_off &amp; 15) of &amp;#39;len&amp;#39; bytes overflows<br /> by up to 15 bytes under the same condition.<br /> <br /> Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE -<br /> the PSP is instructed to write round_up(4097, 16) = 4112 bytes to<br /> a 4096-byte buffer.<br /> <br /> Fix by also bounding len by (PAGE_SIZE - d_off), the same check that<br /> sev_send_update_data() already performs for its single-page guest<br /> region.<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd]<br /> Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214<br /> <br /> CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY<br /> Tainted: [U]=USER, [W]=WARN<br /> Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x54/0x70<br /> print_report+0xbc/0x260<br /> kasan_report+0xa2/0xd0<br /> kasan_check_range+0x25f/0x2c0<br /> __asan_memcpy+0x40/0x70<br /> sev_dbg_crypt+0x993/0xd10 [kvm_amd]<br /> sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd]<br /> kvm_vm_ioctl+0x65d/0x6d0 [kvm]<br /> __se_sys_ioctl+0xb2/0x100<br /> do_syscall_64+0xe8/0x870<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb<br /> memcg:ff11000112827d82<br /> flags: 0x1400000000000000(node=1|zone=1)<br /> raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000<br /> raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc<br /> ^<br /> ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc<br /> ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc<br /> ==================================================================<br /> Disabling lock debugging due to kernel taint<br /> <br /> [sean: add sample KASAN splat, Fixes, and stable@]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var<br /> <br /> info-&gt;var, a framebuffer&amp;#39;s current mode, is expected to have a matching<br /> entry in info-&gt;modelist. var_to_display() relies on this and treats a<br /> failed fb_match_mode() as "This should not happen". fb_set_var() keeps it<br /> true by adding the mode to the list on every change, and<br /> do_register_framebuffer() does the same at registration.<br /> <br /> store_modes() replaces the modelist from userspace. fb_new_modelist()<br /> validates the new modes but does not check that info-&gt;var still has a<br /> match. It relies on fbcon_new_modelist() to re-point consoles, but that<br /> only handles consoles mapped to the framebuffer. With fbcon unbound there<br /> are none, so info-&gt;var is left describing a mode that is no longer in the<br /> list.<br /> <br /> A later console takeover runs var_to_display(), where fb_match_mode()<br /> returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it<br /> to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode.<br /> <br /> Keep the current mode in the list in fb_new_modelist(), the same way<br /> fb_set_var() does.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: release layout stid on setlease failure<br /> <br /> nfs4_alloc_stid() publishes the new stid into cl-&gt;cl_stateids via<br /> idr_alloc_cyclic() under cl_lock before returning to<br /> nfsd4_alloc_layout_stateid(). When nfsd4_layout_setlease() then<br /> fails, the error path frees the layout stateid directly with<br /> kmem_cache_free() without ever calling idr_remove(), leaving the<br /> IDR slot pointing at freed slab memory. Any subsequent IDR walker<br /> (states_show, client teardown) dereferences the dangling pointer.<br /> <br /> The correct teardown for an IDR-published stid is nfs4_put_stid(),<br /> which removes the IDR slot under cl_lock, dispatches sc_free<br /> (nfsd4_free_layout_stateid) to release ls-&gt;ls_file via<br /> nfsd4_close_layout(), and drops the nfs4_file reference in its<br /> tail.<br /> <br /> A second issue blocks that switch: nfsd4_free_layout_stateid()<br /> unconditionally inspects ls-&gt;ls_fence_work via<br /> delayed_work_pending() under ls_lock, but<br /> INIT_DELAYED_WORK(&amp;ls-&gt;ls_fence_work, ...) currently runs only<br /> after the setlease call. On the setlease-failure path the<br /> destructor would touch an uninitialized delayed_work.<br /> <br /> nfsd4_alloc_layout_stateid()<br /> nfs4_alloc_stid() /* idr_alloc_cyclic under cl_lock */<br /> nfsd4_layout_setlease() /* fails */<br /> nfs4_put_stid()<br /> nfsd4_free_layout_stateid()<br /> delayed_work_pending(&amp;ls-&gt;ls_fence_work) /* needs INIT */<br /> nfsd4_close_layout() /* nfsd_file_put(ls-&gt;ls_file) */<br /> put_nfs4_file()<br /> <br /> Fix by hoisting the ls_fenced / ls_fence_delay / INIT_DELAYED_WORK<br /> initialization above the nfsd4_layout_setlease() call, and replace<br /> the manual nfsd_file_put + put_nfs4_file + kmem_cache_free cleanup<br /> with a single nfs4_put_stid(stp).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: core: fix adapter registration race<br /> <br /> Adapters can be looked up based on their id using i2c_get_adapter()<br /> which takes a reference to the embedded struct device.<br /> <br /> Make sure that the adapter (including its struct device) has been<br /> initialised before adding it to the IDR to avoid accessing uninitialised<br /> data which could, for example, lead to NULL-pointer dereferences or<br /> use-after-free.<br /> <br /> Note that the i2c-dev chardev, which is registered from a bus notifier,<br /> currently uses i2c_get_adapter() so the adapter needs to be added to the<br /> IDR before registration.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: omap2: fix use-after-free in omapfb_mmap<br /> <br /> omapfb_mmap() has a race condition with OMAPFB_SETUP_PLANE ioctl that<br /> can lead to use-after-free:<br /> <br /> The fb_mmap() entry point holds mm_lock but not lock (fb_info-&gt;lock),<br /> while ioctl handlers like OMAPFB_SETUP_PLANE hold lock but not mm_lock.<br /> This allows concurrent execution.<br /> <br /> In omapfb_mmap():<br /> 1. rg = omapfb_get_mem_region(ofbi-&gt;region); // Get old region ref<br /> 2. start = omapfb_get_region_paddr(ofbi); // Read from NEW region<br /> 3. len = fix-&gt;smem_len; // Read from NEW region<br /> 4. vm_iomap_memory(vma, start, len); // Map NEW region memory<br /> 5. atomic_inc(&amp;rg-&gt;map_count); // Increment OLD region!<br /> <br /> Concurrently, OMAPFB_SETUP_PLANE can:<br /> - Reassign ofbi-&gt;region = new_rg<br /> - Update fix-&gt;smem_len<br /> - OMAPFB_SETUP_MEM then checks NEW region&amp;#39;s map_count (0!) and frees it<br /> <br /> This leaves userspace with a mapping to freed physical memory.<br /> <br /> The fix is to read all required values (start, len) from the same<br /> region reference (rg) that will have its map_count incremented,<br /> preventing the region from being freed while still mapped.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()<br /> <br /> When fbcon_do_set_font() fails (e.g., due to a memory allocation failure<br /> inside vc_resize() under heavy memory pressure), it jumps to the `err_out`<br /> label to roll back the console state. However, the current rollback logic<br /> forgets to restore the `hi_font` state, leading to a severe state machine<br /> corruption.<br /> <br /> Earlier in the function, `set_vc_hi_font()` might be called to change<br /> `vc-&gt;vc_hi_font_mask` and mutate the screen buffer. If `vc_resize()`<br /> subsequently fails, the `err_out` path restores `vc_font.charcount`<br /> but entirely skips rolling back the `vc_hi_font_mask` and the screen<br /> buffer.<br /> <br /> This mismatch leaves the terminal in a desynchronized state. Because<br /> `vc_hi_font_mask` remains set, the VT subsystem will still accept<br /> character indices greater than 255 from userspace and write them to the<br /> screen buffer. Subsequent rendering calls (e.g., `fbcon_putcs()`) will<br /> then use these inflated indices to access the reverted, 256-character<br /> font array, leading to a deterministic out-of-bounds read and potential<br /> kernel memory disclosure.<br /> <br /> Fix this by adding the missing rollback logic for the `hi_font` mask<br /> and screen buffer in the error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs: serialize volume label accesses<br /> <br /> Protect vol-&gt;volume_label with a mutex and snaphost the label before<br /> copy_to_user. This prevent a use-after-free when FS_IOC_SETFSLABEL<br /> replaces the vol-&gt;volume_label and FS_IOC_GETTSLABEL reads it<br /> concurrently.