Re: [PATCH v3] 9pfs: Fix segfault in do_readdir_many caused by struct dirent overread

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Freitag, 4. Februar 2022 16:54:12 CET Philippe Mathieu-Daudé wrote:
> On 4/2/22 16:50, Dmitry V. Levin wrote:
> > On Fri, Feb 04, 2022 at 06:32:07PM +0300, Vitaly Chikunov wrote:
> > [...]
> > 
> >>> struct dirent *
> >>> qemu_dirent_dup(struct dirent *dent)
> >>> {
> >>> 
> >>>      size_t sz = offsetof(struct dirent, d_name) + _D_EXACT_NAMLEN(dent)
> >>>      + 1;
> >> 
> >> But d_namlen is not populated by synth_direntry, so this will lead to
> >> a bug too. Idea is that qemu_dirent_dup handles real dirents and
> >> simulated (underpopulated) dirents.
> >> 
> >> Also Linux does not have d_namlen AFAIK, thus this code will not provide
> >> any speed up in most cases (and always fallback to strlen), unlike if we
> >> use d_reclen.
> >> 
> >> Also, I m not sure if _D_EXACT_NAMLEN is defined on all systems, so this
> >> needs ifdefs too.
> > 
> > Yes, _D_EXACT_NAMLEN() is a GNU extension, it was introduced in glibc
> > back in 1996 but some popular libcs available for Linux do not provide
> > this macro.
> 
> Can't we define _D_EXACT_NAMLEN() if not available?

It is not that trivial.

With recent macOS patch set in mind: macOS does not have any of these macros 
either. It does have d_namlen and d_reclen though. Keep in mind though that 
macOS also has d_seekoff which is almost always zero though.

So please, don't blindly define something, test it! On doubt I stick with 
Vitaly's solution, because it just works^TM.

On the long term we can still adjust this to make all people happy, but this 
is about fixing a crash, so I am fine with what Greg called "band-aid".

Best regards,
Christian Schoenebeck