From: Philippe De Muyter <phdm@macqel.be>
To: tt roxy <roxy520tt@gmail.com>
Cc: Ren Wei <n05ec@lzu.edu.cn>,
linux-block@vger.kernel.org, axboe@kernel.dk, kees@kernel.org,
hexlabsecurity@proton.me, objecting@objecting.org,
akpm@linux-foundation.org, yuantan098@gmail.com, bird@lzu.edu.cn
Subject: Re: [PATCH 1/1] block: partition: aix: bound LV name formatting
Date: Sun, 28 Jun 2026 18:40:16 +0200 [thread overview]
Message-ID: <20260628164016.GA23966@frolo.corp.macq.eu> (raw)
In-Reply-To: <CALMqdkS0arRS5FSsbPBiHAZzU-NeDEBhm01-r5v00GFQN=sx8w@mail.gmail.com>
Hello tt roxy,
On Sat, Jun 27, 2026 at 12:37:50PM +0800, tt roxy wrote:
> On Sat, Jun 27, 2026 at 4:50 AM Philippe De Muyter <phdm@macqel.be> wrote:
> >
> > Hello Ren Wei,
> >
> > On Fri, Jun 26, 2026 at 03:21:22PM +0800, Ren Wei wrote:
> > > From: Zhiling Zou <roxy520tt@gmail.com>
> > > @@ -273,7 +274,8 @@ int aix_partition(struct parsed_partitions *state)
> > > if (lvip[i].pps_found && !lvip[i].lv_is_contiguous) {
> > > char tmp[sizeof(n[i].name) + 1]; // null char
> > >
> > > - snprintf(tmp, sizeof(tmp), "%s", n[i].name);
> > > + snprintf(tmp, sizeof(tmp), "%.*s",
> > > + (int)sizeof(n[i].name), n[i].name);
> >
> > Is this change necessary ? snprintf always adds a NULL terminator and
> > truncates the input if needed, isn't it ?
> >
>
> Yes, snprintf() guarantees that the destination buffer is
> NUL-terminated and truncates the output.
>
> However, with %s and no precision, snprintf() still treats n[i].name as
> a NUL-terminated source string. If the on-disk fixed-size name field is
> not NUL-terminated, snprintf() can keep reading past the end of
> n[i].name while looking for the terminator, before truncating the output
> into tmp.
>
> So the issue is not an overflow of tmp, but an out-of-bounds read from
> the fixed-width source field. The precision is needed to bound that
> source read to sizeof(n[i].name).
>
> > > pr_warn("partition %s (%u pp's found) is "
> > > "not contiguous\n",
> > > tmp, lvip[i].pps_found);
> > > --
Actually the 'tmp' buffer is not needed. Printing directky n[i].name
with '%.*s' in pr_warn would be enough to fix the problem IMHO.
Philippe
prev parent reply other threads:[~2026-06-28 16:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1782398104.git.roxy520tt@gmail.com>
2026-06-26 7:21 ` [PATCH 1/1] block: partition: aix: bound LV name formatting Ren Wei
2026-06-26 9:09 ` Philippe De Muyter
2026-06-27 4:37 ` tt roxy
2026-06-28 16:40 ` Philippe De Muyter [this message]
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=20260628164016.GA23966@frolo.corp.macq.eu \
--to=phdm@macqel.be \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=bird@lzu.edu.cn \
--cc=hexlabsecurity@proton.me \
--cc=kees@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=n05ec@lzu.edu.cn \
--cc=objecting@objecting.org \
--cc=roxy520tt@gmail.com \
--cc=yuantan098@gmail.com \
/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