[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101215094953.GG19804@ZenIV.linux.org.uk>
Date: Wed, 15 Dec 2010 09:49:53 +0000
From: Al Viro <viro@...IV.linux.org.uk>
To: P??draig Brady <P@...igBrady.com>
Cc: Am??rico Wang <xiyou.wangcong@...il.com>,
Andreas Dilger <adilger.kernel@...ger.ca>, wharms@....de,
Eric Dumazet <eric.dumazet@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Vasiliy Kulikov <segoon@...nwall.com>,
kernel-janitors@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, Jakub Jelinek <jakub@...hat.com>
Subject: Re: [PATCH v2] fs: select: fix information leak to userspace
On Wed, Nov 24, 2010 at 11:46:33AM +0000, P??draig Brady wrote:
> Looks like gcc is following the standard exactly.
>
> C90 - 6.5.7
> C99 - 6.7.8
>
> If there are fewer initializers in a brace-enclosed list than
> there are elements or members of an aggregate ... the remainder
> of the aggregate shall be initialized implicitly the same as
> objects that have static storage duration.
Incorrect. See 6.2.6.1 in C99; basically, padding bytes have unspecified
contents. Implementation is allowed to leave them in any state (including
not bothering to copy them when doing struct assignments, etc.). See
Appendix J (portability issues) as well.
The text you are quoting is about handling of missing initializers - it
essentially refers you back to the rules in 6.7.8p{9,10} (for arithmetical
types use zero, for pointers - null pointer, for arrays - apply recursively
to each array member, for structs - apply recursively for each named
member, for unions - apply recursively for the first named member). That's
it - nothing in the standard says how to initialize padding. Note that
these rules are _not_ guaranteed to be "fill everything with zero bits";
it often will be true, but it's implementation-dependent. Implementation
may decide to fill padding with all-zeroes; it's not required to do so.
The bottom line: if you rely on that, you are relying on non-portable
details of compiler behaviour. Moreover, the authors are not even
required to document what they are doing or to keep that behaviour
consistent.
--
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