Hardy CVE-2010-3880, inet_diag: Make sure we actually run the same bytecode we audited (V2)

[Stefan Bader]

On 02/09/2011 03:15 PM, Tim Gardner wrote:
> On 02/09/2011 07:08 AM, Tim Gardner wrote:
>> On 02/07/2011 07:38 AM, Tim Gardner wrote:
>>> On 02/07/2011 02:15 AM, Andy Whitcroft wrote:
>>>> On Mon, Feb 07, 2011 at 09:48:11AM +0100, Stefan Bader wrote:
>>>>> On 02/02/2011 09:43 PM, Tim Gardner wrote:
>>>>>> On 02/02/2011 12:11 PM, Tim Gardner wrote:
>>>>>>> Postpone this one for a bit. The custom binary openvz flavour is
>>>>>>> failing.
>>>>>>>
>>>>>>> rtg
>>>>>>
>>>>>> Added the openvz cleanup patch.
>>>>>>
>>>>>> rtg
>>>>>>
>>>>> Hm, this one looks odd. The hunk in the openvz patch seems to add the
>>>>> "sll->sll_plttype = 0" and that does not seem to be touched by this
>>>>> cve.
>>>>
>>>> That sounds familiar. I think that that comes from the CVE below:
>>>>
>>>> commit 2c14b0a36cebda5a1fc2c69f2dd01eb73365aa65
>>>> Author: Andy Whitcroft<apw at canonical.com>
>>>> Date: Tue Feb 1 14:26:24 2011 +0000
>>>>
>>>> net: packet: fix information leak to userland, CVE-2010-3876
>>>>
>>>> I suspect that means this extra line should have come in earlier, not
>>>> sure if it is worth splitting out now, but in a perfect world I suspect
>>>> it should have been. My fault by the looks of it.
>>>>
>>>> -apw
>>>>
>>>
>>> Yeah, I think it's still OK. It just moves a hunk of a patch around, and
>>> the context lines go along for the ride. The custom binary patch
>>> mechanism is a real pain.
>>>
>>> rtg
>>
>> I fixed 'net: packet: fix information leak to userland, CVE-2010-3876'
>> for openvz and pushed +master-next, so you'll need to re-fetch.
>>
>> Now, back to the original Hardy CVE patch....
> 
> OK, how about this.
> 
> rtg
> 
Probably... mostly... err maybe without the line saying there is a fixup for
openvz in the commit message.

-Stefan