[Lucid, Karmic, Hardy] Fix regression caused by CVE-2010-2943 fix

Tim Gardner tim.gardner at canonical.com
Tue Mar 1 14:53:19 UTC 2011


On 03/01/2011 02:00 AM, Stefan Bader wrote:
> On 02/23/2011 11:24 PM, Tim Gardner wrote:
>> On 02/23/2011 09:22 AM, Stefan Bader wrote:
>>> SRU Justification:
>>>
>>> Impact: The patches backported to fix CVE-2010-2943 caused a regressioni
>>>           for xfsdump.
>>>
>>> Fix: Backporting one more patch from upstream is fixing the issue.
>>>
>>> Testcase:
>>>    1. create an xfs filesystem with data (>~100MB). There is a compressed
>>>       archive provided in comment #14.
>>>    2. run "xfsdump -p10 -Ltest -Mdump -f outfile<mount>"
>>>        Note: Hardy and earlier seem to require the path to the device,
>>>        while later releases can handle the mount point.
>>> The xfsdump command aborts with SGI_FS_BULKSTAT errno = 22
>>>
>>> Note: the same changes were also backported to Dapper, but I have not
>>> yet been able to verify the regression there. Instead I got the feeling
>>> that xfs could be more broken in that release (I already get driver
>>> crashes when transferring bigger amounts of data to the xfs file system
>>> as a preparation). So I am tempted to leave the Dapper code as is. Even
>>> more as it again so different from the Hardy code that a backport is not
>>> simple.
>>>
>>> I will follow up with patches (hopefully) responding to this initial mail.
>>>
>>> -Stefan
>>>
>> I'm inclined to leave Dapper alone as well. Was it even stable enough for
>> production use in 2.6.15 ?
>>
>> The commit log mentions using iget "which should be fast enough for normal use
>> with the radix-tree based inode cache introduced a while ago". When was the
>> radix-tree stuff introduced? Will this patch introduce a ginormous performance
>> regression?
>>
> The radix tree based inode cache was added just with 2.6.24-rc1. So another
> reason to leave Dapper alone.
>
>> What about either reverting the original CVE patch, or finding a smaller fix for
>> it?
>>
> But I would stick with the backport we have plus this patch. Btw, the next
> 2.6.32.y release will have those 5 backported patches (4 we already have and
> this additional one).
>
> -Stefan
>> rtg
>
OK, I'm good with that.

Acked-by: Tim Gardner <tim.gardner at canonical.com>

-- 
Tim Gardner tim.gardner at canonical.com





More information about the kernel-team mailing list