Messages in this thread | | | Subject | Re: [PATCH v2] fs: select: fix information leak to userspace | From | Eric Dumazet <> | Date | Tue, 23 Nov 2010 01:20:48 +0100 |
| |
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
Strangely, if we remove ".l = 2," line, gcc emits code to clear al the fields
main: pushl %ebp movl %esp, %ebp andl $-16, %esp subl $32, %esp leal 24(%esp), %eax movl $0, 24(%esp) movl %eax, (%esp) movl $0, 28(%esp) movb $1, 24(%esp) call bar xorl %eax, %eax leave ret
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |