netdev - RE: [PATCH net-next] qed: Prevent stack corruption on MFW interaction

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]

Message-ID: <BL2PR07MB23060C5BFFA4738BE48D644F8DA70@BL2PR07MB2306.namprd07.prod.outlook.com>
Date:   Mon, 7 Nov 2016 12:25:42 +0000
From:   "Mintz, Yuval" <Yuval.Mintz@...ium.com>
To:     David Laight <David.Laight@...LAB.COM>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next] qed: Prevent stack corruption on MFW interaction

> > Driver uses a union for copying data to & from management firmware
> > when interacting with it.
> > Problem is that the function always copies sizeof(union) while commit
> > 2edbff8dcb5d ("qed: Learn resources from management firmware") is
> > casting a union elements which is of smaller size [24-byte instead of 88-bytes].
> >
> > Also, the union contains some inappropriate elements which increase
> > its size [should have been 32-bytes]. While this shouldn't corrupt
> > other PF messages to the MFW [as management firmware enforces
> > permissions so that each PF is allowed to write only to its own
> > mailbox] we fix this here as well.
> ...
> 
> Is it worth adding a compile-time assert on the size of the union?
> 
> 	David

I don't think so; The MFW team defines the elements and already enforces that.

It was simply a slip in my initial submission, where I omitted some
stuff that was already part of their HSI and wasn't required for that
submission, and missed the fact it was a union and not a struct
[hence uniting the removed fields to retain 'correct offsets' of fields].