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 4E1BFC02193 for ; Tue, 4 Feb 2025 20:48:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E07BC280002; Tue, 4 Feb 2025 15:48:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DB656280001; Tue, 4 Feb 2025 15:48:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C7ECD280002; Tue, 4 Feb 2025 15:48:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id AA79B280001 for ; Tue, 4 Feb 2025 15:48:38 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 683CA1A015F for ; Tue, 4 Feb 2025 20:48:38 +0000 (UTC) X-FDA: 83083450716.25.6F957D4 Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by imf01.hostedemail.com (Postfix) with ESMTP id 6D79B40012 for ; Tue, 4 Feb 2025 20:48:36 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gIq6mqg1; spf=pass (imf01.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.53 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=1738702116; 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=UB+b5/GLNJBneFA5sTPfeIuegF7/CdQflpntzTg1wUc=; b=QMoFSzY4kcFz18pxFGCZb7rCKmA4qncaGNP/mUGagB4Lqj3Eeuu3+ov5pksHXgeGfWy64Z 81pKFhyCZCXG+ko02syUYkWw47+58ktkF6riY3/VrLII9K76HBJStFz66SOxieXifMrFkd U6ExaIz735JJqDtUZIQ6RTRr3Wid4Hc= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gIq6mqg1; spf=pass (imf01.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.53 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=1738702116; a=rsa-sha256; cv=none; b=3490iXqX4dRk9mZAwiRaiF/s6ii5Q0V0mLHeRh8XyhuDBDd/37wWSbaabz06dXmO/3iZXo 1/jWn0uI2VSWOYRTreeB2CRxcHItxO0kE2XsYSCTx8N5Y4mA4Oz/wd8PgrsIapch9FjmcU t6Me08uRpF8sCSvMCHl57Hq1jewmww0= Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-5da12292b67so9918135a12.3 for ; Tue, 04 Feb 2025 12:48:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738702115; x=1739306915; 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=UB+b5/GLNJBneFA5sTPfeIuegF7/CdQflpntzTg1wUc=; b=gIq6mqg1T/wNrO/w/qWkGcH5s04CgGS+S7VYBR2jojXlBvuKRWmiWFMB9JoONYooHW pdeEjyw7k5XdOBfw6WDIAGC8HKHmCLpsSGwKbdGa0EMIrDF0z7/l7th15iSTcN3nGcXG N2vGbh1tgxvfeCrhFPoaENdnkruerjDLTsOMh25O42IrkbJzzR/2DfuPv2jjzGC23eqx jxfmXxTQSXTebMoHGxqu56/xS2O6DotCGpFQH4aaDI7QvoRqLLerYC5jRAdLrgK+yv+m da1tCr+WhDFE5HRKC8DsddtsFpUFj7DumNAI9NvR3cFjpPDbV+v7EFegI47WNIzEFZYZ ky3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738702115; x=1739306915; 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=UB+b5/GLNJBneFA5sTPfeIuegF7/CdQflpntzTg1wUc=; b=CT+EaolH/ekjCbh/2GZxHyzjrlHXvZq6HXq51w55T+tK+ah7JN4AaA0+ls6gjuiLrT heEMu6yxTg6rCaGbBrNswIk6UvJn5Q6hv5jVwGxTzm0Zra3obgaGL3EazzI0MsDYLKiN CMhvc75BMw2T2vLQFijkS5ooANxctFdEiKE1gRxnoCycpB/wXBsqWAL9VUWTgknAxBUo iWteGynPwr/rzqcxMyEEv1CE/nWJYrASjPcgRcwyK49lot2Qj5Ivx3IRkcmyC2LI5FP/ s284k9g9unkPEJgg8ifvnCBLS87MyNckDednIczhtarvY3B1xv10/Hw/o9b65VH8KJv/ h2AQ== X-Forwarded-Encrypted: i=1; AJvYcCVedf/BdJC2T0TTT3xQkbpVaQDz2QIxAHlPleVjM6eNVo5P/giOW8686MViL9++V4ixef5edTSHEA==@kvack.org X-Gm-Message-State: AOJu0YyN5WC+eNWtC3vGXXmfCTLEc4qqvXDPl58csDUO4ZzOnTC0h5VE EqZfht98eBXywgnB9HAQygFulhuD0ZG2PDAnTv4M6OSn4f9ppk6m7f2ENwP9vAspgVZ1AV1HLn9 qpcjL3a9DdDZaKZs80GYo0YL7mfg= X-Gm-Gg: ASbGncvwXxEaCBy3NiJa6bKuiQc+jwiiKGF1TcnoLcmdWzWyY6S/YGVZ6QYfe29Sf5e BUfY26H2vvp/KaZlwjz32xSBugV++j/lyQSYSFAyX0PUcyW5kIdsA+yiosPNcy3bKKuq/Em8= X-Google-Smtp-Source: AGHT+IHvAbD26S2+1hOEKdqIS8Zalo8h8j8u/5qXBrcKts7qsx9/xmkOOjKUAnQ5Ch9x4VJq/vXmdsmwAjw6JAosUyg= X-Received: by 2002:a05:6402:34c5:b0:5dc:d9cb:64fc with SMTP id 4fb4d7f45d1cf-5dcdb72d925mr1188382a12.19.1738702114410; Tue, 04 Feb 2025 12:48:34 -0800 (PST) MIME-Version: 1.0 References: <67a1e1f4.050a0220.163cdc.0063.GAE@google.com> <202502040717.FCEFDB7E0@keescook> <20250204203059.GA909029@mit.edu> In-Reply-To: <20250204203059.GA909029@mit.edu> From: Mateusz Guzik Date: Tue, 4 Feb 2025 21:48:22 +0100 X-Gm-Features: AWEUYZkNzkwghVnO_pWEtGkamlUcqUiswAmdummI6fCkRwHW3xW4dHRdUed_0s8 Message-ID: Subject: Re: [syzbot] [hardening?] [mm?] BUG: bad usercopy in vfs_readlink To: "Theodore Ts'o" Cc: Kees Cook , syzbot , 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: 6D79B40012 X-Stat-Signature: 89pcdqdg488gm4tmqj43ztpykatc1bsb X-Rspam-User: X-HE-Tag: 1738702116-534615 X-HE-Meta: U2FsdGVkX18g+lotdmNtpFbEeyE8odRxsvlqdefZn7dm+Ig/lJp5AHQjt4L0/W4E6KsHCcNuGg6fusL4j/Oshtb6L1HTuEZMf2m8/Dti4SzwcZpt/mEUTy1eY+ZqkM4N38ndkhoIdxFl2LSNQn1WShtmmGQAf7ejWawzDJ8gRZQZKhNN78iyFI11NkRSYDc0aNzJrjop1P7wyl22mAvdkAZIjl6nnLy8f8utswmcUy/QWC9nVoLnGxEuDK6y9vC448uhSFbKZv6D+ZBPU12kpZiGi0dup4gZkxnm65CG/PLcYokS2FufNpvMZiYa4lvbtEBKXoftdc2WuZW4cFf/RACbkC6k5ksZdzMy/u8Su513et1A7Ony1xtOzXVTkmZW9oSonwdmST45s3YLGHXmzK3ZGXw+r5vDYsq+QWrBKFNm4OiGzeZ+/9sNzz/QP3EbRHYiJqYe+4ZtmkOG1EyCliXIPu15wPRXmJoGvpqUW2quaskht747F+W8L2xSehLtsY7GPWP/JdvBLAfoL7L9eBclRsfrniwPaoT7LVyDlGxjnBOGJyPBXyL0Srmi3lGrdRibymO3eMgXWjKicf95Xdi9LT15b225ZgQ/I6teG1Dkdl//OHs7962pAhFuObqJsZP4FUIx+0p4SWnh4Qs9YCdSVY72k7jXYgfWy8x0wJLhbCt9MEsHPz28+4MavFBv22Fxr3QTPHEb+KgFQdsZgOk+2kBzSLIedIkXfuDDdVlDYkq/XCngLOb6JXPwBzJbdPglKjOhBPlACqCGApksT6eB1/QLTW+A3PXDLYUey6689rAMgUmbG5gV3ueQ2XEOJHtL+VkXNoIAk7156pCGU16JC+Kg6kf4gScDwWWW0irNBWM7JLYUVnXYSPDU1lEMtMVYSvAMGIysSjo7LZjtLWO+GBtbn3CPlMIESrorEBSG28OUYaIYh0QuQ1+ySyD1QP+R6UZkPT48/uxepAf LfA+Eqsa 4n/NkIeuW9XChOg3iN9Y6DBsmyauGmRACZhKjAzokO9SnOFqLXLwEVTvcKpxHadn75UW1mV+jNE9owZb3Mc6gwZipoUuJuNdgCnr84ceDBQC9JqukQ09LzD81yETci29Kcweqt5HI6Bi7O8mVQCtmw6RipwqRcyphtiINoiwRBy0myGs/Hf1WbBb8VIn9Q8cWPzwsbpB7XQ1Brci8mL6xDG8fjGDV1ZKItRhnEp+t3GF1lFoKgnxWV+P7kAlXjIMix2LlM2XpaS3cL4KoJdW7ev9MuY8GVykcaL5/8/TDq2HTkq6nA0wiWjqrX0nbEL8qCJwrYJzo5r+NeTKlcwT7t9OG/Lgc6R3Bs+40Ua2Yu1I443VAOCJXY0pKCNpA3B8AN4YMw3gcM0bCtAE/CHQJXpYEugKwX47xuvWk7Ikm8pMSzA1m/thUm1/IBXdQFIwwOTPqYl2DFC+thzf4XZnfWoqhCGQhbl2i6ksvoEl1F6PMofTpAme3gxeokOv3loQ49e+fBpGDNvKsWH7cz7+7D4bIHw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000041, 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 9:31=E2=80=AFPM Theodore Ts'o wrote: > > On Tue, Feb 04, 2025 at 05:49:48PM +0100, Mateusz Guzik wrote: > > 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. > > There are two kinds of symlinks in ext4. "Fast symlinks", where the > symlink target can fit in i_block[]. And normal, sometimes called > "slow" symlinks, where i_block[] contains a pointer to data block > (either i_blocks[0] for a traditional inode, or the root of an extent > tree that will fit in i_block[] if EXTENTS_FL is set). In the case > of a fast symlink, the maximum size of the file system is > sizeof(i_block[])-1. For a normal/slow symlink, the maximum size is > super->s_blocksize. > > We determine whether a symlink is "fast" or not by checking whether > i_size is less than sizeof(i_blocks[]). In other words. if i_size > less than 60 (and it's not an encrypted inode), it's a fast symlink > and we set i_link to point to the i_block array. From __ext4_iget() > in fs/ext4/inode.c: > > if (IS_ENCRYPTED(inode)) { > inode->i_op =3D &ext4_encrypted_symlink_inode_ope= rations; > } else if (ext4_inode_is_fast_symlink(inode)) { > inode->i_link =3D (char *)ei->i_data; > inode->i_op =3D &ext4_fast_symlink_inode_operatio= ns; > nd_terminate_link(ei->i_data, inode->i_size, > sizeof(ei->i_data) - 1); > } else { > inode->i_op =3D &ext4_symlink_inode_operations; > } > > > The call to nd_terminate_link() guarantees that inode->i_link is > NUL-terminated, although the on-disk formatshould have already been > NUL-terminated when the symlink is set. > It is nul-terminated, but inode->i_size does not line up with it -- as in the inode size pulled from the disk image is different than what strlen would suggest. My question is if that's legitimate, I'm guessing not. If not, then ext4 should complain about it. On stock kernel this happens to work because strlen finds the "right" size. > Also note that there really is no point to caching inodes where > inode->i_link is not a NUL pointer, since in those cases we never call > file system's get_link() function; the VFS will just fetch it straight > from i_link. And in those cases, it's because it's a "fast symlink" > (many file systems have this concept; not just ext[234]) and the > symlink target was read in as part of the on-disk inode, and so there > is no separate disk block read read the symlink. And so if you are > attempting to cache symlinks where inode->i_link is non-NULL, you're > just wasting a small amount of memory, and wasting the CPU time to do > the strcpy. > My code does not allocate any extra memory or do any extra copies. The code prior to my change would grab i_link, strlen on it and pass that to copy_to_user every single time readlink is issued. My code stores the size in the inode (unioned with a field not used for symlinks, so no again no increase in memory usage) so that the strlen call can be avoided. Past that it's the same thing. --=20 Mateusz Guzik