[Lucid, Karmic, Hardy] Fix regression caused by CVE-2010-2943 fix
Brad Figg
brad.figg at canonical.com
Thu Mar 3 15:28:41 UTC 2011
On 03/01/2011 06:53 AM, Tim Gardner wrote:
> 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>
>
Works for me as well.
Acked-by: Brad Figg <brad.figg at canonical.com>
--
Brad Figg brad.figg at canonical.com http://www.canonical.com
More information about the kernel-team
mailing list