Vulnerabilidades

*** 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 /> 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 /> 9p: avoid putting oldfid in p9_client_walk() error path<br /> <br /> When p9_client_walk() is called with clone set to false, fid aliases<br /> oldfid. If the walk subsequently fails after the request has been sent,<br /> the error path jumps to clunk_fid, which currently calls p9_fid_put(fid)<br /> unconditionally.<br /> <br /> This drops a reference to oldfid even though ownership of oldfid remains<br /> with the caller. If this is the last reference, oldfid can be clunked and<br /> destroyed while the caller still expects it to be valid. A later use or<br /> put of oldfid can then trigger a use-after-free or refcount underflow.<br /> <br /> Fix this by only putting fid in the clunk_fid error path when it does not<br /> alias oldfid, matching the existing guard in the error path below.<br /> <br /> This can be triggered when a multi-component walk is split into multiple<br /> p9_client_walk() calls and a later non-cloning walk fails. A reproducer<br /> and refcount warning logs are available on request.

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

*** 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 /> 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 /> NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr<br /> <br /> nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a<br /> netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately<br /> calls strrchr(buf, &amp;#39;.&amp;#39;) to locate the port separator. Both decodes<br /> use xdr_stream_decode_string_dup(), and the current code checks only<br /> "nlen

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix out-of-bounds read in smb_check_perm_dacl()<br /> <br /> The permission-check ACE walk in smb_check_perm_dacl() validates the ACE<br /> header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it<br /> never checks that ace-&gt;size is actually large enough to contain<br /> num_subauth sub-authorities before compare_sids() dereferences them.<br /> <br /> CIFS_SID_BASE_SIZE covers the SID header up to but excluding the<br /> sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header,<br /> so the existing guards only guarantee the 8-byte SID base, i.e. zero<br /> sub-authorities. compare_sids() then reads ace-&gt;sid.sub_auth[i] for<br /> i num_subauth, ace-&gt;sid.num_subauth). The local<br /> comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid()<br /> result) always have at least one sub-authority, and an attacker controls<br /> the ACE revision and authority bytes (which lie within the in-bounds SID<br /> base), so they can match one of those SIDs and force the sub_auth read.<br /> <br /> A crafted ACE with size == 16 and num_subauth &gt;= 1 placed at the tail of<br /> the security descriptor therefore causes a heap out-of-bounds read of up<br /> to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd<br /> allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr()<br /> into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in<br /> ndr_decode_v4_ntacl()), so the read lands past the allocation. The<br /> malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL<br /> is not normalised before being written to the security.NTACL xattr) and<br /> the read fires on a subsequent SMB2_CREATE access check, making this<br /> reachable by an authenticated client on a share that uses ACL xattrs.<br /> <br /> Add the missing num_subauth-versus-ace_size check, mirroring the<br /> identical guards already present in the sibling parsers parse_dacl() and<br /> smb_inherit_dacl().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Fix SECINFO_NO_NAME decode error cleanup<br /> <br /> nfsd4_decode_secinfo_no_name() currently initializes sin_exp after<br /> decoding sin_style. If the XDR stream is truncated, the decoder returns<br /> nfserr_bad_xdr before sin_exp is initialized.<br /> <br /> Since commit 3fdc54646234 ("NFSD: Reduce amount of struct<br /> nfsd4_compoundargs that needs clearing"), the inline iops array is not<br /> cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore<br /> leave sin_exp holding stale union contents from a previous operation.<br /> <br /> The error response path still invokes nfsd4_secinfo_no_name_release(),<br /> which calls exp_put() on a non-NULL sin_exp.<br /> <br /> Initialize sin_exp before the first failable decode step, matching<br /> nfsd4_decode_secinfo().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix posix_acl leak on SETACL decode failure<br /> <br /> nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each<br /> call nfs_stream_decode_acl() twice, first for NFS_ACL and then for<br /> NFS_DFACL. Each successful call transfers ownership of a freshly<br /> allocated posix_acl into argp-&gt;acl_access or argp-&gt;acl_default. If<br /> the first call succeeds but the second fails, the decoder returns<br /> false and argp-&gt;acl_access is left dangling.<br /> <br /> ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and<br /> ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle.<br /> Both only call fh_put() and have no knowledge of the ACL fields on<br /> argp. The posix_acl_release() pairs sat at the out: labels inside<br /> nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process()<br /> skips pc_func when pc_decode returns false, so that cleanup is<br /> unreachable on decode failure:<br /> <br /> svc_process_common()<br /> pc_decode() /* decode_setaclargs: false */<br /> /* pc_func skipped */<br /> pc_release() /* fh_put only -- ACLs leaked */<br /> <br /> The orphaned posix_acl is leaked for the lifetime of the server.<br /> <br /> Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(),<br /> which release both argp-&gt;acl_access and argp-&gt;acl_default in addition<br /> to fh_put(), and wiring them as pc_release for their respective SETACL<br /> procedures. pc_release runs on every path svc_process() takes after<br /> decode, including decode failure, so the posix_acl_release() pairs are<br /> removed from the proc functions&amp;#39; out: labels to keep ownership in one<br /> place. This matches the existing release_getacl() pattern used by<br /> the sibling GETACL procedures.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix posix_acl leak and ignored error in nfsd4_create_file<br /> <br /> nfsd4_create_file() has two bugs in its ACL handling:<br /> <br /> The return value of nfsd4_acl_to_attr() is silently discarded. When<br /> the NFSv4-to-POSIX ACL conversion fails (e.g., -EINVAL for<br /> unsupported ACE types), the file is created without any ACL and the<br /> client receives NFS4_OK. This violates RFC 7530/8881 which require<br /> the server to reject unsupported attributes on CREATE.<br /> <br /> When start_creating() fails after ACL attributes have been populated<br /> in attrs (either via nfsd4_acl_to_attr or via ownership transfer from<br /> open-&gt;op_dpacl/op_pacl), the function jumps to out_write which skips<br /> nfsd_attrs_free(). The posix_acl allocations are leaked. A client<br /> can trigger this repeatedly with OPEN(CREATE), ACL attributes, and an<br /> invalid filename (e.g., longer than NAME_MAX).<br /> <br /> Fix both by capturing the nfsd4_acl_to_attr() return value and by<br /> changing the early error paths to jump to out instead of out_write.<br /> Initialize child to ERR_PTR(-EINVAL) so that end_creating() is safe<br /> to call even if start_creating() was never reached.