From patchwork Sun Jun 23 05:11:33 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ryusuke Konishi X-Patchwork-Id: 13708482 Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A70752BCE3; Sun, 23 Jun 2024 05:11:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.177 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719119509; cv=none; b=ApEHjzdJNH6HKkU8ERWY9PcGdosXuTAHN0zEBs5QsXT0zy1BpWvV7DTTwx5bNAQ5OY71O1rz09hd+xSftnaUcn+Bf8ucXbpgoYJZjFTjieQlBNr9MoAPL6gea0Lx2Gu8IP+B3DJ3md4BoVUGEHKn5SSMhd3h7UyUrvdOFyDThig= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719119509; c=relaxed/simple; bh=KnxIZFudG3C1TxSI8/CmS0sJBmROfHw8jGPU93w5fu8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=kIy+bjz1tyWmrj2W6RBVTBoCEHSTyMihy+n6XAYhZs/HxoCxtcESVijZAxqw9B41nmKrfjWn7Joy06uDBVNMttZ2SaD5SEEQ45/30VQUghuOwrUir3JkYVovqElvRIQ2zuuyqUF7rQOcY/smQc6bODqTuFlmbWDMtl1rtf/Evqs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ObyLgvwu; arc=none smtp.client-ip=209.85.210.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ObyLgvwu" Received: by mail-pf1-f177.google.com with SMTP id d2e1a72fcca58-7066c799382so692631b3a.3; Sat, 22 Jun 2024 22:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719119507; x=1719724307; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=vAvwFpe4xOuU3RCpzs53rLmBv8KRl44T9Keb6/shdb0=; b=ObyLgvwuCvFcJkg9qMalecjt3mgrbidrf757/6T0YwU26qiIisM7WlUK6+UoNEM0oQ HOtLkmBc8ij01RAQFmVsp5RO0Zj39GWmBhyQ6F1to6lKoHTo0RBChyZ+yWPfAJV/o4x7 PAfmDa+F1eCHSu8HNgGkQKMVWiwpRB7rWnX3q10zUKwCtREyN0VpN3gNGjrVAKbBD5X6 1JJZV0IKWSaNz224fO/9+4zhgiMPeDA2AP2E537s8vxxSd/QYMtBw9Zg/uAdYdHC6woV GoIxrM32AYPRdjNx5LZKCbknfUGV75L5m4mSjKl0vkvfZFIfpA178f/lTEi1iv3RDtZw vNyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719119507; x=1719724307; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vAvwFpe4xOuU3RCpzs53rLmBv8KRl44T9Keb6/shdb0=; b=eN7jAj3IKL4JoOttEaTgnlycvJz7APatZUOFbe2yAsRey1Rfwa0ZoAIcy/iT02IsoF 4HyCtVkuTitYRcnYNgC1zdpiDuCdGDOVMXBX70KFAKYFvQsjQzJ2+vYBJWtOo8/gwc+3 3JQa1NGRSZETrp7JRqEUOeTmftNRP3rqzpI+X89kAdpWdzcPhW3xztEicrdXcVvcKw/1 JjaK9000k01ZhaBCTdLNq2XEws/SBEG2LeQgPGqZJ8Dd+V3vZSMoQz6Jpps5nuOn72Qo +WgoiegDPXa39KgyZrp8J7PuHaFHGffZpzlVsQm+icsWhZmpbK6c6IYXtALvhs8NOKPJ G4yA== X-Forwarded-Encrypted: i=1; AJvYcCV/SkRE+cOdbefIO8VJr6Ki9TvK7P2c5JJrG7mSuimgz0iKAaMBGzbDBhOdjA+L659vfjMXABuv9oId6NvrAOPY02IDuLo1pvCUDKWOFo1AjPxLI0ylazJ46HEBWeimW3sAyeRABbM16NR7ag== X-Gm-Message-State: AOJu0YxCSTQy6IpAWsNeKXgTRe9U4oyUCemQaKFqbBMCkBPAp/9DXHVY SGY6QHd8Bw1ypbMiJ6e/ES2tDIkEHGz7rmtFB7G2npu8wAfwSI6KaMZEVQ== X-Google-Smtp-Source: AGHT+IGlOVArsdPGcw35kvPGEqXKkqr+FViW/sPKKeoxDxroMFVMAS0N4X8ESJRTWqYkOsHZHpE4DA== X-Received: by 2002:a05:6a00:1b44:b0:705:b15e:747b with SMTP id d2e1a72fcca58-7067471c5f6mr1816847b3a.30.1719119506929; Sat, 22 Jun 2024 22:11:46 -0700 (PDT) Received: from carrot.. (i114-180-52-104.s42.a014.ap.plala.or.jp. [114.180.52.104]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-706512d3034sm4042844b3a.170.2024.06.22.22.11.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Jun 2024 22:11:46 -0700 (PDT) From: Ryusuke Konishi To: Andrew Morton Cc: linux-nilfs , syzbot , syzkaller-bugs@googlegroups.com, LKML , hdanton@sina.com, jack@suse.cz, linux-fsdevel@vger.kernel.org, willy@infradead.org Subject: [PATCH 1/3] nilfs2: fix inode number range checks Date: Sun, 23 Jun 2024 14:11:33 +0900 Message-Id: <20240623051135.4180-2-konishi.ryusuke@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240623051135.4180-1-konishi.ryusuke@gmail.com> References: <000000000000fe2d22061af9206f@google.com> <20240623051135.4180-1-konishi.ryusuke@gmail.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In the current implementation of nilfs2, "nilfs->ns_first_ino", which gives the first non-reserved inode number, is read from the superblock, but its lower limit is not checked. As a result, if a number that overlaps with the inode number range of reserved inodes such as the root directory or metadata files is set in the super block parameter, the inode number test macros (NILFS_MDT_INODE and NILFS_VALID_INODE) will not function properly. In addition, these test macros use left bit-shift calculations using with the inode number as the shift count via the BIT macro, but the result of a shift calculation that exceeds the bit width of an integer is undefined in the C specification, so if "ns_first_ino" is set to a large value other than the default value NILFS_USER_INO (=11), the macros may potentially malfunction depending on the environment. Fix these issues by checking the lower bound of "nilfs->ns_first_ino" and by preventing bit shifts equal to or greater than the NILFS_USER_INO constant in the inode number test macros. Also, change the type of "ns_first_ino" from signed integer to unsigned integer to avoid the need for type casting in comparisons such as the lower bound check introduced this time. Signed-off-by: Ryusuke Konishi Cc: stable@vger.kernel.org --- fs/nilfs2/nilfs.h | 5 +++-- fs/nilfs2/the_nilfs.c | 6 ++++++ fs/nilfs2/the_nilfs.h | 2 +- 3 files changed, 10 insertions(+), 3 deletions(-) diff --git a/fs/nilfs2/nilfs.h b/fs/nilfs2/nilfs.h index 728e90be3570..7e39e277c77f 100644 --- a/fs/nilfs2/nilfs.h +++ b/fs/nilfs2/nilfs.h @@ -116,9 +116,10 @@ enum { #define NILFS_FIRST_INO(sb) (((struct the_nilfs *)sb->s_fs_info)->ns_first_ino) #define NILFS_MDT_INODE(sb, ino) \ - ((ino) < NILFS_FIRST_INO(sb) && (NILFS_MDT_INO_BITS & BIT(ino))) + ((ino) < NILFS_USER_INO && (NILFS_MDT_INO_BITS & BIT(ino))) #define NILFS_VALID_INODE(sb, ino) \ - ((ino) >= NILFS_FIRST_INO(sb) || (NILFS_SYS_INO_BITS & BIT(ino))) + ((ino) >= NILFS_FIRST_INO(sb) || \ + ((ino) < NILFS_USER_INO && (NILFS_SYS_INO_BITS & BIT(ino)))) /** * struct nilfs_transaction_info: context information for synchronization diff --git a/fs/nilfs2/the_nilfs.c b/fs/nilfs2/the_nilfs.c index f41d7b6d432c..e44dde57ab65 100644 --- a/fs/nilfs2/the_nilfs.c +++ b/fs/nilfs2/the_nilfs.c @@ -452,6 +452,12 @@ static int nilfs_store_disk_layout(struct the_nilfs *nilfs, } nilfs->ns_first_ino = le32_to_cpu(sbp->s_first_ino); + if (nilfs->ns_first_ino < NILFS_USER_INO) { + nilfs_err(nilfs->ns_sb, + "too small lower limit for non-reserved inode numbers: %u", + nilfs->ns_first_ino); + return -EINVAL; + } nilfs->ns_blocks_per_segment = le32_to_cpu(sbp->s_blocks_per_segment); if (nilfs->ns_blocks_per_segment < NILFS_SEG_MIN_BLOCKS) { diff --git a/fs/nilfs2/the_nilfs.h b/fs/nilfs2/the_nilfs.h index 85da0629415d..1e829ed7b0ef 100644 --- a/fs/nilfs2/the_nilfs.h +++ b/fs/nilfs2/the_nilfs.h @@ -182,7 +182,7 @@ struct the_nilfs { unsigned long ns_nrsvsegs; unsigned long ns_first_data_block; int ns_inode_size; - int ns_first_ino; + unsigned int ns_first_ino; u32 ns_crc_seed; /* /sys/fs// */ From patchwork Sun Jun 23 05:11:34 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ryusuke Konishi X-Patchwork-Id: 13708483 Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 55A1043AC1; Sun, 23 Jun 2024 05:11:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719119512; cv=none; b=ULgd/uqxHUnMZChdGTjcANuWZ/IAb/coqr2XzEL8ioMiCnviscvZpCrYaQx5bjfehdu7NccTSccM00A8nDaqipD/0PePmgopVJ8OBjpy4sZvoyyQP5xCqRk8yJKSZBzqt9SRNa5ogPnRZvxfIEQjDdnHCjdSpAhLQ/hMnIEc4Og= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719119512; c=relaxed/simple; bh=/QUee5/68v1wUcGvHi4Bt89dLZeWcXxeiN6N2yNKS/A=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=UZtsFZU0zYI3tpqA6fVoTO3CDvHZ2r/dJetc8TKMCMvzGNNOrhF8fs6roF1a9glXZorKzJlfIjX8Ex7FS73qAN50npww+fzLTIeyDNBarxt+1kJYrrndgLfe+IYPTqBmsqsC1KLaWM6ROBSOf4/W6SkC5Nr8kWnVZgrmkFP3AMk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ce//23Ob; arc=none smtp.client-ip=209.85.167.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ce//23Ob" Received: by mail-oi1-f174.google.com with SMTP id 5614622812f47-3d22378c59eso1876017b6e.1; Sat, 22 Jun 2024 22:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719119510; x=1719724310; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=tT5cJycHPW4bF7Awhg5sK4H0c0e9ZmnhKDoAOSL0ZBQ=; b=ce//23ObV5bfprXOOiGwW42aEOOldNl5WgD+t5bCTe4696AZ4b0gQEXJ6aldYXesbZ aWx0rH/6A22DbZnnw5d/mGaDFP4gm+d1GXVtzvx0Zcyjy0W24rlddgUuxURvAa0qn/J+ w6LtCqJ/LzE0hvJ9zUZI1NsWvPan0hcWchQExlyH3gf8VgT9IENokTHNH7oFuI3ob3vU v13/SZN4cjHWcZqMsnSWEApU6H+m5m7SXV4f4lxLt7qdnNmYeL2biwu7V/kC4co+ScDm nhs+G9DG3YvDpR8hjzrvWXE3E6bySEkdIj9QvPmktV9kyJi5MLtu42VnsFqu09qFCWHt 1Zbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719119510; x=1719724310; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tT5cJycHPW4bF7Awhg5sK4H0c0e9ZmnhKDoAOSL0ZBQ=; b=iuDjUOcnoy4pkwfW7pfOnRvm70bHjaM1mPRtiffrvMCV5K8FldR2gSPYN6dLwqtWz+ 7cDdLkRu5x6B2IX7A0rLWdLOFgphfko7cXDXkSj7q7vX2geC2d5xYmtiAHBcTF2QpGBW cC83vJA6mgYqf0vfzeI1SNxIVm61179W083VJVoQOiH1Vn4JcVV+k1N5eo8zpf/xUe/g 5kL2SfX8eIVBA/ljjvzjOuNwzQj9JNfb4veUBS2xVyfC75W8frJybLXbyKAmrQvnxyxd sFXMrgjMrvu0jZs9KDuW+qD46y09Y2iWJuqmIl7xepyqT6vd11+5gxe1mDWqXSnAbmIW hzVw== X-Forwarded-Encrypted: i=1; AJvYcCV6mIWs/9Qs2zB+m2q/KS4oW/NdN6CTKoN0l9KC/x5DAohi9oDDwuiBoOiWeDFU6i8E+c0DVXEg5HUX+cYwgon9Lx9DPguHFwE9Nzf0W1624M+S3kikhgcv+tsxkRFPsXZpqeApsf0tl+ySxA== X-Gm-Message-State: AOJu0YzsQiH0/ets8w5PiTODTgrMicBpvN/rSHrGHHk30GkPX8C5OOQz 76RDkzsOUwIbT8zYW6wAfQJ2bvO+WzKes3owS5sYe3Up0bLp8IuQ X-Google-Smtp-Source: AGHT+IGnkv2J9jT2ewWs/C5naQYApfAEe/3OeTIkIKfra3WnN958rumKElq8w0HQ9/th3kXzzmjWPQ== X-Received: by 2002:a05:6808:1491:b0:3d2:4820:5ec3 with SMTP id 5614622812f47-3d54589c290mr1810468b6e.0.1719119510285; Sat, 22 Jun 2024 22:11:50 -0700 (PDT) Received: from carrot.. (i114-180-52-104.s42.a014.ap.plala.or.jp. [114.180.52.104]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-706512d3034sm4042844b3a.170.2024.06.22.22.11.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Jun 2024 22:11:49 -0700 (PDT) From: Ryusuke Konishi To: Andrew Morton Cc: linux-nilfs , syzbot , syzkaller-bugs@googlegroups.com, LKML , hdanton@sina.com, jack@suse.cz, linux-fsdevel@vger.kernel.org, willy@infradead.org Subject: [PATCH 2/3] nilfs2: add missing check for inode numbers on directory entries Date: Sun, 23 Jun 2024 14:11:34 +0900 Message-Id: <20240623051135.4180-3-konishi.ryusuke@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240623051135.4180-1-konishi.ryusuke@gmail.com> References: <000000000000fe2d22061af9206f@google.com> <20240623051135.4180-1-konishi.ryusuke@gmail.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Syzbot reported that mounting and unmounting a specific pattern of corrupted nilfs2 filesystem images causes a use-after-free of metadata file inodes, which triggers a kernel bug in lru_add_fn(). As Jan Kara pointed out, this is because the link count of a metadata file gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(), tries to delete that inode (ifile inode in this case). The inconsistency occurs because directories containing the inode numbers of these metadata files that should not be visible in the namespace are read without checking. Fix this issue by treating the inode numbers of these internal files as errors in the sanity check helper when reading directory folios/pages. Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer analysis. Signed-off-by: Ryusuke Konishi Reported-by: syzbot+d79afb004be235636ee8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d79afb004be235636ee8 Reported-by: Jan Kara Closes: https://lkml.kernel.org/r/20240617075758.wewhukbrjod5fp5o@quack3 Tested-by: Ryusuke Konishi Cc: stable@vger.kernel.org --- fs/nilfs2/dir.c | 6 ++++++ fs/nilfs2/nilfs.h | 5 +++++ 2 files changed, 11 insertions(+) diff --git a/fs/nilfs2/dir.c b/fs/nilfs2/dir.c index 52e50b1b7f22..dddfa604491a 100644 --- a/fs/nilfs2/dir.c +++ b/fs/nilfs2/dir.c @@ -135,6 +135,9 @@ static bool nilfs_check_folio(struct folio *folio, char *kaddr) goto Enamelen; if (((offs + rec_len - 1) ^ offs) & ~(chunk_size-1)) goto Espan; + if (unlikely(p->inode && + NILFS_PRIVATE_INODE(le64_to_cpu(p->inode)))) + goto Einumber; } if (offs != limit) goto Eend; @@ -160,6 +163,9 @@ static bool nilfs_check_folio(struct folio *folio, char *kaddr) goto bad_entry; Espan: error = "directory entry across blocks"; + goto bad_entry; +Einumber: + error = "disallowed inode number"; bad_entry: nilfs_error(sb, "bad entry in directory #%lu: %s - offset=%lu, inode=%lu, rec_len=%zd, name_len=%d", diff --git a/fs/nilfs2/nilfs.h b/fs/nilfs2/nilfs.h index 7e39e277c77f..4017f7856440 100644 --- a/fs/nilfs2/nilfs.h +++ b/fs/nilfs2/nilfs.h @@ -121,6 +121,11 @@ enum { ((ino) >= NILFS_FIRST_INO(sb) || \ ((ino) < NILFS_USER_INO && (NILFS_SYS_INO_BITS & BIT(ino)))) +#define NILFS_PRIVATE_INODE(ino) ({ \ + ino_t __ino = (ino); \ + ((__ino) < NILFS_USER_INO && (__ino) != NILFS_ROOT_INO && \ + (__ino) != NILFS_SKETCH_INO); }) + /** * struct nilfs_transaction_info: context information for synchronization * @ti_magic: Magic number From patchwork Sun Jun 23 05:11:35 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ryusuke Konishi X-Patchwork-Id: 13708484 Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2B69F54903; Sun, 23 Jun 2024 05:11:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719119515; cv=none; b=f9CdbylR0Y2rzAGrLaAqJtyaVqTh6zZ90IMW88bxp6WXRCxh6UB3y2DUuzRkOzO7do1XFsjIRWJT4aD+ot26UAAGJ6mDb0Ew06cY1viMZkiK4B9GBse/2O91XkdbjcARAe7SsXFcFIkrcD89xi1HanFcV1sNBgy2t/py/AqPY0s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719119515; c=relaxed/simple; bh=xYJG8i+fuWApHBDCTAWc1UwRChxNBZW/laCKRJyFaE0=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=VprCeaaZt1um5RWp9ebSGfMEpiX2SpZp/pov9FL6eb14EoT4WA96lsry9Ocl6WOWZHdh3Me5CF5KxdYkOD1+s5CcyXGdljoNqtrWk3xf1+ghIDxvFZE5YoAKsugZ85L+zZcmE2o07/v/ovOAr/04mP3IvNcmbbKPZ1Ev/pmFJyE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=fEMsJt+n; arc=none smtp.client-ip=209.85.210.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fEMsJt+n" Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-706642b4403so669859b3a.1; Sat, 22 Jun 2024 22:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719119513; x=1719724313; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=RjnjBeEg2Eh+rau6hPT05sZEODPu6+al+eM3tFMwTLA=; b=fEMsJt+nhWzmUJYVeriWYf5aGs5a1mrTWSBmQLCLymtjM7ud/VnFGme7OIOvE8Y4vg MVjrYhGom2LPtSIbuU2uQp/0OYQjtiJu2nCGNg5rSPW9jvQ/5jwkPyBCzMpCpQncwwXk wjsOrKPjswfE4lpfONAMOHhkc48VzKXGe8Cg7iYg9gxAkRK/5Nu22Mil2Y7zEdt/lubN oV6PjgtUVi0/qM5rIhoebOUduASNkzMXBBlsSWD9OGzXZ4ou6+Pisi5Hnm6BGAs+IcXc FAIazh6T1UsjjDShZ3TLmuqdSa2hTcAYugdxaunPA5Ef9Gmrd4c9l3WlsmPJ/P1U1prW LyUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719119513; x=1719724313; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RjnjBeEg2Eh+rau6hPT05sZEODPu6+al+eM3tFMwTLA=; b=UqRNUvnpwfnYCqlHeCwMfoiIMDJFk2w5rWsTvIRj/AqZg11KrcvSgGnedUL0hpcHa8 Nb0E4xnDa1PWksf32RXd7N955ieJTrXDmaC18NcRr/Iqje2ljpdRxnNIbddDMvwawoLh Pn/vuagxRuUTNGSmudo1Mcl/gngdjUhY8HJsKOV2Zz3N4lWANx/T6IBKpy79keU5yC6x XVkVjuUx5siIceD8sFcuPbDxhuep9bB+63RaMPf92Z807DymsGcpXC3R206VWa8pTtaf SXbXVVi+v7iXGFemXeRRarZghyLGft+lgEvsOE167ATVJQhzfl2iDxHNht82KNGj87jH kanQ== X-Forwarded-Encrypted: i=1; AJvYcCV5lPvLWU/FgKcGoJIL5c/UphOX+vbHrIKBiDdY3HCMax9vTJ//NfQagmEX4o3YIN8oD26XrjN5LfT53Dnf24e0BmlhLdrilvp92gaEr/SIi92Jy3JL7vn0WXzA39tEptPaVT32bWD6bCC9gw== X-Gm-Message-State: AOJu0YyGl0b5DG61EMxBdayhNkFo9+sihYzCv/VtonJLoMqeXuVJ7Y+6 M0yii8ADKsbGQcWETGd2yRVsnEtZukFzlpwmw9+qx5FaOLWNkw6I X-Google-Smtp-Source: AGHT+IG3/AWgYvkNCTocWy0yKRiTkrWq4RAWHBWsaSthWvnc8UEYp3Uaz/6jmm/Mhwe2GTmaqkLPWg== X-Received: by 2002:aa7:824b:0:b0:706:3f17:ca2 with SMTP id d2e1a72fcca58-70669ecae02mr3320340b3a.0.1719119513305; Sat, 22 Jun 2024 22:11:53 -0700 (PDT) Received: from carrot.. (i114-180-52-104.s42.a014.ap.plala.or.jp. [114.180.52.104]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-706512d3034sm4042844b3a.170.2024.06.22.22.11.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Jun 2024 22:11:52 -0700 (PDT) From: Ryusuke Konishi To: Andrew Morton Cc: linux-nilfs , syzbot , syzkaller-bugs@googlegroups.com, LKML , hdanton@sina.com, jack@suse.cz, linux-fsdevel@vger.kernel.org, willy@infradead.org Subject: [PATCH 3/3] nilfs2: fix incorrect inode allocation from reserved inodes Date: Sun, 23 Jun 2024 14:11:35 +0900 Message-Id: <20240623051135.4180-4-konishi.ryusuke@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240623051135.4180-1-konishi.ryusuke@gmail.com> References: <000000000000fe2d22061af9206f@google.com> <20240623051135.4180-1-konishi.ryusuke@gmail.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 If the bitmap block that manages the inode allocation status is corrupted, nilfs_ifile_create_inode() may allocate a new inode from the reserved inode area where it should not be allocated. Previous fix commit d325dc6eb763 ("nilfs2: fix use-after-free bug of struct nilfs_root"), fixed the problem that reserved inodes with inode numbers less than NILFS_USER_INO (=11) were incorrectly reallocated due to bitmap corruption, but since the start number of non-reserved inodes is read from the super block and may change, in which case inode allocation may occur from the extended reserved inode area. If that happens, access to that inode will cause an IO error, causing the file system to degrade to an error state. Fix this potential issue by adding a wraparound option to the common metadata object allocation routine and by modifying nilfs_ifile_create_inode() to disable the option so that it only allocates inodes with inode numbers greater than or equal to the inode number read in "nilfs->ns_first_ino", regardless of the bitmap status of reserved inodes. Signed-off-by: Ryusuke Konishi Cc: stable@vger.kernel.org --- fs/nilfs2/alloc.c | 19 +++++++++++++++---- fs/nilfs2/alloc.h | 4 ++-- fs/nilfs2/dat.c | 2 +- fs/nilfs2/ifile.c | 7 ++----- 4 files changed, 20 insertions(+), 12 deletions(-) diff --git a/fs/nilfs2/alloc.c b/fs/nilfs2/alloc.c index 89caef7513db..ba50388ee4bf 100644 --- a/fs/nilfs2/alloc.c +++ b/fs/nilfs2/alloc.c @@ -377,11 +377,12 @@ void *nilfs_palloc_block_get_entry(const struct inode *inode, __u64 nr, * @target: offset number of an entry in the group (start point) * @bsize: size in bits * @lock: spin lock protecting @bitmap + * @wrap: whether to wrap around */ static int nilfs_palloc_find_available_slot(unsigned char *bitmap, unsigned long target, unsigned int bsize, - spinlock_t *lock) + spinlock_t *lock, bool wrap) { int pos, end = bsize; @@ -397,6 +398,8 @@ static int nilfs_palloc_find_available_slot(unsigned char *bitmap, end = target; } + if (!wrap) + return -ENOSPC; /* wrap around */ for (pos = 0; pos < end; pos++) { @@ -495,9 +498,10 @@ int nilfs_palloc_count_max_entries(struct inode *inode, u64 nused, u64 *nmaxp) * nilfs_palloc_prepare_alloc_entry - prepare to allocate a persistent object * @inode: inode of metadata file using this allocator * @req: nilfs_palloc_req structure exchanged for the allocation + * @wrap: whether to wrap around */ int nilfs_palloc_prepare_alloc_entry(struct inode *inode, - struct nilfs_palloc_req *req) + struct nilfs_palloc_req *req, bool wrap) { struct buffer_head *desc_bh, *bitmap_bh; struct nilfs_palloc_group_desc *desc; @@ -516,7 +520,7 @@ int nilfs_palloc_prepare_alloc_entry(struct inode *inode, entries_per_group = nilfs_palloc_entries_per_group(inode); for (i = 0; i < ngroups; i += n) { - if (group >= ngroups) { + if (group >= ngroups && wrap) { /* wrap around */ group = 0; maxgroup = nilfs_palloc_group(inode, req->pr_entry_nr, @@ -550,7 +554,14 @@ int nilfs_palloc_prepare_alloc_entry(struct inode *inode, bitmap_kaddr = kmap_local_page(bitmap_bh->b_page); bitmap = bitmap_kaddr + bh_offset(bitmap_bh); pos = nilfs_palloc_find_available_slot( - bitmap, group_offset, entries_per_group, lock); + bitmap, group_offset, entries_per_group, lock, + wrap); + /* + * Since the search for a free slot in the second and + * subsequent bitmap blocks always starts from the + * beginning, the wrap flag only has an effect on the + * first search. + */ kunmap_local(bitmap_kaddr); if (pos >= 0) goto found; diff --git a/fs/nilfs2/alloc.h b/fs/nilfs2/alloc.h index b667e869ac07..d825a9faca6d 100644 --- a/fs/nilfs2/alloc.h +++ b/fs/nilfs2/alloc.h @@ -50,8 +50,8 @@ struct nilfs_palloc_req { struct buffer_head *pr_entry_bh; }; -int nilfs_palloc_prepare_alloc_entry(struct inode *, - struct nilfs_palloc_req *); +int nilfs_palloc_prepare_alloc_entry(struct inode *inode, + struct nilfs_palloc_req *req, bool wrap); void nilfs_palloc_commit_alloc_entry(struct inode *, struct nilfs_palloc_req *); void nilfs_palloc_abort_alloc_entry(struct inode *, struct nilfs_palloc_req *); diff --git a/fs/nilfs2/dat.c b/fs/nilfs2/dat.c index 180fc8d36213..fc1caf63a42a 100644 --- a/fs/nilfs2/dat.c +++ b/fs/nilfs2/dat.c @@ -75,7 +75,7 @@ int nilfs_dat_prepare_alloc(struct inode *dat, struct nilfs_palloc_req *req) { int ret; - ret = nilfs_palloc_prepare_alloc_entry(dat, req); + ret = nilfs_palloc_prepare_alloc_entry(dat, req, true); if (ret < 0) return ret; diff --git a/fs/nilfs2/ifile.c b/fs/nilfs2/ifile.c index 612e609158b5..1e86b9303b7c 100644 --- a/fs/nilfs2/ifile.c +++ b/fs/nilfs2/ifile.c @@ -56,13 +56,10 @@ int nilfs_ifile_create_inode(struct inode *ifile, ino_t *out_ino, struct nilfs_palloc_req req; int ret; - req.pr_entry_nr = 0; /* - * 0 says find free inode from beginning - * of a group. dull code!! - */ + req.pr_entry_nr = NILFS_FIRST_INO(ifile->i_sb); req.pr_entry_bh = NULL; - ret = nilfs_palloc_prepare_alloc_entry(ifile, &req); + ret = nilfs_palloc_prepare_alloc_entry(ifile, &req, false); if (!ret) { ret = nilfs_palloc_get_entry_block(ifile, req.pr_entry_nr, 1, &req.pr_entry_bh);