linux-kernel - Re: [uml-devel] [PATCH 1/1] hostfs: fix UML crash

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]

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/