From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 20867C02193 for ; Tue, 4 Feb 2025 15:30:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 442F1280001; Tue, 4 Feb 2025 10:30:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F23C6B0083; Tue, 4 Feb 2025 10:30:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BAB0280001; Tue, 4 Feb 2025 10:30:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 0DC5C6B0082 for ; Tue, 4 Feb 2025 10:30:16 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9554F140B04 for ; Tue, 4 Feb 2025 15:30:15 +0000 (UTC) X-FDA: 83082648390.14.71305C7 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id D5DD240005 for ; Tue, 4 Feb 2025 15:30:13 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=lXRwN3+K; spf=pass (imf27.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738683014; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=vOOXvV3/ofS624X+AKpyhFOmvPzGr7gZ5Dwb0n/WjEc=; b=urfbbOvPztQd5E9rkiwcVJXEgTbxaSK70U+cdC5eRFCgjz6vAoaAzeHiSn72NPeZP1wkaC sABVq2/aCkeh8k4+tQolFvlVqT2H1WKK9G1KzE9NmryLmLMxwsDE55HXZfF1r4JyscTQg7 Ygxai3L2VTswKYfQbJ4S4aaQ9iEcOwc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738683014; a=rsa-sha256; cv=none; b=aUph6WbJ5V7hUp184vQmdGkkkmFaKXjmjRlNzFP9r1GQh7A/qSTMTvbaxq09ja1p/Bc9hx olGZLtDwiSy5YA/KNRNoRvQ3C4Ru7zbP0IOglVmfHbe3qDT96mJnZHr77mSXk88LOHIKZe MVLV17skdVkdywUShiuS4jD4nSkS8js= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=lXRwN3+K; spf=pass (imf27.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 2B2AE5C4CEA; Tue, 4 Feb 2025 15:29:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9835DC4CEDF; Tue, 4 Feb 2025 15:30:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738683012; bh=u1FZ54R0O5S/HeyqDgM4tlKdRqkdUj3bRIO8nDvAQFo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lXRwN3+K38LnZd+JYDmSua/WO4AB6KFUC3CJY3ASq2Bdv4+dijrZw0CR34hP2edbY wZCsqcDtWolE7doBm6MpTV6Nrl3D9CXsSzQ7DWTt8iBWV+q3HRQUEHOWLu+IGKgwGw YsRvv37U9oCv8/GRbskoivDxuLWDzl3rT8m3vfTL+fDwLj7/OXSTtMuQZ5pf7nTSoN Fve01jM2J2J/ARIoGEqcxJgB5hTR3L0ab5JT6W6HCgn4xF8kh238VjfNrM7ISpBlmg jcYN/dWDbsI9awBV1AJKFr9pUNU5FGX/kj4+GNw5EcuwI4IZIJ4MAvH3J0gV0meWLl sp/FgqS5s/8AQ== Date: Tue, 4 Feb 2025 07:30:08 -0800 From: Kees Cook To: Mateusz Guzik Cc: syzbot , Theodore Ts'o , akpm@linux-foundation.org, brauner@kernel.org, gustavoars@kernel.org, linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] [hardening?] [mm?] BUG: bad usercopy in vfs_readlink Message-ID: <202502040717.FCEFDB7E0@keescook> References: <67a1e1f4.050a0220.163cdc.0063.GAE@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: D5DD240005 X-Stat-Signature: a3nssw6ib5ta3cj9974bjodktpo4rbqf X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1738683013-844180 X-HE-Meta: U2FsdGVkX192uiAHblOVrOxFWuxicLLjjd2md+/efvt9vfn7vBZPcJd70SAD4bYNgS0aI6gd44JpJrO436glQ3QEMcoG8d52QQWasxhTCmr+BJokaEvTTIW66MgHg6Cgyzrw0IsuCC/evG4S2fLxrslXpiym6uBUbtPQf5s0SOH5VVcL4fkh61J5YVftl3EywPgj+fyX4m3TXq71G548SubiVaIeH4M6AHT7UENnNMA7CnoRJtu4xQKu/upKtUeAS4495OqmuMfQgSVgnlc9NFN8z4mJHQLH7rMLqzpainwJDPUdeJIi/ByL7O6H+8azhRIjvw9csEWGWGnTeuUAqoji1fzQFqAHvqW3ULLJxqyhSxO1rMWAh+vhFlaKmkY/aviwj0fryBoLvCGO4h7ILOG0hsWbOuJ3BVCU5kKlgyfz26PYxDJAhewXhhINPBUnpAwv7d5rI03bAUzIucyFqhXuDUyp8jti/vucsZkuieCu9TXuLxgrhqa0DKRNEFYPMdKVA0/wvb7mG/n/q7/b9tF8uP1Zib7ZCNtYEUbiy7xBNWI+ikbl9pfoujDOI3lQy58jyK8A5IvHdL/nIrP3FCHGlTrD6wdo7lEPKaMd80fl3n+99DAAn87LazyYEymiD/1KENAUhX2mumzrpHp9DvKTBGdQ4k62x/nnpfQVvq6lnhQgn11+nT/MIepJ06JovInl8Cv3lXQ8VP12dFYz2np1VxuTDKOe7EWmSclmqFbT9vu3VDikq6fhWAK/AfHNi7O/6dWkWFMw7M45Bq99l7vtsepBUUQtyUv1B02RPL5fQ0HKGX1UvBlYvjPSY/YhWrGtuMIXUuIF/ib9pB1uoqJHjtmV/fURx3rjlKXC3/sMVf9BKB5UeoKusHMfmA3DQm2pYYtralGp3Dhe+Yn5wSoQd44bWu2JfaH5Flmh8HT02eUx3ePavom/8+Gi6GGcC/6RSeXcDjH/AGVCF7A bmYTYtmV UiR46UPsrvaQQ5/tgCbHiQlIvUwnt0Jc6qgg++aBBD7d52lz3yoZiWmQ0LWD2dm+OZzCfQgveCZjre0xMyWHTjggyxN3wgJ3PgvtSNC7v++kHI+bThJOTGfvbubPQQTcyv8p3+aG60nuOFzVmqyfTD82xHZZyVjYfXPgGqsfCQXYljUvcRj09208HjEr+GmDmCUYcIUaAaLhioBhoywBuyVDTffe8/Y2Xv5iFlrgzFwTZh5ZMUnIoaSpgTCGOKm8A7+7E5bMc9hWmbGpZx/rE37uCKesJ3Hr/YjOPU3WH0IUwaGwYzF+NAMaw62q9WfXhUQBW4/6klBumj1LkoV0FXPkOUXYYUuLn0VSpgChmJ4h0Pwq5Mfo+KQwjQ/Gqy1LjRCSSb2jq55svx9l6wziM3gJTo2e24S2BAulmXkosSR0yh6656kJaHdQbebXp+p/KP1gYLqanct8Rwy8t3PtwOcgWUpDntMn7+dvT/vE4fBzP0/rLUVqoTPf72pInc9eAOXXnbMKLoNax1ZzV1qNCT2sSbNHk1Axi7Up3Pjvu/d5EJars3dqnQqejVlXJTDTmHLqaeEtAISnZ7FjUgVhMXC7zc4Y7wFvF4DVvQ7clzb7XzSVp9KnY0RKVxbyZBNS3Lqierue8Wh/vtvDXKkZalpqALgnA6Q4loefpPuTg43vOzzeXt+9xzwTlqhGH7pmq+SLP+neib8VTZqM1S83grOFmaoYcWBw7xSZwRuUQSj17L5+xq4ctdYaiZldFdkSynFbVxsElb7IgA7A6DnhGCSW/T4xNKea5RXolIDFubF4/RKF9suh78zDLZHOVgibTWhmwel0jtdiMd2odOq9Kr4b/kl5XjLIpVcQNthtVxAtvdKqRv+Vi042fBhAkMAHt11ajU2E1ycHmnTiRjw1hoEzsdjbnR3+Mc+r3NBiU+TlhKJ/msJN9EVqVUjEc9TiJBooGw5wzsKvtvhw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Feb 04, 2025 at 12:38:30PM +0100, Mateusz Guzik wrote: > On Tue, Feb 4, 2025 at 10:46 AM syzbot > wrote: > > > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: 69b8923f5003 Merge tag 'for-linus-6.14-ofs4' of git://git... > > git tree: upstream > > console+strace: https://syzkaller.appspot.com/x/log.txt?x=1258aeb0580000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=57ab43c279fa614d > > dashboard link: https://syzkaller.appspot.com/bug?extid=48a99e426f29859818c0 > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15825724580000 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1658aeb0580000 > > > > Downloadable assets: > > disk image: https://storage.googleapis.com/syzbot-assets/ea84ac864e92/disk-69b8923f.raw.xz > > vmlinux: https://storage.googleapis.com/syzbot-assets/6a465997b4e0/vmlinux-69b8923f.xz > > kernel image: https://storage.googleapis.com/syzbot-assets/d72b67b2bd15/bzImage-69b8923f.xz > > mounted in repro: https://storage.googleapis.com/syzbot-assets/7c2919610764/mount_0.gz > > > > The issue was bisected to: > > > > commit bae80473f7b0b25772619e7692019b1549d4a82c > > Author: Mateusz Guzik > > Date: Wed Nov 20 11:20:35 2024 +0000 > > > > ext4: use inode_set_cached_link() > > > > This looks like a case of a deliberately corrupted image. > > I added back a debug printk I used when writing the patch before. For > correct cases it reports: > > [ 19.574861] __ext4_iget: inode ff18d9bec05977c8 [/etc/environment] > i_size 16 strlen 16 > [ 19.585987] __ext4_iget: inode ff18d9bed6f25c68 > [/etc/alternatives/awk] i_size 21 strlen 21 > [ 19.590419] __ext4_iget: inode ff18d9bed6f24108 [/usr/bin/gawk] > i_size 13 strlen 13 > [ 19.592199] __ext4_iget: inode ff18d9bed6abeea8 > [libassuan.so.0.8.5] i_size 18 strlen 18 > [ 19.593804] __ext4_iget: inode ff18d9bed6f29368 > [libsigsegv.so.2.0.7] i_size 19 strlen 19 > > etc. > > However, the bogus case is: > [ 52.161476] __ext4_iget: inode ff18d9bed1cc2a38 > [/tmp/syz-imagegen43743633/file0/file0] i_size 131109 > strlen 37 > > That is i_size is out of sync with strlen. > > Prior to my patch this happened to work because the copying was in > fact issuing strlen to find the size every time. > > Given this code in fs/ext4/inode.c: > 5008 } else if (ext4_inode_is_fast_symlink(inode)) { > 5009 inode->i_op = &ext4_fast_symlink_inode_operations; > 5010 nd_terminate_link(ei->i_data, inode->i_size, > 5011 sizeof(ei->i_data) - 1); > > To me this looks like a pre-existing bug in ext4 which just happened This gets clamped to i_data size, though, so I don't see a bug. Is there still a code path where i_size is getting used? It looks like the buffer overflow was introduced with bae80473f7b0 ("ext4: use inode_set_cached_link()"), more details below... > to get exposed with: > > 5012 inode_set_cached_link(inode, (char *)ei->i_data, > 5013 inode->i_size); The sanity checker said: > usercopy: Kernel memory exposure attempt detected from SLUB object 'ext4_inode_cache' (offset 0, size 176)! The cache was created to make only the i_data field visible: ext4_inode_cachep = kmem_cache_create_usercopy("ext4_inode_cache", sizeof(struct ext4_inode_info), 0, SLAB_RECLAIM_ACCOUNT | SLAB_ACCOUNT, offsetof(struct ext4_inode_info, i_data), sizeof_field(struct ext4_inode_info, i_data), init_once); which is 15 bytes, at offset 0: struct ext4_inode_info { __le32 i_data[15]; /* unconverted */ __u32 i_dtime; So, yes, this seems like a buffer overflow caught by usercopy, where the bug was as described above. I don't think there was an existing flaw in ext4, though? > However, if the strlen thing is indeed the source of truth, the > inode_set_cached_link call can be trivially patched to use it instead > of i_size. Agreed. Please CC me and I can review it. :) -Kees -- Kees Cook