qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kurz <groug@kaod.org>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: "Vitaly Chikunov" <vt@altlinux.org>,
	qemu-stable@nongnu.org, ldv@altlinux.org, qemu-devel@nongnu.org,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>
Subject: Re: [PATCH v3] 9pfs: Fix segfault in do_readdir_many caused by struct dirent overread
Date: Fri, 4 Feb 2022 16:16:06 +0100	[thread overview]
Message-ID: <20220204161606.162d2c05@bahia> (raw)
In-Reply-To: <28345882.VnrBaU8NEn@silver>

On Fri, 04 Feb 2022 15:12:18 +0100
Christian Schoenebeck <qemu_oss@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-stable@nongnu.org
> > > Co-authored-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
> > > Signed-off-by: Vitaly Chikunov <vt@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;

    return g_memdup(dent, sz);
}

If this is a cycles problem, 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
> 
> 



  reply	other threads:[~2022-02-04 15:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-04  5:06 [PATCH v3] 9pfs: Fix segfault in do_readdir_many caused by struct dirent overread Vitaly Chikunov
2022-02-04 12:08 ` Christian Schoenebeck
2022-02-04 12:15 ` Dmitry V. Levin
2022-02-04 12:17   ` Dmitry V. Levin
2022-02-04 13:55 ` Philippe Mathieu-Daudé via
2022-02-04 14:12   ` Christian Schoenebeck
2022-02-04 15:16     ` Greg Kurz [this message]
2022-02-04 15:32       ` Vitaly Chikunov
2022-02-04 15:50         ` Dmitry V. Levin
2022-02-04 15:54           ` Philippe Mathieu-Daudé via
2022-02-04 16:04             ` Christian Schoenebeck
2022-02-04 19:31               ` Philippe Mathieu-Daudé via
2022-02-04 15:33       ` Christian Schoenebeck
2022-02-04 16:19   ` Dmitry V. Levin
2022-02-05  3:23     ` Vitaly Chikunov
2022-02-05  5:58     ` Greg Kurz
2022-02-05 11:36 ` Christian Schoenebeck
2022-02-05 11:58   ` Philippe Mathieu-Daudé via

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=20220204161606.162d2c05@bahia \
    --to=groug@kaod.org \
    --cc=f4bug@amsat.org \
    --cc=ldv@altlinux.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=qemu_oss@crudebyte.com \
    --cc=vt@altlinux.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;
as well as URLs for NNTP newsgroup(s).