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 49DAE2236FC; Tue, 8 Apr 2025 12:31:09 +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=1744115469; cv=none; b=ShaTUEhYqjuy50+163A+CriidUKvLQsoAkRAiSMF6kv3p9NtPA0lehtfUVpXJMOmkQc9CBM06OpUrmTKqEhZoV2GXgDj2AGsc4c06j9Eh+tz9Z+NREl3ZD+7LoIqTF4W+iWLQgrZ6S8v4H9YncImsw+Mu0819F1GxoBrdkTt0NI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744115469; c=relaxed/simple; bh=5EZ8wbNzX3XOXK8cVgy/SxGoMET74PewXvDT9LQ/Z7M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=T0Fndv9HQ8uLsMt51a8JcIC958AiaroWY4Vk133lbjwejx8Ikh7MGq2yTIMrFJfM3S5Nf9d80ywlLVytCkk8WMa2uk/iBpRMpwL7+rQhM/H1s3q7NBcy6GdcHq3tPbNnOul5XViqV2kKqKA5NVXz0b/U2QsPh0TJzwM96+B2/0Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=mMi2+q9A; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="mMi2+q9A" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CFEBBC4CEE5; Tue, 8 Apr 2025 12:31:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1744115469; bh=5EZ8wbNzX3XOXK8cVgy/SxGoMET74PewXvDT9LQ/Z7M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mMi2+q9AZ5q/kEIYa6kD76VjKGUxbPTaDOCGa4dkEpIWMrW8Opt8P+nOOvzs/tPHv p+Hl9bDBkw3UIJv0yId8uJPv+SmiBJj1wImumhKtErBgPYXJSlLln5/7kGdC1zX8Gl 9pMvrQVh5NWoIac7pqx/ZlpirE4+aHWMqXgQQrgc= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, syzbot , Qasim Ijaz , Dave Kleikamp Subject: [PATCH 6.13 486/499] jfs: fix slab-out-of-bounds read in ea_get() Date: Tue, 8 Apr 2025 12:51:38 +0200 Message-ID: <20250408104903.479382835@linuxfoundation.org> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250408104851.256868745@linuxfoundation.org> References: <20250408104851.256868745@linuxfoundation.org> User-Agent: quilt/0.68 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.13-stable review patch. If anyone has any objections, please let me know. ------------------ From: Qasim Ijaz commit fdf480da5837c23b146c4743c18de97202fcab37 upstream. During the "size_check" label in ea_get(), the code checks if the extended attribute list (xattr) size matches ea_size. If not, it logs "ea_get: invalid extended attribute" and calls print_hex_dump(). Here, EALIST_SIZE(ea_buf->xattr) returns 4110417968, which exceeds INT_MAX (2,147,483,647). Then ea_size is clamped: int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr)); Although clamp_t aims to bound ea_size between 0 and 4110417968, the upper limit is treated as an int, causing an overflow above 2^31 - 1. This leads "size" to wrap around and become negative (-184549328). The "size" is then passed to print_hex_dump() (called "len" in print_hex_dump()), it is passed as type size_t (an unsigned type), this is then stored inside a variable called "int remaining", which is then assigned to "int linelen" which is then passed to hex_dump_to_buffer(). In print_hex_dump() the for loop, iterates through 0 to len-1, where len is 18446744073525002176, calling hex_dump_to_buffer() on each iteration: for (i = 0; i < len; i += rowsize) { linelen = min(remaining, rowsize); remaining -= rowsize; hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize, linebuf, sizeof(linebuf), ascii); ... } The expected stopping condition (i < len) is effectively broken since len is corrupted and very large. This eventually leads to the "ptr+i" being passed to hex_dump_to_buffer() to get closer to the end of the actual bounds of "ptr", eventually an out of bounds access is done in hex_dump_to_buffer() in the following for loop: for (j = 0; j < len; j++) { if (linebuflen < lx + 2) goto overflow2; ch = ptr[j]; ... } To fix this we should validate "EALIST_SIZE(ea_buf->xattr)" before it is utilised. Reported-by: syzbot Tested-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=4e6e7e4279d046613bc5 Fixes: d9f9d96136cb ("jfs: xattr: check invalid xattr size more strictly") Cc: stable@vger.kernel.org Signed-off-by: Qasim Ijaz Signed-off-by: Dave Kleikamp Signed-off-by: Greg Kroah-Hartman --- fs/jfs/xattr.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) --- a/fs/jfs/xattr.c +++ b/fs/jfs/xattr.c @@ -559,11 +559,16 @@ static int ea_get(struct inode *inode, s size_check: if (EALIST_SIZE(ea_buf->xattr) != ea_size) { - int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr)); + if (unlikely(EALIST_SIZE(ea_buf->xattr) > INT_MAX)) { + printk(KERN_ERR "ea_get: extended attribute size too large: %u > INT_MAX\n", + EALIST_SIZE(ea_buf->xattr)); + } else { + int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr)); - printk(KERN_ERR "ea_get: invalid extended attribute\n"); - print_hex_dump(KERN_ERR, "", DUMP_PREFIX_ADDRESS, 16, 1, - ea_buf->xattr, size, 1); + printk(KERN_ERR "ea_get: invalid extended attribute\n"); + print_hex_dump(KERN_ERR, "", DUMP_PREFIX_ADDRESS, 16, 1, + ea_buf->xattr, size, 1); + } ea_release(inode, ea_buf); rc = -EIO; goto clean_up;