[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PULL 0/5] 9p queue 2022-02-10
From: |
Christian Schoenebeck |
Subject: |
Re: [PULL 0/5] 9p queue 2022-02-10 |
Date: |
Mon, 14 Feb 2022 18:40:31 +0100 |
On Montag, 14. Februar 2022 15:43:51 CET Vitaly Chikunov wrote:
> Christian,
>
> On Mon, Feb 14, 2022 at 12:44:48PM +0100, Christian Schoenebeck wrote:
> > On Montag, 14. Februar 2022 11:36:53 CET Greg Kurz wrote:
> > > The synth backend should be fixed to honor d_reclen, or
> > > at least to allocate with g_new0().
> >
> > Yes, I overlooked that this is not initialized with zero already.
> >
> > With g_new0() d_reclen would be zero and qemu_dirent_dup() would then
> > fallback
> > to the portable branch (as I assumed it already would):
> Perhaps, this additional change should be added (I only found two instances
> of V9fsSynthOpenState allocation):
>
> diff --git a/hw/9pfs/9p-synth.c b/hw/9pfs/9p-synth.c
> --- a/hw/9pfs/9p-synth.c
> +++ b/hw/9pfs/9p-synth.c
> @@ -182,7 +182,7 @@ static int synth_opendir(FsContext *ctx,
> V9fsSynthOpenState *synth_open;
> V9fsSynthNode *node = *(V9fsSynthNode **)fs_path->data;
>
> - synth_open = g_malloc(sizeof(*synth_open));
> + synth_open = g_malloc0(sizeof(*synth_open));
> synth_open->node = node;
> node->open_count++;
> fs->private = synth_open;
> @@ -266,7 +266,7 @@ static int synth_open(FsContext *ctx, V9fsPath *fs_path,
> V9fsSynthOpenState *synth_open;
> V9fsSynthNode *node = *(V9fsSynthNode **)fs_path->data;
>
> - synth_open = g_malloc(sizeof(*synth_open));
> + synth_open = g_malloc0(sizeof(*synth_open));
> synth_open->node = node;
> node->open_count++;
> fs->private = synth_open;
Either
/*
* Add NAME_MAX to ensure there is enough space for 'dent' member, because
* some systems have d_name size of just 1, which would cause a buffer
* overrun.
*/
synth_open = g_malloc0(sizeof(*synth_open) + NAME_MAX);
Or more simple by adjusting struct V9fsSynthOpenState:
index 036d7e4a5b..eeb246f377 100644
--- a/hw/9pfs/9p-synth.h
+++ b/hw/9pfs/9p-synth.h
@@ -41,6 +41,11 @@ typedef struct V9fsSynthOpenState {
off_t offset;
V9fsSynthNode *node;
struct dirent dent;
+ /*
+ * Ensure there is enough space for 'dent' above, some systems have a
+ * d_name size of just 1, which would cause a buffer overrun.
+ */
+ char dent_trailing_space[NAME_MAX];
} V9fsSynthOpenState;
int qemu_v9fs_synth_mkdir(V9fsSynthNode *parent, int mode,
and of course still replacing g_malloc() by g_malloc0().
> > Additionally I would add NAME_MAX to the V9fsSynthOpenState allocation
> > size, because it is known that some systems define dirent as flex-array
> > (zero d_name size).
>
> (To be precise) not just zero, but 1 byte. Also, to remind, for some
> filesystems, such as CIFS, actual d_name size could be longer than NAME_MAX.
> Because of that struct dirent cannot be allocated statically or with simple
> sizeof.
Yes, but the dir names in the synth driver are just short hard coded names
anyway, there is no access to a real filesystem going on in the synth driver.
> > I know Greg would not favour this solution (using g_new0), but it's the
> > most minimalistic and most portable solution. So I would favour it for
> > now.
> Why g_new0 and not just g_malloc0? This is smallest code change, which seems
> appropriate for a bug fix.
Both are fine with me in this case.
>
> Thanks,
>
> > A cleaner solution on the long-term would be turning V9fsSynthOpenState's
> > 'dent' member into a pointer and adding a new function to osdep like:
> >
> > struct dirent *
> > qemu_dirent_new(const char* name) {
> >
> > ...
> >
> > }
> >
> > But I would like to postpone that qemu_dirent_new() solution, e.g. because
> > I guess some people would probably not like qemu_dirent_new() to have in
> > osdep, as it is probably not a general purpose function, and I am not
> > keen putting qemu_dirent_new() into a different location than
> > qemu_dirent_dup(), because it would raise the danger that system
> > dependent code might deviate in future.
> >
> > Best regards,
> > Christian Schoenebeck
- [PULL 3/5] tests/9pfs: Fix leak of local_test_path, (continued)
- [PULL 3/5] tests/9pfs: Fix leak of local_test_path, Christian Schoenebeck, 2022/02/10
- [PULL 5/5] 9pfs: Fix segfault in do_readdir_many caused by struct dirent overread, Christian Schoenebeck, 2022/02/10
- [PULL 1/5] tests/9pfs: use g_autofree where possible, Christian Schoenebeck, 2022/02/10
- Re: [PULL 0/5] 9p queue 2022-02-10, Peter Maydell, 2022/02/13
- Re: [PULL 0/5] 9p queue 2022-02-10, Christian Schoenebeck, 2022/02/14
- Re: [PULL 0/5] 9p queue 2022-02-10, Greg Kurz, 2022/02/14
- Re: [PULL 0/5] 9p queue 2022-02-10, Christian Schoenebeck, 2022/02/14
- Re: [PULL 0/5] 9p queue 2022-02-10, Vitaly Chikunov, 2022/02/14
- Re: [PULL 0/5] 9p queue 2022-02-10,
Christian Schoenebeck <=
- Re: [PULL 0/5] 9p queue 2022-02-10, Greg Kurz, 2022/02/15
- Re: [PULL 0/5] 9p queue 2022-02-10, Christian Schoenebeck, 2022/02/16
- Re: [PULL 0/5] 9p queue 2022-02-10, Greg Kurz, 2022/02/16
- Re: [PULL 0/5] 9p queue 2022-02-10, Philippe Mathieu-Daudé, 2022/02/16
- Re: [PULL 0/5] 9p queue 2022-02-10, Vitaly Chikunov, 2022/02/16
- Re: [PULL 0/5] 9p queue 2022-02-10, Christian Schoenebeck, 2022/02/16