Re: CVE-2014-9900 fix is not upstream

> > 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

Re: CVE-2014-9900 fix is not upstream

> > 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

Re: CVE-2014-9900 fix is not upstream

> 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; >   

Re: CVE-2014-9900 fix is not upstream

> 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; >   

Re: CVE-2014-9900 fix is not upstream

> 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;

Re: CVE-2014-9900 fix is not upstream

> 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;

Re: CVE-2014-9900 fix is not upstream

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

Re: CVE-2014-9900 fix is not upstream

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

Re: CVE-2014-9900 fix is not upstream

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 >

Re: CVE-2014-9900 fix is not upstream

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 >

Re: CVE-2014-9900 fix is not upstream

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 

Re: CVE-2014-9900 fix is not upstream

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 

Re: CVE-2014-9900 fix is not upstream

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 { > >

Re: CVE-2014-9900 fix is not upstream

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 { > >

Re: CVE-2014-9900 fix is not upstream

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 > >

Re: CVE-2014-9900 fix is not upstream

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 > >

Re: CVE-2014-9900 fix is not upstream

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.

Re: CVE-2014-9900 fix is not upstream

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.

Re: CVE-2014-9900 fix is not upstream

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

Re: CVE-2014-9900 fix is not upstream

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

Re: CVE-2014-9900 fix is not upstream

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

Re: CVE-2014-9900 fix is not upstream

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 > >

Re: CVE-2014-9900 fix is not upstream

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

Re: CVE-2014-9900 fix is not upstream

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

CVE-2014-9900 fix is not upstream

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

CVE-2014-9900 fix is not upstream

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