Linux XFS filesystem development
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: vmfunc <celeste@collar.sh>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
	linux-xfs@vger.kernel.org, Carlos Maiolino <cem@kernel.org>,
	Andrey Albershteyn <aalbersh@kernel.org>
Subject: Re: [PATCH] xfsdump: avoid false-positive __strcpy_chk abort on long dirent names
Date: Fri, 26 Jun 2026 01:09:47 -0700	[thread overview]
Message-ID: <aj4zy64RwzgALUdM@infradead.org> (raw)
In-Reply-To: <178243370553.73182.935356806206037088@collar.sh>

On Fri, Jun 26, 2026 at 12:28:27AM +0000, vmfunc wrote:
> On Thu, Jun 25, 2026 at 03:57:58PM -0700, Darrick J. Wong wrote:
> > Why wouldn't you fix the structure definitions to use the proper VLA
> > syntax (dh_name[]) instead of making the code less readable?
> 
> looked at that first but dh_name[] doesnt drop in cleanly here. the
> declared size isnt slack padding, its the count of name bytes carried
> inline in the fixed-size on-media header, n read_dirent() in
> restore/content.c reads the record back out using sizeof() of that member:
> 
> 	namep = dhdrp->dh_name + sizeof(dhdrp->dh_name);
> 	memcpy(dhdrp->dh_name, dhdr_v1.dh_name, sizeof(dhdr_v1.dh_name));

To me it looks like the problem is that mix up the on-disk and
in-memory structure with different semantics here.  The somewhat
more invasive fix would be to split the

direnthdr structure into an in-memory direnthdr one, and an on-disk
direnthdr_v3.  The former would use a VLA, and the latter the existing
hard coded value.  This would also allow to make the endian conversion
in xlate_direnthdr/xlate_direnthdr_v1 type safe.


  reply	other threads:[~2026-06-26  8:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-25 22:23 [PATCH] xfsdump: avoid false-positive __strcpy_chk abort on long dirent names vmfunc
2026-06-25 22:57 ` Darrick J. Wong
2026-06-26  0:28   ` vmfunc
2026-06-26  8:09     ` Christoph Hellwig [this message]
2026-06-26  8:11     ` Andrey Albershteyn
2026-07-02 19:58       ` Celeste
2026-07-03 13:03         ` Christoph Hellwig
2026-07-03 15:49           ` Darrick J. Wong

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=aj4zy64RwzgALUdM@infradead.org \
    --to=hch@infradead.org \
    --cc=aalbersh@kernel.org \
    --cc=celeste@collar.sh \
    --cc=cem@kernel.org \
    --cc=djwong@kernel.org \
    --cc=linux-xfs@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