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 46750C02193 for ; Tue, 4 Feb 2025 16:50:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A203D280002; Tue, 4 Feb 2025 11:50:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9CFFC280001; Tue, 4 Feb 2025 11:50:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89932280002; Tue, 4 Feb 2025 11:50:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 64845280001 for ; Tue, 4 Feb 2025 11:50:05 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 1C693C01F0 for ; Tue, 4 Feb 2025 16:50:05 +0000 (UTC) X-FDA: 83082849570.01.DC8A926 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf05.hostedemail.com (Postfix) with ESMTP id 182DF10000F for ; Tue, 4 Feb 2025 16:50:02 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=U7k0eTTi; spf=pass (imf05.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=1738687803; 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=/higoSSduy/KO2yVDFknDgAYJkI4wtcMS+4qzTFpIHw=; b=rOmo7l74TpK7e8l2oRRMDrm55GB8GUpnkY9K3BJAeMV1c/NCUYeWiQccmgSXnqTFVWn/8e GlhzZg6fPwAvOyBXuhYDHGsvCsN1aCjWx9JBE/kGQBTkDbqBDKlmndzIZvmrS1/lVdTYJW EM8ZYNgWa7Ku2TnWsd884jzwaHGHfeQ= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=U7k0eTTi; spf=pass (imf05.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=1738687803; a=rsa-sha256; cv=none; b=5wVt2lfQVgKwgZ89+pQV1NtdQmq4lRkyo95QtdPOQU6Xr7oI9YeWXTVlCn0Nax8NxLRMXJ gLYgQ/zWgmNFAj399xecQfy7IUrwi0uRybibMTOscfAz+lUbAP9prmVTMdM7s8PARqYpHM 6bk/lT7SRyhl/ewRRHnGRAs+jd6bd2I= Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-5dc89df7eccso7254671a12.3 for ; Tue, 04 Feb 2025 08:50:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738687801; x=1739292601; 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=/higoSSduy/KO2yVDFknDgAYJkI4wtcMS+4qzTFpIHw=; b=U7k0eTTiHNSEN+s0LsOUEfo2LUI2M+ELi9WpTtl0c/xphDOEGixcGIBSJUBfnNrEEw 7+Jk1fLoOjajITbWXDUt6AAYbAQ20MPMPH0hLVerOS5GQA41kiXjS5Yxt4bb4iIoOqQh Y06xFiq8IytmEj/RzsLenh8MPa8r+O8+vyAHIXZwMpLDRQl0bpvyH/1tV7Al4FNyiqex SP0ATOQWN30f0uiWsvyZ/fdELp0CyX6t3QHLo9HIf3ZyDMVBSLOzgxKrJjpA+ZvV/tuE FpfdS8Bvt785tEShOo+DAQTg2W6j/1Zv21MWjxaW+Jsjnh2CjrVkZadkma25Hkho+SVn SoPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738687801; x=1739292601; 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=/higoSSduy/KO2yVDFknDgAYJkI4wtcMS+4qzTFpIHw=; b=BHfQqFuVfpn+aQSThhQ3dO9A9AMdRtEogLPseW4lE6MjDnJ3Zig/0ALlGgqgwZo/HN JUFsgnQL7jbPk/J/2F35dycwpiS/KnL36zVcLrQltOfueuWz0xYRKcGh674/3ptNRU3I gQtNNFewxP1xWtBetFgWfPL2i9pRTxF5tFxu1nYnQlDTf8ZffFBEHBo2wHuZedQlqlXy 5xCRaQDx6fetPKn6DF4L3dv0UA4ENCaLl1o21oSXyXQ96RmT6uH0AUdKYK55ag+yyJjm ta8gHa42DFN6KRI79kGUNwTAQMDxVTLSPGeaCKn8vsLzovY4n5ja0j7rfcW1ZQr+ssHf JdLQ== X-Forwarded-Encrypted: i=1; AJvYcCXNH7ZfMVWyNDEDaSiLtp+atksW68NMZlhtuw5mxcugpfcHVkZA6wfEwJuya3EWfT6ZJXDc4PZN6w==@kvack.org X-Gm-Message-State: AOJu0YyDUX3B44bD9ShmjLzzMd6/6HzzOnFUv8pAjXEQkxmlsZXvMe04 DoeYSYqTzRAF55d7SZrcuPDpSlYre05uzztpRzqwQJvk+TkfMNXGzi6NdbZJsSsjYPsZPt7/BFh m+Qc3xk+a8g5swMxUQ+uCJQ5dSbE= X-Gm-Gg: ASbGncsDdK8YuFscsUDDjRdd47f/nd/6b9ZM+9XI/SY9uQVV9rHZyKVvsfq7wW2k5Io jv5QPtZwiC4Au/9MFL49uHboUHKtb/+/tWAa7Wv1x5j0/bf4CmugnWiO7HL/xCGGKZRgKmKw= X-Google-Smtp-Source: AGHT+IHfxdQG2tJlCpw/8xpw+d7GjY4QltazgqxiSu1xU4R6shZ98eYPrJEgfxG48JgSqPoUwLICbUz62hDYbQjkmeI= X-Received: by 2002:a05:6402:26cc:b0:5dc:c869:da53 with SMTP id 4fb4d7f45d1cf-5dcc869dd38mr3157635a12.31.1738687800777; Tue, 04 Feb 2025 08:50:00 -0800 (PST) MIME-Version: 1.0 References: <67a1e1f4.050a0220.163cdc.0063.GAE@google.com> <202502040717.FCEFDB7E0@keescook> In-Reply-To: From: Mateusz Guzik Date: Tue, 4 Feb 2025 17:49:48 +0100 X-Gm-Features: AWEUYZnJ0U7VzGUSpHXrBnGDNIKmZNbTo6AYkphiwPn1O-6LS8WWCVuo0Q9swnI 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: rspam05 X-Rspamd-Queue-Id: 182DF10000F X-Stat-Signature: hctwxbhcfjx1oorxrdk5rbs6p8so3y3z X-Rspam-User: X-HE-Tag: 1738687802-705326 X-HE-Meta: U2FsdGVkX18/Ravac1NUB3i7zKjApYAd/wmbb3e6R+DAZYNEB46pHmNGyjowckmoQA67RR2v8UjnofWgK9mcRxgknp9m0Zj5cFcHqDV1VTjwdOzGcggxtB0BBfupTjx1JQWNdzwm0fDrQr+OYj/bcTfzRvMpFKLvQzIF5EYSAKbfpWv6YhKdAX0dJm1Fg+wClvu/q552/vjKFPF9bgYDEJP5o8XKUsasuAk2kS8yPHTmqPguszOCQMGcVV38lixNrav9zJRPZALmg/XR1SX5sQQl+Y6XdV8heWuJ25dIOb6R4ZgB6oE6DhE46ImH6zwSEvyuyckWcfTtOsZlIHO5OC2NDvf9SM6jtHTj4vozdnLgkxoNeewFWpPIDy+XEO+TG1DUgzQYYs06duhyiAtZ4Q1EyCpYQq2Wee2ykyZCetsxG/tqxXrLDJ1V6glJR0iFYpVUlpDTxZzhLVp3NSUrAO6QVY9c/BJAAdx/7/tzbIymaYQLtaJl5r+A71F8UEXCbIZSoUCw8oONWVqloz0sn1qMAcPSE5uYTZsXtmZZNtODAoG7ldC8IeBSdIsOV2RBBQ6vuEHfu/Epa5OuA7mWw51W/EubHP/Va6GBCTsdqZDlSYCxnapIuj3Afg9UaeLHp+zbEe14kDVXzcjJZYUf0yMWLDURCiKH4kMr97Rb8lwrWhlQayq1R9Z4EmK4HQUt19948of/etYyxyBGAgbYR+qegk1MQLMh80YdzuTrBd33zm5sVwvHsc8zCANigpm6kM22FoKY+ytFMdfz65nwS8CV8R7/sq+aLaV5kHAIT0SgQvvG/OCc0kr3/PXqdxbZttVVIyur5LKeK+rK8T6uh5/TV/J2bpnmI0GmieBudLyoQuJPvqs4ScS3F2i9AE4HfL5jlr6fVcx5EhQGCnE1Dr6yBvmgB2ydnlbvNuEFvJ6Mlm+bv88JrkUzpqmNH8iRxdLLYeKYM6EhHhxzy6r WaRGFnCD eTCyzVtZ7OGr4Yzp/hf1hRkB7lW7PGSseqccbKUj2c++vNWVwHrkQeaFF4HAncwyjni/fKQpOdpTUUCkYQqBUeuhnFVTgf7pIaPEO81kiMtdhN7qfdpSZZNzk0nRWrzgyeQnBb3IO+duO9ONxZrpb2XhDz1rrxN0/z/NJIpqLFLarGNQTTPzslSFK0mw21pEyDyzhkvnKUTKm4Df/Y6wRAzA9u81gK1XeSojevNprKAIIKRMqO/CJUk2vIjWKdYNXbthronfmWduDujk0Uw5svEhOF4isgkd6IAD1J426IM3H5aVFLDTqa9rcXVop/suPuJtf/pZq1JSc3EbdGRjgHUS+Jrtke7uyrN/1GKOvMfYCJt7+ZlQY99LUGqt3eUBEyblyodbKz/TbCw3zHx/yttFhhSuCrV6DwVwtRPu01plesvJHo8HMcRtPlDoI70L9KPtX9m6RQ8jsVomv1LNB1hBDUF33H/ZrB2djxe67bwgPMjHqj4hQnkkK2n0wQN93BJJMzcRnWaGK2psioK28EoFuV7QHsyIUEaFy0r4vcLvThZLBIGJbsl+gda8h+08JVtJPHcLEl3+AGqB3jLwwCDW9ssFlcYOr/6okXIv398k2k9SK1L63a9mmum/Im93BTcRMDJo5gmhUKUjr+hmTBRvuOW+hl9ZwG2snJumWgdDWdHskhtDXeW74708xAVtE7XsziRYPkZ29cPw1xuEImaa+A+cgwKScNPEDtILH81rJnmEMXIE1O6fSTaPGdm5YgK2CvkAr4BC5tTLICvqCkQwWVQp60ko9OBmcKM/gL1V9N9+MYRwldPtaxUDzKXM3eD5h7Oz479zsoUE15R1MJ8CqkPtRv87V989iMJv0xVZSTWNpsa0KVEVlg9ESVUHd8kQBX+Akix2DILPSy/Qwz13rJiGNc+Xpoa5eQWs3SpPpJFU0lnnIO130Uo6E8DTLJMRM7fw/buy0DfUQj0X879DNj0KR VJt1BaE4 rlOQdiKT8lM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000009, 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:58=E2=80=AFPM Mateusz Guzik wr= ote: > > 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=3D1258aeb= 0580000 > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=3D57ab43c= 279fa614d > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=3D48a99e426= f29859818c0 > > > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils f= or Debian) 2.40 > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=3D15825= 724580000 > > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=3D1658aeb= 0580000 > > > > > > > > Downloadable assets: > > > > disk image: https://storage.googleapis.com/syzbot-assets/ea84ac864e= 92/disk-69b8923f.raw.xz > > > > vmlinux: https://storage.googleapis.com/syzbot-assets/6a465997b4e0/= vmlinux-69b8923f.xz > > > > kernel image: https://storage.googleapis.com/syzbot-assets/d72b67b2= bd15/bzImage-69b8923f.xz > > > > mounted in repro: https://storage.googleapis.com/syzbot-assets/7c29= 19610764/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_ino= de_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 ther= e > > still a code path where i_size is getting used? It looks like the buffe= r > > 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 *)e= i->i_data, > > > 5013 inode->i_size); > > > > The sanity checker said: > > > usercopy: Kernel memory exposure attempt detected from SLUB object 'e= xt4_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_ca= che", > > 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 th= e > > 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. > I'm going to restate: the original behavior can be restored by replacing i_size usage with a strlen call. However, as is I have no basis to think that the disparity between the two is legitimate. If an ext4 person (Ted cc'ed) tells me the disparity can legally happen and is the expected way, I'm going to patch it up no problem. --=20 Mateusz Guzik