APPLIED: [CVE-2011-1576] core: Fix memory leak/corruption on VLAN GRO_DROP

[Stefan Bader]

On 12.12.2011 15:07, Tim Gardner wrote:
> On 12/07/2011 09:46 AM, Stefan Bader wrote:
>> On 19.09.2011 16:12, Tim Gardner wrote:
>>> On 09/19/2011 08:00 AM, Stefan Bader wrote:
>>>> introduced by (2.6.30):
>>>>      5d0d9be8ef456afc6c3fb5f8aad06ef19b704b05
>>>>      gro: Move common completion code into helpers
>>>>
>>>> fixed upstream by (2.6.37):
>>>>      3701e51382a026cba10c60b03efabe534fba4ca4
>>>>      vlan: Centralize handling of hardware acceleration.
>>>>
>>>> The upstream fix avoids the problem by re-arranging some helper functions.
>>>> This minimal fix was picked from the RedHat source package. It matches the
>>>> way that the vlan code handled the cases before the merge.
>>>>
>>>> Natty and Oneiric have the upstream fix. Hardy does not even handle GRO.
>>>> So only fixes for Lucid and Maverick are required. The two versions for
>>>> lucid/fsl-imx51 and the rest only differ by a bit of sourrounding code.
>>>>
>>>
>>>
>> Benjamin Poirier from SUSE had been looking at this one, too. And we had brief
>> discussion. While the simple fix we took from RedHat will likely work, it is not
>> really restoring a previous behavior as I had been thinking. This alternate
>> approach is now queued in 2.6.32.y and when that hits, we could revert the other
>> patch. And we likely would then want to do the same for all the combinations of
>> other places where the same patch has been added.
>>
>> -Stefan
> 
> So, you're kind of confusing me about which patches get reverted in what
> release. Perhaps you could send pull requests for each release that demonstrate
> exactly how you'd like each release to look.
> 
> rtg

Hm, probably will make sense more to Maverick as the upstream stable update for
Lucid, which I just sent out will contain the new patch (just without stating
the cve in our way of tagging). We could just revert the old patch there.

Will prepare something for Maverick.

-Stefan