Message ID | 20240229163011.16248-3-lhenriques@suse.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-87089-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2097:b0:108:e6aa:91d0 with SMTP id gs23csp526329dyb; Thu, 29 Feb 2024 08:41:26 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXDzC+CupoYwkbv1zA+SHpgOtPlZx1yfcxk+6t+uOQLbNCqEnahIkK4c8V3ZcvslwuZlVyoANE1lPm1o5J/U47M0qz0rg== X-Google-Smtp-Source: AGHT+IF2D5MsRrpctQ4HjROBqbr+RrXzy7uBtfcxvuUhV1YAbO4VB1eMkKVER+rOklQAfC9UMEGO X-Received: by 2002:a05:6e02:dee:b0:365:a941:1b7d with SMTP id m14-20020a056e020dee00b00365a9411b7dmr2666165ilj.18.1709224886442; Thu, 29 Feb 2024 08:41:26 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709224886; cv=pass; d=google.com; s=arc-20160816; b=TyykZthE38spXZwg2z30rI+ir7ICww2hXv22oZcK/txrSFZg8gRNPlaV3ff5rX/5v9 6eKlCLawvalDiRo+eEiDv9iCJPXKXrl3ycGUYIx4fS7LJzlERCW0XnYBwyqUz4dWk3Ys V1fTBicgO9IXWlLK2tMJtsylK0q6f8+v6VNstPpRXWTChNDUOqMNPE1ihsAaf4VAFq7z hjkUKPXuUdnG7xMUmLQ7ITHBKXNBDNz3OqDrXIGfrZ+tTELNXel9A4DcE2QUzk2Hq3BB hLyQAi7Qu/K+tkPicbATNwQzpZhFhJyv5kO93AZ5A11BDxEQETGYY5zCRE5l+4R5hSyW 8Xvg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from; bh=S35D1OR+mA1m+N+6brm0O8P0hi0mWzDKaobaBOcjjrg=; fh=jGdaoZ9f8fxaZ4S3XMcGs4Y5Dr6Ro1lg3HBgLAvBHb8=; b=yDMWGrqFtPxZtTqgPcitVArFyqcxRWOP+NFnYzYqVt75ZXe3QQRoI2EkOfQu6TFqRJ V90GU+T+r54j8DSvSdBYOZ37ddVyPS6FBfrd9tOrZECNciiJJ5B4K2B8OYNLgZcbsjoD CLRFEwnP9/isQMWnSXyB43wBG3EA+VBE6Vv3SCFDyyT1MUpHHyTda9b3Bt9WmUcwKgDS m+/TFED+fc0kUViVWx7cry2w6NvfgzzApeFgcZ78nGBhxXZnS/9F144FH0tmRIR7grgo EVlVex4WWUJ373oHMfUCP3wrNkQTMZZaagJlwHX++Mhu4pNJMxwHNYw2Ug79ED8LYAyk zn3A==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=suse.de dmarc=pass fromdomain=suse.de); spf=pass (google.com: domain of linux-kernel+bounces-87089-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-87089-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id b7-20020a056a000cc700b006e584551d6bsi1688211pfv.258.2024.02.29.08.41.26 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Feb 2024 08:41:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-87089-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=suse.de dmarc=pass fromdomain=suse.de); spf=pass (google.com: domain of linux-kernel+bounces-87089-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-87089-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id DAD6928BD01 for <ouuuleilei@gmail.com>; Thu, 29 Feb 2024 16:33:38 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C1F2F7A13B; Thu, 29 Feb 2024 16:30:21 +0000 (UTC) Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) (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 7D8FA160638; Thu, 29 Feb 2024 16:30:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.130 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709224220; cv=none; b=hBPv59AVeJOSCvrXCS0lIzE9e1rdEnAInjRJE4Kc+HI5O9xDN2zPnt2N3KmPnZ7RuS11p9nbzeRG+UI1LBuKNBJEcUu/RI7xCeTKHm9iyQoVOYRGm3EX3kJMmvB2EmwOZJyCg9jugxDlLNopWyi1FeY607WjFEVuLkmjBds2A80= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709224220; c=relaxed/simple; bh=vTk9qY7Ap4iFsr2Q/nS6b1xXOiZqaEGYtgbyecVJ1DA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=q9RA8N867OCZN485wPgnbFg9UUjtqoKbz6+PdKT2hqIME4z2MheIq/8rKYQmmXJSGkBSXllNOezjo/7LmhkxxFC+Q1f9I5QzsZaPsj0bfedfdVlQQe7vKbwFKLxnpDUpc8SagBlGWaiI0VarGRL1J8n1yyaob/TF51lxEi25DZw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=suse.de; spf=pass smtp.mailfrom=suse.de; arc=none smtp.client-ip=195.135.223.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.de Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id C35BD21E07; Thu, 29 Feb 2024 16:30:16 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 0355813A4B; Thu, 29 Feb 2024 16:30:15 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id MMIpORex4GU0PwAAD6G6ig (envelope-from <lhenriques@suse.de>); Thu, 29 Feb 2024 16:30:15 +0000 Received: from localhost (brahms.olymp [local]) by brahms.olymp (OpenSMTPD) with ESMTPA id 71ffe845; Thu, 29 Feb 2024 16:30:14 +0000 (UTC) From: Luis Henriques <lhenriques@suse.de> To: Theodore Ts'o <tytso@mit.edu>, Andreas Dilger <adilger.kernel@dilger.ca>, Alexander Viro <viro@zeniv.linux.org.uk>, Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>, Miklos Szeredi <miklos@szeredi.hu>, Amir Goldstein <amir73il@gmail.com> Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org, Luis Henriques <lhenriques@suse.de> Subject: [PATCH 2/3] ext4: fix mount parameters check for empty values Date: Thu, 29 Feb 2024 16:30:09 +0000 Message-ID: <20240229163011.16248-3-lhenriques@suse.de> In-Reply-To: <20240229163011.16248-1-lhenriques@suse.de> References: <20240229163011.16248-1-lhenriques@suse.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Level: Authentication-Results: smtp-out1.suse.de; none X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Spam-Score: -4.00 X-Rspamd-Queue-Id: C35BD21E07 X-Spam-Flag: NO X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1792252194676708737 X-GMAIL-MSGID: 1792252194676708737 |
Series |
fs_parser: handle parameters that can be empty and don't have a value
|
|
Commit Message
Luis Henriques
Feb. 29, 2024, 4:30 p.m. UTC
Now that parameters that have the flag 'fs_param_can_be_empty' set and
their value is NULL are handled as 'flag' type, we need to properly check
for empty (NULL) values.
Signed-off-by: Luis Henriques <lhenriques@suse.de>
---
fs/ext4/super.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
On Thu, Feb 29, 2024 at 04:30:09PM +0000, Luis Henriques wrote: > Now that parameters that have the flag 'fs_param_can_be_empty' set and > their value is NULL are handled as 'flag' type, we need to properly check > for empty (NULL) values. > > Signed-off-by: Luis Henriques <lhenriques@suse.de> > --- > fs/ext4/super.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/ext4/super.c b/fs/ext4/super.c > index 0f931d0c227d..44ba2212dfb3 100644 > --- a/fs/ext4/super.c > +++ b/fs/ext4/super.c > @@ -2183,12 +2183,12 @@ static int ext4_parse_param(struct fs_context *fc, struct fs_parameter *param) > switch (token) { > #ifdef CONFIG_QUOTA > case Opt_usrjquota: > - if (!*param->string) > + if (!param->string) > return unnote_qf_name(fc, USRQUOTA); I fail to understand how that can happen. Currently both of these options are parsed as strings via: #define fsparam_string_empty(NAME, OPT) \ __fsparam(fs_param_is_string, NAME, OPT, fs_param_can_be_empty, NULL) So if someone sets fsconfig(..., FSCONFIG_SET_STRING, "usrquota", NULL, ...) we give an immediate case FSCONFIG_SET_STRING: if (!_key || !_value || aux) return -EINVAL; from fsconfig() so we know that param->string cannot be NULL. If that were the case we'd NULL deref in fs_param_is_string(): int fs_param_is_string(struct p_log *log, const struct fs_parameter_spec *p, struct fs_parameter *param, struct fs_parse_result *result) { if (param->type != fs_value_is_string || (!*param->string && !(p->flags & fs_param_can_be_empty))) So you're check above seems wrong. If I'm mistaken, please explain, how this can happen in detail.
Christian Brauner <brauner@kernel.org> writes: > On Thu, Feb 29, 2024 at 04:30:09PM +0000, Luis Henriques wrote: >> Now that parameters that have the flag 'fs_param_can_be_empty' set and >> their value is NULL are handled as 'flag' type, we need to properly check >> for empty (NULL) values. >> >> Signed-off-by: Luis Henriques <lhenriques@suse.de> >> --- >> fs/ext4/super.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/fs/ext4/super.c b/fs/ext4/super.c >> index 0f931d0c227d..44ba2212dfb3 100644 >> --- a/fs/ext4/super.c >> +++ b/fs/ext4/super.c >> @@ -2183,12 +2183,12 @@ static int ext4_parse_param(struct fs_context *fc, struct fs_parameter *param) >> switch (token) { >> #ifdef CONFIG_QUOTA >> case Opt_usrjquota: >> - if (!*param->string) >> + if (!param->string) >> return unnote_qf_name(fc, USRQUOTA); > > I fail to understand how that can happen. Currently both of these > options are parsed as strings via: > > #define fsparam_string_empty(NAME, OPT) \ > __fsparam(fs_param_is_string, NAME, OPT, fs_param_can_be_empty, NULL) > > > So if someone sets fsconfig(..., FSCONFIG_SET_STRING, "usrquota", NULL, ..) > we give an immediate > > case FSCONFIG_SET_STRING: > if (!_key || !_value || aux) return -EINVAL; > > from fsconfig() so we know that param->string cannot be NULL. If that > were the case we'd NULL deref in fs_param_is_string(): > > int fs_param_is_string(struct p_log *log, const struct fs_parameter_spec *p, > struct fs_parameter *param, struct fs_parse_result *result) > { > if (param->type != fs_value_is_string || > (!*param->string && !(p->flags & fs_param_can_be_empty))) > > So you're check above seems wrong. If I'm mistaken, please explain, how > this can happen in detail. I hope my reply to the previous patch helps clarifying this issue (which is quite confusing, and I'm probably the confused one!). To summarize, fsconfig() will (or can) get this parameter as a flag, not as string. Cheers,
diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 0f931d0c227d..44ba2212dfb3 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -2183,12 +2183,12 @@ static int ext4_parse_param(struct fs_context *fc, struct fs_parameter *param) switch (token) { #ifdef CONFIG_QUOTA case Opt_usrjquota: - if (!*param->string) + if (!param->string) return unnote_qf_name(fc, USRQUOTA); else return note_qf_name(fc, USRQUOTA, param); case Opt_grpjquota: - if (!*param->string) + if (!param->string) return unnote_qf_name(fc, GRPQUOTA); else return note_qf_name(fc, GRPQUOTA, param);