Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: add a WRITE_DAC/WRITE_OWNER check to SMB2 SET_INFO SECURITY<br /> <br /> commit cc57232cae23 ("ksmbd: fix FSCTL permission bypass by adding a<br /> permission check for FSCTL_SET_SPARSE") added a fp-&gt;daccess gate to<br /> fsctl_set_sparse and noted that "similar handle-level checks exist in other<br /> functions but are missing here." The SMB2 SET_INFO SECURITY arm is one of<br /> the missing ones, and the most security-relevant: smb2_set_info_sec() calls<br /> set_info_sec() with no per-handle access check.<br /> <br /> set_info_sec() (fs/smb/server/smbacl.c) re-permissions the file: it<br /> rewrites owner/group/mode via notify_change(), rewrites the POSIX ACL via<br /> set_posix_acl(), and on KSMBD_SHARE_FLAG_ACL_XATTR shares removes and<br /> rewrites the Windows security descriptor via ksmbd_vfs_set_sd_xattr().<br /> Every other persistent-mutation arm of the sibling handler<br /> smb2_set_info_file() checks fp-&gt;daccess first (FILE_WRITE_DATA /<br /> FILE_DELETE / FILE_WRITE_EA / FILE_WRITE_ATTRIBUTES); the SECURITY arm —<br /> which mutates the access control itself — is the only one with no gate.<br /> <br /> A client can therefore open a handle with FILE_WRITE_ATTRIBUTES only (no<br /> FILE_WRITE_DAC / FILE_WRITE_OWNER) and use SMB2_SET_INFO with InfoType<br /> SMB2_O_INFO_SECURITY to rewrite the file&amp;#39;s DACL and owner, granting itself<br /> access the handle&amp;#39;s daccess never carried. Unlike the FSCTL data arms this<br /> is a metadata/xattr operation, so there is no FMODE_WRITE VFS backstop —<br /> the missing fp-&gt;daccess check is the entire gate.<br /> <br /> Setting a security descriptor is the WRITE_DAC / WRITE_OWNER operation, so<br /> require at least one of those on the handle before re-permissioning the<br /> file. -EACCES is mapped to STATUS_ACCESS_DENIED by smb2_set_info().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: require source read access for duplicate extents<br /> <br /> FSCTL_DUPLICATE_EXTENTS_TO_FILE passes the source file directly to<br /> vfs_clone_file_range() or vfs_copy_file_range() without checking the SMB<br /> access mask granted to the source handle. A handle opened with attribute<br /> access can consequently be used to copy file contents into an<br /> attacker-readable destination.<br /> <br /> Require FILE_READ_DATA on the source handle before either VFS operation,<br /> matching other ksmbd data-copy paths.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: mask server-provided mode to 07777 in modefromsid<br /> <br /> When modefromsid is active, parse_dacl() applies the server-provided<br /> sub_auth[2] value from the NFS mode SID to cf_mode without masking to<br /> 07777. Apply the correct masking, same as in the read path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: harden POSIX SID length parsing<br /> <br /> posix_info_sid_size() reads sid[1] to obtain the subauthority count,<br /> but its existing boundary check still accepts buffers with only one<br /> remaining byte. Require two bytes before reading sid[1] so all client<br /> paths that reuse the helper reject truncated POSIX SIDs safely.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: Fix next buffer leak in receive_encrypted_standard()<br /> <br /> receive_encrypted_standard() allocates next_buffer before checking<br /> whether the number of compound PDUs already reached MAX_COMPOUND. If<br /> the limit check fails, the function returns immediately and the newly<br /> allocated next_buffer is not assigned to server-&gt;smallbuf/server-&gt;bigbuf,<br /> making it leaked.<br /> <br /> Move the MAX_COMPOUND check before allocating next_buffer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix double-free in SMB2_open() replay<br /> <br /> A response-bearing attempt can return a replayable error and free its<br /> response buffer. If SMB2_open_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 double-free in SMB2_flush() replay<br /> <br /> SMB2_flush() keeps its response buffer bookkeeping across replay<br /> attempts. If a replayable flush response is received and the retry then<br /> fails before cifs_send_recv() stores a replacement response, flush_exit<br /> will free the stale response pointer a second time.<br /> <br /> Reinitialize resp_buftype and rsp_iov at the top of the replay loop so<br /> cleanup only acts on response state produced by the current attempt.<br /> This fixes a double-free without changing replay handling for successful<br /> requests.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix change notify replay double-free<br /> <br /> A response-bearing attempt can return a replayable error and free its<br /> response buffer. If SMB2_notify_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 double-free in SMB2_ioctl() replay<br /> <br /> A response-bearing attempt can return a replayable error and free its<br /> response buffer. If SMB2_ioctl_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 query_info() replay double-free<br /> <br /> A response-bearing attempt can return a replayable error and free its<br /> response buffer. If SMB2_query_info_init() fails before the next send,<br /> cleanup 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 /> proc: protect ptrace_may_access() with exec_update_lock (part 1)<br /> <br /> Fix the easy cases where procfs currently calls ptrace_may_access() without<br /> exec_update_lock protection, where the fix is to simply add the extra lock<br /> or use mm_access():<br /> <br /> - do_task_stat(): grab exec_update_lock<br /> - proc_pid_wchan(): grab exec_update_lock<br /> - proc_map_files_lookup(): use mm_access() instead of get_task_mm()<br /> - proc_map_files_readdir(): use mm_access() instead of get_task_mm()<br /> - proc_ns_get_link(): grab exec_update_lock<br /> - proc_ns_readlink(): grab exec_update_lock

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: pcc: fix use-after-free and double free in _OSC evaluation<br /> <br /> pcc_cpufreq_do_osc() calls acpi_evaluate_object() twice for the<br /> two-phase _OSC negotiation. Between the two calls it freed<br /> output.pointer but left output.length unchanged. Since<br /> acpi_evaluate_object() treats a non-zero length with a non-NULL<br /> pointer as an existing buffer to write into, the second call wrote<br /> into freed memory (use-after-free). The subsequent kfree(output.pointer)<br /> at out_free then freed the same pointer a second time (double free).<br /> <br /> Reset output.pointer to NULL and output.length to ACPI_ALLOCATE_BUFFER<br /> after freeing the first result, so ACPICA allocates a fresh buffer for<br /> each phase independently.