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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ