From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794061580; b=IwWRIa3RFiktp5eW1oJidep/AH7ltvoc9CcXXN5ka58cHSDGqo3m7A7qvis6iOJEq9We CxMFOQW5Pe/CMCTorDu7a+Vo5Lsq7eCMtkBZxS2ClSdFNXO/RFJSmTHbwQ+HLkiUv9ujq OUszy9XPXuQyp4rH42Id1vtGbXkxjUyFFaX5ylT9OJE+4EKa7BV9A8uNNViW3HfIKSzEj cvxPBndQxHgTuKnc0mhPfVTjzuXGKyoZHXk3hFFF8LaUG/YLikOcuMa2uT0t3k6XuVu1h /bElucL4jB7R0eJlqDJeio3sQT/9H2TffuEbkQwXQ+PuIDKymVx9pSH0fXCQjxtMTwg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794061580; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=udSfLXv0uokH4+iqSzrG0cNZG5wLgNsprxe8hs2DuwA=; b=fC9cKcpphaGyNq81wsPFV1MWAm8gWUubpOtOPvUfV2dF/XPcSVeMODh4Fl/jXtb07E8e mrdOuPAndP3QPrSGbC56RefhgdbOsmkDXpBjc3+vDfDWsYu0je0y9SqUACfrr1ZdRf6EG 7LNbC5EZHFoBfLL+d3FAiNFtZB5Wbxy3lbU2DALk4Tyce6Bhbu1MgT4MBltIeMJtewg9D MPDvzyfZe3bKHKdVfHM9kXxvQaNR3BKDVJ9DpEL8rXhfKJotDx2uTYIwLfuPUWxFLXEcf pGU6TNpPiM6kCcRuZHfZwFUzv8SSDXATZYJ/Q83VgDkzTSf4Vdx/M2TFURg3bKv+K1A== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=a7sj9uWQ; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4DD36606A326; Sat, 7 Nov 2026 14:26:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=a7sj9uWQ Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1B851F0089F; Sat, 7 Nov 2026 14:26:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1794061580; bh=udSfLXv0uokH4+iqSzrG0cNZG5wLgNsprxe8hs2DuwA=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=a7sj9uWQ0R0qDuhz/3of+inPnjvUqmGk2iEqhEMbpTbyq6YNBeFupzMimpkPpfRm+ DtG6BdjG8RDIRaqmQjwfUCrhvEarvgbl24msQCcQZwKeq270goRjshbluoARI7yEoZ PJ0vvQcj5/bVv+7/eFpOId3k0tkw9noeOVgzC7ms= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, YANXIN LI , Jan Kara , "Christian Brauner (Amutable)" Subject: [PATCH 6.12 0656/1536] ufs: use u64 for directory size in ufs_last_byte Date: Sat, 7 Nov 2026 08:44:32 -0500 Message-ID: <20261107135015.953774703@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261107134957.653319350@linuxfoundation.org> References: <20261107134957.653319350@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: YANXIN LI commit 1eff23433e73d7da4f9e3529d2701e34962b161f upstream. ufs1_read_inode() and ufs2_read_inode() copy the untrusted 64-bit on-disk size into inode->i_size. ufs_last_byte() then truncates that value to an unsigned int before calculating the valid extent of a directory folio. A directory size of exactly 4 GiB is truncated to zero. In ufs_find_entry(), subtracting the requested record length from that zero forms an endpoint almost 4 GiB beyond the mapped folio. A crafted UFS2 image produces: BUG: KASAN: use-after-free in ufs_find_entry+0x583/0x6e0 [ufs] Read of size 1 ... ufs_find_entry ufs_inode_by_name ufs_lookup __lookup_slow path_lookupat The KASAN classification reflects that the adjacent physical page was free; the source-level operation is an out-of-folio read. A controlled UFS1 test with CONFIG_UFS_FS_WRITE enabled also made ufs_find_entry() return a directory entry from an adjacent anonymous page. unlink() then passed that pointer to ufs_delete_entry(), which cleared the adjacent page's 3 2-bit d_ino. This write result reproduced three out of three times. UFS normally requires a privileged mount path. A relevant boundary is a privileged automounter or image-processing service handling an attacker-supplied filesystem. The write primitive additionally requires UFS1 to be mounted read-write with CONFIG_UFS_FS_WRITE enabled; the read is reachable with read-only UFS2. Keep the intermediate size arithmetic at 64 bits so non-final pages are bounded at PAGE_SIZE. With this change, the same controlled tests reach the real on-disk directory entry and produce no adjacent-page write or KASAN report. A reproducer and full validation logs are available on request. The vulnerable helper is present in v7.2-rc3, v7.1, v6.18.38, v6.12.95, v6.6.111, and upstream master at 1229e2e57a5c. Runtime reproduction and fix validation were performed in an x86-64 QEMU guest running v7.2-rc3 with generic KASAN. Fixes: b71034e5e67d ("[PATCH] ufs: directory and page cache: from blocks to pages") Cc: stable@vger.kernel.org Signed-off-by: YANXIN LI Link: https://patch.msgid.link/20260718190300.867109-1-fadouse@pm.me Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman --- fs/ufs/dir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/ufs/dir.c +++ b/fs/ufs/dir.c @@ -211,7 +211,7 @@ fail: static unsigned ufs_last_byte(struct inode *inode, unsigned long page_nr) { - unsigned last_byte = inode->i_size; + u64 last_byte = inode->i_size; last_byte -= page_nr << PAGE_SHIFT; if (last_byte > PAGE_SIZE)