FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 09-21-2012, 03:55 AM
Ben Hutchings
 
Default Lucid CVE-2012-3412

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.

--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 09-21-2012, 04:54 PM
Tim Gardner
 
Default Lucid CVE-2012-3412

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@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 08:39 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org