lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTim1sUog=5cDRHRxRhg6P0QKCe-SkNMTAgmNa3Qt@mail.gmail.com>
Date:	Mon, 18 Oct 2010 21:43:44 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Richard Weinberger <richard@....at>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, toralf.foerster@....de,
	jdike@...toit.com, linux-kernel@...r.kernel.org,
	user-mode-linux-devel@...ts.sourceforge.net,
	viro@...iv.linux.org.uk
Subject: Re: [uml-devel] [PATCH 1/1] hostfs: fix UML crash

On Mon, Oct 18, 2010 at 21:31, Richard Weinberger <richard@....at> wrote:
> Am Montag 18 Oktober 2010, 21:22:31 schrieb Geert Uytterhoeven:
>> On Mon, Oct 18, 2010 at 20:40, Andrew Morton <akpm@...ux-foundation.org>
> wrote:
>> > On Mon, 18 Oct 2010 18:36:54 +0200 Richard Weinberger <richard@....at>
> wrote:
>> >> 365b1818 resized f_spare within struct statfs.
>> >> hostfs accesses f_spare directly and needs an update.
>> >>
>> >> Signed-off-by: Richard Weinberger <richard@....at>
>> >> Reported-by: Toralf F__rster <toralf.foerster@....de>
>> >> Tested-by: Toralf F__rster <toralf.foerster@....de>
>> >> ---
>> >>  fs/hostfs/hostfs_user.c |    2 +-
>> >>  1 files changed, 1 insertions(+), 1 deletions(-)
>> >>
>> >> diff --git a/fs/hostfs/hostfs_user.c b/fs/hostfs/hostfs_user.c
>> >> index 6777aa0..ce2f168 100644
>> >> --- a/fs/hostfs/hostfs_user.c
>> >> +++ b/fs/hostfs/hostfs_user.c
>> >> @@ -388,6 +388,6 @@ int do_statfs(char *root, long *bsize_out, long long
>> >> *blocks_out, spare_out[1] = buf.f_spare[1];
>> >>       spare_out[2] = buf.f_spare[2];
>> >>       spare_out[3] = buf.f_spare[3];
>> >> -     spare_out[4] = buf.f_spare[4];
>> >> +
>> >>       return 0;
>> >>  }
>> >
>> > Thanks.
>> >
>> > Is there any reason for hostfs to be playing with the f_spare field at
>> > all?
>>
>> It just copies it from struct statfs64 on the host to struct kstatfs
>> on the guest.
>> Probably a memcpy() is more future-safe, if it's combined with a
>> BUILD_BUG_ON(sizeof(statfs64.f_spare) != sizeof(kstatfs.f_spare)).
>>
>> Still, currently it doesn't copy the recently added f_flags field.
>> To protect against future changes like that, an explicit
>> BUILD_BUG_ON(sizeof(kstatfs.f_spare) != 4*sizeof(long)) may be even
>> better...
>
> Anyway, why do we need to copy f_spare from the host to the guest?
> I'm quite sure it can be omitted.

I guess it wants to preserve fields that are added in the future,
which may be useful
if the host is more recent than the guest.

Still, even if you don't want to preserve them, you probably want to clear them,
so memset() is better than a fixed loop through 4 elements.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ