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 8D783C02193 for ; Tue, 4 Feb 2025 15:58:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0D4286B0088; Tue, 4 Feb 2025 10:58:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 083176B008A; Tue, 4 Feb 2025 10:58:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB4A66B008C; Tue, 4 Feb 2025 10:58:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id CD3476B0088 for ; Tue, 4 Feb 2025 10:58:26 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8FAED140A1B for ; Tue, 4 Feb 2025 15:58:26 +0000 (UTC) X-FDA: 83082719412.21.02F3905 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf02.hostedemail.com (Postfix) with ESMTP id A7DF380013 for ; Tue, 4 Feb 2025 15:58:24 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=goaA7y+J; spf=pass (imf02.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738684704; 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=2uB2kJTb8QdOsUK0L7YFlrm67ABkU6a2AEVF7OP8woU=; b=I9wrGMkCeK0ggnNjo2uKylAtZgwVC0ejvNJEciP64whZEqsOG35G0ZJMS3UhEtymyKA5/O FijvCZr2LZS8IccHGXaWaW01heazonr3yBCFYQCpjqM51nU88drJqaZAb/HBa1kyZTR6HZ Mxs4EP7jwSsqd+zhvAjZI2lbQIO0MOk= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=goaA7y+J; spf=pass (imf02.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738684704; a=rsa-sha256; cv=none; b=7GlHRt6UMQvlqOzOh7ArFRg2JofLSWCghwVRcPym+w0Wkmw0FdYoHAz0kU/tdOpAsHBU/d htkDjqduI8a5FCITRHl6VvNekYVDvMd4ebvDDXhSAXEVa27nYbT95AlrFjt+C7HuiKAIdR r8Yv8povwc97o8IjV43muHlym+eh0jg= Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-5dcca17340fso1294074a12.2 for ; Tue, 04 Feb 2025 07:58:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738684703; x=1739289503; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=2uB2kJTb8QdOsUK0L7YFlrm67ABkU6a2AEVF7OP8woU=; b=goaA7y+J/FOQ+d86mDQPaBxRNTpsWtDJCd02lWdUR0CYDAaHyjdVogOXknCLrhRaeF 2xr/PoQdqNQzO3SOhpp5U+RDFBsTTiOBkcE0/lSxTAXbhnWYUu9l07pGxcNYXdrFj3qV Nq03suw/E2PUb+ga77jsO18HLE25ZixG6ElH25JPRXQcM9haZl7fqEjH7sVqU7QyXFtP DjuWFD2pRz1vEmOGfMSAnFjV3IA3xFaYw4hp1BqXtibth0VWPCoVubOf3ggYNLvFnpJu 39mXuJcmllQ8+1iOVimQOtgpuF/F/NBUHPGBcQWZSOJZekqUfU9Hi8gRma/Vjehcbbso i/rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738684703; x=1739289503; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2uB2kJTb8QdOsUK0L7YFlrm67ABkU6a2AEVF7OP8woU=; b=pOcdZPUqtkC7Ths4qxcyOh4Srfc8rs88bo1Fmiwki28Ry8GHeJANMBtjJT3lySKcjz sRs3Ijd6X3lSZROLH8Y47wzu7Ey/WIBCWfwie39Pn9Q6IBaYYTGI2I6NRAm8nEF/QEyQ roKxMGB3wcGyf2y1FjFgNlX55KMXwZgOqq4WnI+jHhGQM0xFiGY95Et7byBopO8/+cQm NcS4U5SMXQ9OOKkb44DyrqTqi3ytL5vebg9iNBPvzZCIEZbfc8y5W3OMTKF1P3ioyvj2 ksCzJizc0BlS7FVIJQhpeJjORsNDe2Nktvu25c+7NIYAxt0pL4euUsRim1rOgxd60vwy wQWg== X-Forwarded-Encrypted: i=1; AJvYcCXWfFv/TXc4EepMJI7YM7LqWpTapph4xVKBIL94uZAlFrUcxdU46UL8KfHINpgzUd9pRSxMuWQYSA==@kvack.org X-Gm-Message-State: AOJu0Yy3dgQccwGmAYbfQi/niGthZi8d3w3sqcPn65HGVa5z9SOUHgB/ v0/WPBaG1ezTXwHZGgM5Y3VbekMLQBfvhf7OgwRy6ncAcrj3c84RvooA7biPNUJRd6MWweQLdwd Ef+ajxwQFDp8dYF3xKMgW8kJXZuLjAKNaBGU= X-Gm-Gg: ASbGncu//rW/bcL/gC/UNbuhN9x7bwoAQYd8NYisOg7D1Y3uz0Vm/jzyeQZLE8bbVz0 oTYX8itKY/nDp+9uaBgrlRpdrs+kagDgHAYhoyL2REN3z9AgPmYDOBRfBbe88dyFMdI5VYqM= X-Google-Smtp-Source: AGHT+IHW9GxC/TcJGuLrCLjpmO/aQ4mpI8PFi9S7e+Fb+4RmuNwKDiXV6w+lylLH1atj4xsNf9lGehSKmuAJLEuRmBg= X-Received: by 2002:a05:6402:50ca:b0:5dc:5e37:b3ab with SMTP id 4fb4d7f45d1cf-5dc5efc1e31mr30790551a12.12.1738684702790; Tue, 04 Feb 2025 07:58:22 -0800 (PST) MIME-Version: 1.0 References: <67a1e1f4.050a0220.163cdc.0063.GAE@google.com> <202502040717.FCEFDB7E0@keescook> In-Reply-To: <202502040717.FCEFDB7E0@keescook> From: Mateusz Guzik Date: Tue, 4 Feb 2025 16:58:10 +0100 X-Gm-Features: AWEUYZmY3UJTrZZwxs8Jm5FMnyNZZ4ZBtTxGT54CvHbzHL5s97u6pP-uEnCtnHA Message-ID: Subject: Re: [syzbot] [hardening?] [mm?] BUG: bad usercopy in vfs_readlink To: Kees Cook 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: A7DF380013 X-Stat-Signature: cenhnpib6j3dc5m51xicu4z9dwp5knqg X-Rspam-User: X-HE-Tag: 1738684704-526447 X-HE-Meta: U2FsdGVkX1/vupB1GHHFl88O2d3nNAbtuVQc56bCvsxM8ifJDqVJ58rP2Tg2odg7OnilpuS8K2EuPOGIKayZC1V4Yd+RiyJkBqmrFYamKxVGdy3kAFjO+UcZGv6FhLcZIqRIOqQYkQhoVHi4RJHUTFkvoOcF3YROjs1c+tOjSn+0dfIXUOBfDVAk5+LgVCLeErS0ZpdtGu9d/NmcM67l7hYuh4pUNjtP87AFWeH9cm+E0oZPY8v6XzADhSaSxeq3bjrT/QympPuLt0Xz831Q313LW7gLA3yhr/HyFmsb03nGbVv9zbdZiQP2UTpRceUVtWTaypsvfWhj6v4snAUPgKWG4k/cIWWdg33dPpeBylyeR28cv16HSvtoXBR/gYaQbYSYBrHMya/pf9uiW7EEKjqauZ+XYQpwreOn0MFZ9PK7ncUifghKUzREOOZefREA7ZrdBA3iFRW9LQgh6PXN+XdQ9mLMdZOOWh4DTklu+BczsRo4RkKTZs0bwQr5BX6hmPs2nQOx2c52SIooirtTMGHKN/GPHWxAlaqcYJ84dTn8Nrq0gWgldJxuZqZaqOqPFysQkdLCDXH1LxHCFNfqa7M7QhEuEVZ8aZPAL9nNq3oAGX/7F7DnZrOHKqRJyupFVMZTUPImKg9M7elvH1r6c7ICLYPxwTEuZhCYNx5UAu6prPH8bz+4/1XCPc5/lzGo7zBGV2sN/ZRVAAGqmomnGvgCAsff0aN5Q6Rk8dblEMuGkOSrcTxLdkqUnAS7gRiCenfuL+59Lv85xH2hSqtK87iJppWUqp5eDBqRDhFyhvSnRKqwyoZv5ec5mgXhH7ibKALu3BoPWivL/YOFkfGKdmgpcuDAamSK843tRuj/756x5TB4Al/wrHExiHgFASWjgLhLIn1qiIYEXO/rNoIjfRQuOOUtSYiO3plAoFs/t+mb1YR2BvkCZrry9iEclEAntrepKix2ivRnVg5bH9Z zUo+JQUh s8t2Q7R+xqox6m3t5YFBAJx6nWsxs8W84162LuCw3OE+KJAJ2iiDPdg9w8LryD//WANvo543acxkvomMzyJH2QwbACs5FsdNo0Zv24PCPDLWDZEB8QQZjsBmEig3EVJMI07JumFbXUOu27pPCVoD7uoPiiuL4lPFEXmQrCXmBomdPosBQKqPbxY6TVKmecF3gTRel74oNhfetRGNaTZTBQPmERMK849INmlpM6K6NnlvQmWC9xDMz0wT+lehYe8X0InzxZqHwNB6bmo3MnYRjfqfJfXyQarIEMPfy3lMPi8Q+RvYCdkRqNhhfxkVOLTVytXisoVpVIyyHpdUC52sn5n4amQlNYmWhoD3oJbbbIo1DTOgCM6CGsNPxiz+eqVyfOGSCvYaPT0D1pCZaH1PWmG09BdcO2roH+f14Ad+8d6fBbyZCxdrzWdx1VaY5jkG3FNkO4RJ6AHi4/iXHEbuIVG0OpG4PO9C0M388H5O1zJm6akj8pNxkjy9K5IEnhxH4iZ4Vkc6xpuvN6Tz+K/BWIk6xQk0HxubMKiR2agesojVyFnHW8p7a7ZZP/aIr9iArTEE4PI+IEwwqrTyox8pJcvvYjUDAibACPA5yi6R4/+sCXrG7DUDDDCo0FE2uzdal0C8IuQxkk1TOyE7t2YAFsAQ6WHDl6goxK0HHdEKEmirbF1Q0gFUm0l+idzIRIihou+aHA9bpOEE9IL9T/5TivD2gDYcrdXHrHEhQT3R3Zr2OkRXqNUOoCOsISfA4aEdw2HRycIwey3+6zP3GnuRgm9KMZz+Vr0ndbpTOLhGrQU3scQTrXx1haMyP0m66P9RlR8NJ72GwNLxcQ1oBpCNV3oNBWmW4hxEqVjPhKsvgI7Jp/j4MaAFWmJOBKem2SchDPXd2GoC1Gb1gGOQG2pSyGkZFl8UjrC72eXDCTeC3MjCkroWbzMBamdduBNbCJgYYe7gKj4eCC1OFjCgkIAgoc3XVB7BE DEUrEHgs dPrner3CGkU= 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 4, 2025 at 4:30=E2=80=AFPM Kees Cook wrote: > > On Tue, Feb 04, 2025 at 12:38:30PM +0100, Mateusz Guzik wrote: > > On Tue, Feb 4, 2025 at 10:46=E2=80=AFAM 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=3D1258aeb05= 80000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=3D57ab43c27= 9fa614d > > > dashboard link: https://syzkaller.appspot.com/bug?extid=3D48a99e426f2= 9859818c0 > > > 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=3D1582572= 4580000 > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=3D1658aeb05= 80000 > > > > > > Downloadable assets: > > > disk image: https://storage.googleapis.com/syzbot-assets/ea84ac864e92= /disk-69b8923f.raw.xz > > > vmlinux: https://storage.googleapis.com/syzbot-assets/6a465997b4e0/vm= linux-69b8923f.xz > > > kernel image: https://storage.googleapis.com/syzbot-assets/d72b67b2bd= 15/bzImage-69b8923f.xz > > > mounted in repro: https://storage.googleapis.com/syzbot-assets/7c2919= 610764/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 =3D &ext4_fast_symlink_inode= _operations; > > 5010 nd_terminate_link(ei->i_data, inode->i_s= ize, > > 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_li= nk()"), > 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 'ext= 4_inode_cache' (offset 0, size 176)! > > The cache was created to make only the i_data field visible: > > ext4_inode_cachep =3D kmem_cache_create_usercopy("ext4_inode_cach= e", > 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_da= ta), > 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? > I don't follow. Are you claiming the cached symlinks can only be up to 15 sizeof(i_data) in size? In the long above you can see lengths bigger than that. I had the vm still running, dmesg shows some more printks with lengths above that: [ 695.648078] __ext4_iget: inode ff18d9bed33c3c78 [../Pacific/Pago_Pago] i_size 20 strlen 20 [ 695.650647] __ext4_iget: inode ff18d9bed33c60f8 [../America/Los_Angeles] i_size 22 strlen 22 [ 695.653160] __ext4_iget: inode ff18d9bec8be8128 [../America/Denver] i_size 17 strlen 17 [ 695.656716] __ext4_iget: inode ff18d9bed325dc68 [../America/Detroit] i_size 18 strlen 18 [ 695.660450] __ext4_iget: inode ff18d9bed325ca28 [../America/Indiana/Knox] i_size 23 strlen 23 [ 695.664270] __ext4_iget: inode ff18d9bed325c108 [../Pacific/Honolulu] i_size 19 strlen 19 [ 695.666569] __ext4_iget: inode ff18d9bed325aec8 [../America/Indiana/Indianapolis] i_size 31 strlen 31 Note with and without the patch there is copy_to_user from that area taking place. Regardless, as you can see all the symlinks so far have i_size lining up with strlen. The only case which does not is the (presumably intentionally corrupted) fs image from syzbot. Sounds like the link should be rejected by ext4 instead? Again I can do that strlen() call, but it seems like papering over the problem for me. --=20 Mateusz Guzik