Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3867440pxv; Mon, 19 Jul 2021 10:39:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxD2oouufs+yqZ6kKCz/UpKap3CVXqD08ZpEa6IV1RpEAwybWwMdFnPQjJjAptLrJdYQOd3 X-Received: by 2002:a92:1e06:: with SMTP id e6mr17829895ile.258.1626716345107; Mon, 19 Jul 2021 10:39:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626716345; cv=none; d=google.com; s=arc-20160816; b=g8ndrz+Zzaz54lFz3xyyWv29+PwXs70CfTUfm57HCc6BzjhfxOg08gZDjQdY1fwuyW /FcuR04mtXV0+g8zKa/9MySohXmEAdzRFGPvcMbwA+CvMnTIyID6J3VMuVeGRgeTibiv d/XnlloKdiWEWuYKck45imuQ7/2aoMbJNjhoZvV62+s7XJL+kSiMFdoGvZTgnO2iNm0p SlZpgc/O3PLngAzxdGxIuT9QQwmXdU9PLMjBkLMVhacJQcvX/Y4fHtBXildfZgrHKooY MtUXgCc86eYjrJ+ZztUifmwC9kZypzjJQHXj/oDurcdHKzB6WyP51BHgf5EKEsgJRmzj E7cA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=1BA8n7yoQuds0k4OaTqITGQzuAHtT/eSrdMScdoG2cM=; b=IUYSgqxDe5Hsip01h35l+k/KsDqIhm4tGjYcWEgQp+tVT+M/oxCyxbFTrMhlwZO4Xz /y5mgLIDqWgxuPIG6Ru43arhPrpyII2UB80mVIF+pTS7cfIVELt7rkLh3x73i7lwMI13 xxoNZb1ZTIxeOSSfTdBVwtPZd7xedzVoQ+2COO2TJn4XGQkwwY4sdYjSuOH5Xx/XCWvR iSzLUZsU1DrUIg8muLQIQMYR0Ci0LgzF2/AHzNQfy9ht7iZUGUEQnRbKf10vceetEkdN tuCE+APDqYZjfgK4T6Gnn58oiOIOyH9o/rRQbw+Nj4s121jdmBIOqgFK8a/44/OV+fTU 38fg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=FjStnsa0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i9si21880772ioq.17.2021.07.19.10.38.53; Mon, 19 Jul 2021 10:39:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=FjStnsa0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347522AbhGSQ5p (ORCPT + 99 others); Mon, 19 Jul 2021 12:57:45 -0400 Received: from mail.kernel.org ([198.145.29.99]:57556 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347525AbhGSPTb (ORCPT ); Mon, 19 Jul 2021 11:19:31 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5C3BC61414; Mon, 19 Jul 2021 15:58:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1626710298; bh=FL1PTp73Fvj1PbY80kEq4ykA3rIwBqcs8t7Gm9YEcew=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FjStnsa0h7WDDUwBS6Q2gU+c6UvvbhL/z/jqqpflEnzukL8tdCUFJjvgt2vJ00Esu ly8Vokxdf4rOLXOi95ydxIAV5R9a5PNJl4o82lqWP5Lsg3D0jh/Jm+/UL/axgaM6I2 /fKZqXdFV7bmEs3n+TfQBxAAcvg87R0pR22GyB2A= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sascha Hauer , Richard Weinberger , Sasha Levin Subject: [PATCH 5.10 159/243] ubifs: Fix off-by-one error Date: Mon, 19 Jul 2021 16:53:08 +0200 Message-Id: <20210719144946.037816548@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210719144940.904087935@linuxfoundation.org> References: <20210719144940.904087935@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sascha Hauer [ Upstream commit d984bcf5766dbdbe95d325bb8a1b49a996fecfd4 ] An inode is allowed to have ubifs_xattr_max_cnt() xattrs, so we must complain only when an inode has more xattrs, having exactly ubifs_xattr_max_cnt() xattrs is fine. With this the maximum number of xattrs can be created without hitting the "has too many xattrs" warning when removing it. Signed-off-by: Sascha Hauer Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin --- fs/ubifs/journal.c | 2 +- fs/ubifs/xattr.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ubifs/journal.c b/fs/ubifs/journal.c index 091c2ad8f211..7927dea2baba 100644 --- a/fs/ubifs/journal.c +++ b/fs/ubifs/journal.c @@ -881,7 +881,7 @@ int ubifs_jnl_write_inode(struct ubifs_info *c, const struct inode *inode) struct inode *xino; struct ubifs_dent_node *xent, *pxent = NULL; - if (ui->xattr_cnt >= ubifs_xattr_max_cnt(c)) { + if (ui->xattr_cnt > ubifs_xattr_max_cnt(c)) { ubifs_err(c, "Cannot delete inode, it has too much xattrs!"); goto out_release; } diff --git a/fs/ubifs/xattr.c b/fs/ubifs/xattr.c index 09280796fc61..17745f5462f0 100644 --- a/fs/ubifs/xattr.c +++ b/fs/ubifs/xattr.c @@ -512,7 +512,7 @@ int ubifs_purge_xattrs(struct inode *host) struct fscrypt_name nm = {0}; int err; - if (ubifs_inode(host)->xattr_cnt < ubifs_xattr_max_cnt(c)) + if (ubifs_inode(host)->xattr_cnt <= ubifs_xattr_max_cnt(c)) return 0; ubifs_warn(c, "inode %lu has too many xattrs, doing a non-atomic deletion", -- 2.30.2