From: Guoxin Pu <pugokushin@gmail.com>
To: David Laight <David.Laight@ACULAB.COM>,
"axboe@kernel.dk" <axboe@kernel.dk>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] block: fix length of strscpy()
Date: Tue, 2 Jan 2024 10:31:27 +0800 [thread overview]
Message-ID: <c7e29d85-277d-46ae-87ae-bb77dd423652@gmail.com> (raw)
In-Reply-To: <ed0b9dd45fca4f6e910a9e1ffa756180@AcuMS.aculab.com>
Thank you for the review. Sorry if this is the duplicated reply, as I
didn't configure my mail client to send text-only message and the
previous mail was rejected by the list.
On 02/01/2024 05:47, David Laight wrote:
>> @@ -79,8 +79,8 @@ static int parse_subpart(struct cmdline_subpart **subpart, char *partdef)
>> goto fail;
>> }
>>
>> - length = min_t(int, next - partdef,
>> - sizeof(new_subpart->name) - 1);
>> + length = min_t(int, next - partdef + 1,
>> + sizeof(new_subpart->name));
>> strscpy(new_subpart->name, partdef, length);
> Shouldn't that be a memcpy() with the original length?
> Since it looks as though there is something equivalent to:
> next = strchr(partdef, ',');
> just above?
> Maybe with:
> new_subpart->name[length] = '\0';
> if the target isn't zero filled (which the strncpy() probably
> relied on.)
Yes that would be better. But since I'm fixing the issue caused by the
mentioned commit, which was an accepted change to use strscpy instead of
strncpy and seems a part of a series of changes to do that, I think
there might be a reason the maintainers preferred strscpy over strncpy
over memcpy? Otherwise we could just revert that commit and keep using
the original strncpy + setting NULL method, and then potentially swap
strncpy with memcpy.
On 02/01/2024 05:47, David Laight wrote:
> Same
Same.
On 02/01/2024 05:47, David Laight wrote:
>> @@ -262,7 +262,7 @@ static int add_part(int slot, struct cmdline_subpart *subpart,
>>
>> info = &state->parts[slot].info;
>>
>> - label_min = min_t(int, sizeof(info->volname) - 1,
>> + label_min = min_t(int, sizeof(info->volname),
>> sizeof(subpart->name));
>> strscpy(info->volname, subpart->name, label_min);
> WTF?
> That only makes any sense if subpart->name might not be '\0'
> terminated - which strncpy() would have handled fine (with the -1).
> Otherwise what is wrong with:
> strscpy(info->volname, subpart->name, sizeof (info->volname));
>
> David
Yes, there is no need to calculate label_min here. We could remove int
label_min altogether in this function and use a single line of strscpy.
next prev parent reply other threads:[~2024-01-02 2:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-01 17:50 [PATCH] block: fix length of strscpy() Guoxin Pu
2024-01-01 21:26 ` Jens Axboe
2024-01-17 6:11 ` Guoxin Pu
2024-01-01 21:47 ` David Laight
2024-01-02 2:31 ` Guoxin Pu [this message]
2024-01-02 9:14 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c7e29d85-277d-46ae-87ae-bb77dd423652@gmail.com \
--to=pugokushin@gmail.com \
--cc=David.Laight@ACULAB.COM \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox