Re: [PATCH v2] fs: select: fix information leak to userspace

[Andrew Morton <akpm@linux-foundation.org>]

On Tue, 23 Nov 2010 01:20:48 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> Le lundi 22 novembre 2010 __ 15:50 -0800, Andrew Morton a __crit :
> 
> > Well.  We certainly assume in many places that
> > 
> > 	struct foo {
> > 		int a;
> > 		int b;
> > 	} f = {
> > 		.a = 1,
> > 	};
> > 
> > will initialise b to zero.  But I doubt if much code at all assumes
> > that this initialisation patterm will reliably zero out *holes* in the
> > struct.
> > 
> 
> We did such assertions in the past, we were wrong.
> 
> Check commit 1c40be12f7d8ca1d387510d39787b12e512a7ce8 for an example
> (net sched: fix some kernel memory leaks)
> 
> I guess we must make a full audit of all C99 initializers or structures
> copied to userspace, giving a name to hidden holes, to force gcc to init
> them to 0.
> 
> # cat try.c
> struct s {
> 	char c;
> 	long l;
> 	};
> 
> void bar(void *v)
> {
> 	unsigned long *p = v;
> 
> 	printf("%lx %lx\n", p[0], p[1]);
> }
> 
> int main()
> {
> 	struct s s1 = {
> 		.c = 1,
> 		.l = 2,
> 	};
> 
> 	bar(&s1);
> 	return 0;
> }
> 
> # gcc -O2 -o try try.c
> # ./try
> 8049401 2

OK, thanks.  That rather settles it then.  memset() it is.

> Strangely, if we remove ".l = 2," line, gcc emits code to clear al the
> fields

Maybe a glitch, maybe a small optimisation?  That's the sort of thing
which will change over gcc versions too..