> > I see someone did request it 2 years ago:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63479
>
> I don't think this is sufficient. Basically if you write one field in a
> struct after a memset again, the compiler is allowed by the standard to
> write padding bytes again, causing them to
> struct ethtool_wolinfo {
> __u32 cmd;
> __u32 supported;
> __u32 wolopts;
> __u8sopass[SOPASS_MAX]; // 6, actually
> };
>
> we could do
>
> struct ethtool_wolinfo {
> __u32 cmd;
> __u32 supported;
> __u32 wolopts;
>
> If we want to go down this route, probably the only option is to add
> __attribute__((pack)) those structs to just have no padding at all,
> thus breaking uapi.
>
We could also spell out the padding bytes as reserved, i.e. instead of
struct ethtool_wolinfo {
__u32 cmd;
__u32
On 24.08.2016 16:03, Lennart Sorensen wrote:
> On Tue, Aug 23, 2016 at 10:25:45PM +0100, Al Viro wrote:
>> Sadly, sizeof is what we use when copying that sucker to userland. So these
>> padding bits in the end would've leaked, true enough, and the case is
>> somewhat
>> weaker. And any normal ar
On Tue, Aug 23, 2016 at 10:25:45PM +0100, Al Viro wrote:
> Sadly, sizeof is what we use when copying that sucker to userland. So these
> padding bits in the end would've leaked, true enough, and the case is somewhat
> weaker. And any normal architecture will have those, but then any such
> archit
On Tue, Aug 23, 2016 at 04:49:33PM -0400, Lennart Sorensen wrote:
> That would be padding after the structure elements.
>
> I think what was meant is that it won't add padding in the middle of the
> structure due to alignment, ie it isn't doing:
>
> struct ethtool_wolinfo {
> __u32
On Tue, Aug 23, 2016 at 01:34:05PM -0700, Joe Perches wrote:
> On Tue, 2016-08-23 at 21:09 +0100, Al Viro wrote:
> > On Tue, Aug 23, 2016 at 11:24:06AM -0700, David Miller wrote:
> > ... and then we can file a bug report against the sodding compiler. Note
> > that
> > struct ethtool_wolinfo {
> >
On Tue, 2016-08-23 at 21:09 +0100, Al Viro wrote:
> On Tue, Aug 23, 2016 at 11:24:06AM -0700, David Miller wrote:
> > > On some versions and architectures. Can you guarantee that you will
> > > notice when an exception appears?
> > Again, show me the assembler output exhibiting the lack of
> > ini
On Tue, Aug 23, 2016 at 11:24:06AM -0700, David Miller wrote:
> > On some versions and architectures. Can you guarantee that you will
> > notice when an exception appears?
>
> Again, show me the assembler output exhibiting the lack of
> initialization, for this specific structure and situation.
From: Ben Hutchings
Date: Tue, 23 Aug 2016 18:35:27 +0100
> On Tue, 2016-08-23 at 09:40 -0700, David Miller wrote:
>> From: Luis Henriques
>> Date: Tue, 23 Aug 2016 14:41:07 +0100
>>
>> > Digging through some old CVEs I came across this one that doesn't
>> seem be
>> > in mainline. Was there a
On Tue, 2016-08-23 at 09:40 -0700, David Miller wrote:
> From: Luis Henriques
> Date: Tue, 23 Aug 2016 14:41:07 +0100
>
> > Digging through some old CVEs I came across this one that doesn't
> seem be
> > in mainline. Was there a good reason for not being sent upstream?
> Maybe it was
> > reject
From: Luis Henriques
Date: Tue, 23 Aug 2016 14:41:07 +0100
> Digging through some old CVEs I came across this one that doesn't seem be
> in mainline. Was there a good reason for not being sent upstream? Maybe it
> was
> rejected for some reason and I failed to find the discussion.
Because the
Hi!
Digging through some old CVEs I came across this one that doesn't seem be
in mainline. Was there a good reason for not being sent upstream? Maybe it was
rejected for some reason and I failed to find the discussion.
References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9900
h
13 matches
Mail list logo
