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.
next prev parent 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