From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E457F2C0287 for ; Mon, 24 Nov 2025 17:45:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764006308; cv=none; b=QQgYr1RV/Y5yzunVpx5uSPQlEz5an3iHxTCpcEb3w+GIcF46j4YVNGN8IG38jHBeiFwqsj/q6hRWsdWgSBnSdXdE7uxDtTL1EtKTh3VwF+K5EdpmhGHJ50aWr+809tvxKOJeoKyytD3Hc3JNZL5X/evS3BDavmMwtcrMg1CrBQg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764006308; c=relaxed/simple; bh=AZXGTBa5OulODmd/k3ldh9ieppBt0TpxXDhl6Iofa3U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QXeUXq5UBpTtJ8yrXqPv6kbGbfPDa9FXImshaZzitsyvw6SihTTDEBM0WHfteohk/SyAoLyHGJvDC85Rel7LlSRF2LcyK1qPDO3DXZ4bZ0ca7HCH6n8kuhfRsvwSROFog2kNwrYT14h3YMGMpCk2P/aprfDAICU/w2vnU5AmHjE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=W2hN6Aqi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="W2hN6Aqi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD516C19423; Mon, 24 Nov 2025 17:45:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764006307; bh=AZXGTBa5OulODmd/k3ldh9ieppBt0TpxXDhl6Iofa3U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=W2hN6AqiFtChMVzEGm2M+QGSehdTpUJBXYexu4PkD1mT7dlefn88KoVqQHsjY9f/Y bbfMLqclYMxBTI0ncDFwwEPm9meJ0GtrvmgjxK2JNQ3bCiAslKbldSiUYQJ8it52cr RdprrdYueUEOV+Pq+OWzrmdxEnH8tclFB/IYurasbyjPeIdQvKg+w1yd0kWVLbz0b7 eTmohKGeDgwRNt+XAj1ZSYH3LTAzfzMaKqExXkg1gEGl1h5CsQKwkKaOue9vkkoSvB xwcpS9/dD9IVWdW4IjJCDOWRjQ35A7FaU2dIx/ILXLYmvme3N893liHi/ZmustSYNt ZSk1XKE3FcSKw== From: Sasha Levin To: stable@vger.kernel.org Cc: "Darrick J. Wong" , Christoph Hellwig , Carlos Maiolino , Sasha Levin Subject: [PATCH 6.17.y 2/2] xfs: fix out of bounds memory read error in symlink repair Date: Mon, 24 Nov 2025 12:45:03 -0500 Message-ID: <20251124174503.4167383-2-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251124174503.4167383-1-sashal@kernel.org> References: <2025112457-shining-trough-db05@gregkh> <20251124174503.4167383-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Darrick J. Wong" [ Upstream commit 678e1cc2f482e0985a0613ab4a5bf89c497e5acc ] xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that. Cc: stable@vger.kernel.org # v6.10 Fixes: 2651923d8d8db0 ("xfs: online repair of symbolic links") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin --- fs/xfs/scrub/symlink_repair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/xfs/scrub/symlink_repair.c b/fs/xfs/scrub/symlink_repair.c index 5902398185a89..df629892462fe 100644 --- a/fs/xfs/scrub/symlink_repair.c +++ b/fs/xfs/scrub/symlink_repair.c @@ -184,7 +184,7 @@ xrep_symlink_salvage_inline( sc->ip->i_disk_size == 1 && old_target[0] == '?') return 0; - nr = min(XFS_SYMLINK_MAXLEN, xfs_inode_data_fork_size(ip)); + nr = min(XFS_SYMLINK_MAXLEN, ifp->if_bytes); memcpy(target_buf, ifp->if_data, nr); return nr; } -- 2.51.0