Greg, On Fri, Feb 04, 2022 at 04:16:06PM +0100, Greg Kurz wrote: > On Fri, 04 Feb 2022 15:12:18 +0100 > Christian Schoenebeck <qemu_...@crudebyte.com> wrote: > > > On Freitag, 4. Februar 2022 14:55:45 CET Philippe Mathieu-Daudé via wrote: > > > On 4/2/22 06:06, Vitaly Chikunov wrote: > > > > `struct dirent' returned from readdir(3) could be shorter (or longer) > > > > than `sizeof(struct dirent)', thus memcpy of sizeof length will overread > > > > > > > > into unallocated page causing SIGSEGV. Example stack trace: > > > > #0 0x00005555559ebeed v9fs_co_readdir_many > > > > (/usr/bin/qemu-system-x86_64 > > > > + 0x497eed) #1 0x00005555559ec2e9 v9fs_readdir > > > > (/usr/bin/qemu-system-x86_64 + 0x4982e9) #2 0x0000555555eb7983 > > > > coroutine_trampoline (/usr/bin/qemu-system-x86_64 + 0x963983) #3 > > > > 0x00007ffff73e0be0 n/a (n/a + 0x0) > > > > > > > > While fixing, provide a helper for any future `struct dirent' cloning. > > > > > > > > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/841 > > > > Cc: qemu-sta...@nongnu.org > > > > Co-authored-by: Christian Schoenebeck <qemu_...@crudebyte.com> > > > > Signed-off-by: Vitaly Chikunov <v...@altlinux.org> > > > > --- > > > > Tested on x86-64 Linux again. > > > > > > > > Changes from v2: > > > > - Make it work with a simulated dirent where d_reclen is 0, which was > > > > > > > > caused abort in readdir qos-test, by using fallback at runtime. > > > > > > > > hw/9pfs/codir.c | 3 +-- > > > > include/qemu/osdep.h | 13 +++++++++++++ > > > > util/osdep.c | 18 ++++++++++++++++++ > > > > 3 files changed, 32 insertions(+), 2 deletions(-) > > > > > > > > +struct dirent * > > > > +qemu_dirent_dup(struct dirent *dent) > > > > +{ > > > > + size_t sz = 0; > > > > +#if defined _DIRENT_HAVE_D_RECLEN > > > > + /* Avoid use of strlen() if there's d_reclen. */ > > > > + sz = dent->d_reclen; > > > > +#endif > > > > + if (sz == 0) { > > > > > > If _DIRENT_HAVE_D_RECLEN is defined, this case is unlikely... > > > > > > > + /* Fallback to the most portable way. */ > > > > + sz = offsetof(struct dirent, d_name) + > > > > + strlen(dent->d_name) + 1; > > > > + } > > > > + struct dirent *dst = g_malloc(sz); > > > > + return memcpy(dst, dent, sz); > > > > +} > > > > > > What about this? > > > > > > struct dirent * > > > qemu_dirent_dup(struct dirent *dent) > > > { > > > size_t sz; > > > > > > #if defined _DIRENT_HAVE_D_RECLEN > > > /* Avoid use of strlen() if there's d_reclen. */ > > > sz = dent->d_reclen; > > > #else > > > /* Fallback to the most portable way. */ > > > sz = offsetof(struct dirent, d_name) + > > > strlen(dent->d_name) + 1; > > > #endif > > > > > > return g_memdup(dent, sz); > > > } > > > > That was the intentional change v2 -> v3 Philippe. Previous v2 crashed the > > 9p 'synth' tests: > > > > https://lore.kernel.org/qemu-devel/2627488.0S70g7mNYN@silver/T/#ma09bedde59a91e6435443e151f7e49fef8616e4c > > > > You might argue that the 9p 'synth' driver should instead populate d_reclen > > instead, but this v3 is a simpler solution and guarantees to always work. So > > I'd prefer to go with Vitaly's v3 for now, especially as this patch would go > > to the stable branches as well. > > > > This really is a band-aid. Anyone reading this will react as Philippe, > and this is common code, not just 9pfs. With correctly populated dirents, > the helper could be as simple as: > > 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. > > return g_memdup(dent, sz); > } > > If this is a cycles problem, If you don't like d_reclen speed ups, we can always just use most portable strlen method. Vitaly, > I can help reviewing the fixes on > the synth driver, or alternatively you can keep this code > somewhere under 9pfs but please don't put that in common utils. > > Cheers, > > -- > Greg > > > Best regards, > > Christian Schoenebeck > > > >
