Lucid CVE-2012-3412

Tim Gardner tim.gardner at canonical.com
Fri Sep 21 16:54:12 UTC 2012


On 09/20/2012 09:55 PM, Ben Hutchings wrote:
> On Fri, 2012-08-24 at 13:38 -0600, Tim Gardner wrote:
>> On 08/24/2012 09:11 AM, Tim Gardner wrote:
>>> On 08/24/2012 09:05 AM, Herton Ronaldo Krzesinski wrote:
>>>> On Fri, Aug 24, 2012 at 07:58:34AM -0600, Tim Gardner wrote:
>>>>>  static inline int netif_needs_gso(struct net_device *dev, struct sk_buff *skb)
>>>>>  {
>>>>> +	if (skb_is_gso(skb) &&
>>>>> +		skb_shinfo(skb)->gso_segs > skb->dev->gso_max_segs)
>>>>> +		return 0;
>>>>
>>>> Shouldn't be return 1 here? If the condition is true, we would clear the
>>>> flags from features. If flags are cleared, when calling skb_gso_ok:
>>>>
>>>> net_gso_ok would always return 0
>>>> skb_gso_ok would always return 0
>>>> netif_needs_gso returns 1 because it does !skb_gso_ok
>>>>
>>>> Unless I'm missing something here. Anyway, hard to read these functions...
>>>> I think just copying/clearing the flags and passing through skb_gso_ok
>>>> would be better.
>>>>
>>>
>>> I guess I'm confused about when the flag is set. I was assuming if GSO
>>> was set, then the driver handled 'generic segmentation offload'. Aren't
>>> we checking for error conditions, e.g., if there are more segments then
>>> the driver can handle, then _don't_ do GSO ?
>>>
>>> rtg
>>>
>>
>> After some online discussion with Herton I think we've agreed to bag
>> this mess. This is not a broad vulnerability, and the patch is proving
>> to be more effort then its worth.
> 
> If you'd just asked, I could have given you the driver-only fix which
> was applied to the out-of-tree version of sfc.  This would avoid the
> need to backport any net core or TCP changes, which is comparatively
> risky for older kernel versions.  (David Miller has covered 3.x now.)
> 
> The driver-only fix is to truncate TSO skbs to the maximum number of
> segments (100).  This results in terrible throughput for any TCP stream
> that exceeds that, but the limit is chosen to be high enough that
> legitimate traffic should never hit it.  This is also the fix that RHEL
> will use, due to its ABI stability requirements.
> 
> In the driver version in Debian squeeze and Ubuntu lucid (roughly
> equivalent to Linux 2.6.33), the DMA ring sizes were constant, so the
> fix can be simplified further:
> 
> http://anonscm.debian.org/viewvc/kernel/dists/squeeze-security/linux-2.6/debian/patches/bugfix/all/sfc-Fix-maximum-number-of-TSO-segments-and-minimum-T.patch?revision=19347&view=markup
> 
> Ben.
> 

Thanks for the note. We are adopting your patch and dropping the rest.

rtg
-- 
Tim Gardner tim.gardner at canonical.com




More information about the kernel-team mailing list