Vulnerabilities

The Total Upkeep – WordPress Backup Plugin plus Restore & Migrate by BoldGrid plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the 'wp_ajax_cli_cancel' function in all versions up to, and including, 1.17.1. This makes it possible for unauthenticated attackers to cancel a pending rollback, potentially preventing a WordPress installation from automatically reverting a failed update.

A heap-based buffer overflow in the Kerberos hash parser in hashcat v7.1.2 allows an attacker to cause a denial of service or possibly execute arbitrary code via a crafted Kerberos hash file. The issue affects module_hash_decode in multiple Kerberos-related modules because account_info_len is calculated from untrusted delimiter positions without upper-bound validation before memcpy copies the data into a fixed-size account_info buffer.

A stack-based buffer overflow in mangle_to_hex_lower() and mangle_to_hex_upper() in src/rp_cpu.c in hashcat v7.1.2 allows an attacker to cause a denial of service or possibly execute arbitrary code via a crafted rule file, or via the -j or -k rule options used with password candidates of 128 or more characters. The vulnerability is caused by a bounds check that fails to account for the 2x expansion that occurs when password bytes are converted to hexadecimal.

A heap-based buffer overflow in hex_to_binary in the PKZIP hash parser in hashcat v7.1.2 allows an attacker to cause a denial of service or possibly execute arbitrary code via a crafted PKZIP hash file. The issue affects modules 17200, 17210, 17220, 17225, and 17230. When data_type_enum

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: krb5enc - fix async decrypt skipping hash verification<br /> <br /> krb5enc_dispatch_decrypt() sets req-&gt;base.complete as the skcipher<br /> callback, which is the caller&amp;#39;s own completion handler. When the<br /> skcipher completes asynchronously, this signals "done" to the caller<br /> without executing krb5enc_dispatch_decrypt_hash(), completely bypassing<br /> the integrity verification (hash check).<br /> <br /> Compare with the encrypt path which correctly uses<br /> krb5enc_encrypt_done as an intermediate callback to chain into the<br /> hash computation on async completion.<br /> <br /> Fix by adding krb5enc_decrypt_done as an intermediate callback that<br /> chains into krb5enc_dispatch_decrypt_hash() upon async skcipher<br /> completion, matching the encrypt path&amp;#39;s callback pattern.<br /> <br /> Also fix EBUSY/EINPROGRESS handling throughout: remove<br /> krb5enc_request_complete() which incorrectly swallowed EINPROGRESS<br /> notifications that must be passed up to callers waiting on backlogged<br /> requests, and add missing EBUSY checks in krb5enc_encrypt_ahash_done<br /> for the dispatch_encrypt return value.<br /> <br /> <br /> Unset MAY_BACKLOG on the async completion path so the user won&amp;#39;t<br /> see back-to-back EINPROGRESS notifications.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: server: fix active_num_conn leak on transport allocation failure<br /> <br /> Commit 77ffbcac4e56 ("smb: server: fix leak of active_num_conn in<br /> ksmbd_tcp_new_connection()") addressed the kthread_run() failure<br /> path. The earlier alloc_transport() == NULL path in the same<br /> function has the same leak, is reachable pre-authentication via any<br /> TCP connect to port 445, and was empirically reproduced on UML<br /> (ARCH=um, v7.0-rc7): a small number of forced allocation failures<br /> were sufficient to put ksmbd into a state where every subsequent<br /> connection attempt was rejected for the remainder of the boot.<br /> <br /> ksmbd_kthread_fn() increments active_num_conn before calling<br /> ksmbd_tcp_new_connection() and discards the return value, so when<br /> alloc_transport() returns NULL the socket is released and -ENOMEM<br /> returned without decrementing the counter. Each such failure<br /> permanently consumes one slot from the max_connections pool; once<br /> cumulative failures reach the cap, atomic_inc_return() hits the<br /> threshold on every subsequent accept and every new connection is<br /> rejected. The counter is only reset by module reload.<br /> <br /> An unauthenticated remote attacker can drive the server toward the<br /> memory pressure that makes alloc_transport() fail by holding open<br /> connections with large RFC1002 lengths up to MAX_STREAM_PROT_LEN<br /> (0x00FFFFFF); natural transient allocation failures on a loaded<br /> host produce the same drift more slowly.<br /> <br /> Mirror the existing rollback pattern in ksmbd_kthread_fn(): on the<br /> alloc_transport() failure path, decrement active_num_conn gated on<br /> server_conf.max_connections.<br /> <br /> Repro details: with the patch reverted, forced alloc_transport()<br /> NULL returns leaked counter slots and subsequent connection<br /> attempts -- including legitimate connects issued after the<br /> forced-fail window had closed -- were all rejected with "Limit the<br /> maximum number of connections". With this patch applied, the same<br /> connect sequence produces no rejections and the counter cycles<br /> cleanly between zero and one on every accept.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix dir separator in SMB1 UNIX mounts<br /> <br /> When calling cifs_mount_get_tcon() with SMB1 UNIX mounts,<br /> @cifs_sb-&gt;mnt_cifs_flags needs to be read or updated only after<br /> calling reset_cifs_unix_caps(), otherwise it might end up with missing<br /> CIFS_MOUNT_POSIXACL and CIFS_MOUNT_POSIX_PATHS bits.<br /> <br /> This fixes the wrong dir separator used in paths caused by the missing<br /> CIFS_MOUNT_POSIX_PATHS bit in cifs_sb_info::mnt_cifs_flags.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: validate owner of durable handle on reconnect<br /> <br /> Currently, ksmbd does not verify if the user attempting to reconnect<br /> to a durable handle is the same user who originally opened the file.<br /> This allows any authenticated user to hijack an orphaned durable handle<br /> by predicting or brute-forcing the persistent ID.<br /> <br /> According to MS-SMB2, the server MUST verify that the SecurityContext<br /> of the reconnect request matches the SecurityContext associated with<br /> the existing open.<br /> Add a durable_owner structure to ksmbd_file to store the original opener&amp;#39;s<br /> UID, GID, and account name. and catpure the owner information when a file<br /> handle becomes orphaned. and implementing ksmbd_vfs_compare_durable_owner()<br /> to validate the identity of the requester during SMB2_CREATE (DHnC).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: validate rec-&gt;used in journal-replay file record check<br /> <br /> check_file_record() validates rec-&gt;total against the record size but<br /> never validates rec-&gt;used. The do_action() journal-replay handlers read<br /> rec-&gt;used from disk and use it to compute memmove lengths:<br /> <br /> DeleteAttribute: memmove(attr, ..., used - asize - roff)<br /> CreateAttribute: memmove(..., attr, used - roff)<br /> change_attr_size: memmove(..., used - PtrOffset(rec, next))<br /> <br /> When rec-&gt;used is smaller than the offset of a validated attribute, or<br /> larger than the record size, these subtractions can underflow allowing<br /> us to copy huge amounts of memory in to a 4kb buffer, generally<br /> considered a bad idea overall.<br /> <br /> This requires a corrupted filesystem, which isn&amp;#39;t a threat model the<br /> kernel really needs to worry about, but checking for such an obvious<br /> out-of-bounds value is good to keep things robust, especially on journal<br /> replay<br /> <br /> Fix this up by bounding rec-&gt;used correctly.<br /> <br /> This is much like commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-bounds<br /> read in DeleteIndexEntryRoot") which checked different values in this<br /> same switch statement.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid memory leak in f2fs_rename()<br /> <br /> syzbot reported a f2fs bug as below:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff888127f70830 (size 16):<br /> comm "syz.0.23", pid 6144, jiffies 4294943712<br /> hex dump (first 16 bytes):<br /> 3c af 57 72 5b e6 8f ad 6e 8e fd 33 42 39 03 ff

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: abort on fatal signal during sync init<br /> <br /> When sync init is used and the server exits for some reason (error, crash)<br /> while processing FUSE_INIT, the filesystem creation will hang. The reason<br /> is that while all other threads will exit, the mounting thread (or process)<br /> will keep the device fd open, which will prevent an abort from happening.<br /> <br /> This is a regression from the async mount case, where the mount was done<br /> first, and the FUSE_INIT processing afterwards, in which case there&amp;#39;s no<br /> such recursive syscall keeping the fd open.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: require minimum ACE size in smb_check_perm_dacl()<br /> <br /> Both ACE-walk loops in smb_check_perm_dacl() only guard against an<br /> under-sized remaining buffer, not against an ACE whose declared<br /> `ace-&gt;size` is smaller than the struct it claims to describe:<br /> <br /> if (offsetof(struct smb_ace, access_req) &gt; aces_size)<br /> break;<br /> ace_size = le16_to_cpu(ace-&gt;size);<br /> if (ace_size &gt; aces_size)<br /> break;<br /> <br /> The first check only requires the 4-byte ACE header to be in bounds;<br /> it does not require access_req (4 bytes at offset 4) to be readable.<br /> An attacker who has set a crafted DACL on a file they own can declare<br /> ace-&gt;size == 4 with aces_size == 4, pass both checks, and then<br /> <br /> granted |= le32_to_cpu(ace-&gt;access_req); /* upper loop */<br /> compare_sids(&amp;sid, &amp;ace-&gt;sid); /* lower loop */<br /> <br /> reads access_req at offset 4 (OOB by up to 4 bytes) and ace-&gt;sid at<br /> offset 8 (OOB by up to CIFS_SID_BASE_SIZE + SID_MAX_SUB_AUTHORITIES<br /> * 4 bytes).<br /> <br /> Tighten both loops to require<br /> <br /> ace_size &gt;= offsetof(struct smb_ace, sid) + CIFS_SID_BASE_SIZE<br /> <br /> which is the smallest valid on-wire ACE layout (4-byte header +<br /> 4-byte access_req + 8-byte sid base with zero sub-auths). Also<br /> reject ACEs whose sid.num_subauth exceeds SID_MAX_SUB_AUTHORITIES<br /> before letting compare_sids() dereference sub_auth[] entries.<br /> <br /> parse_sec_desc() already enforces an equivalent check (lines 441-448);<br /> smb_check_perm_dacl() simply grew weaker validation over time.<br /> <br /> Reachability: authenticated SMB client with permission to set an ACL<br /> on a file. On a subsequent CREATE against that file, the kernel<br /> walks the stored DACL via smb_check_perm_dacl() and triggers the<br /> OOB read. Not pre-auth, and the OOB read is not reflected to the<br /> attacker, but KASAN reports and kernel state corruption are<br /> possible.