Hardy ecryptfs can cause data loss

[Dustin Kirkland ]

This bug can cause data loss on an ecryptfs mounted filesystem.

The test case looks like this:

# mkdir /tmp/dir1 /tmp/dir2
# mount -t ecryptfs /tmp/dir1 /tmp/dir2
(any ecryptfs mount options are fine, choose defaults)
# cp /usr/share/common-licenses/GPL-3 /tmp/dir2
# umount /tmp/dir2
# mount -t ecryptfs /tmp/dir1 /tmp/dir2
(choose same options/passphrase as last mount)
# echo foo >> /tmp/dir2/GPL-3
# tail /tmp/dir2/GPL-3
# reset

You will see badly decrypted data printed to screen, whereas you should see the GPLv3 plus "foo" printed to screen. The data in this file is permanently hosed.

The fix for this bug was applied upstream against 2.6.26, and is already in the intrepid kernel.

The git commit diff can be seen here:
 * http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commitdiff;h=d3e49afbb66109613c3474f2273f5830ac2dcb09

I will gladly test a new Hardy kernel as soon as it becomes available.

:-Dustin

[Tim Gardner (timg-tpi)]

SRU Justification:

Impact: ecryptfs can cause loss of data in certain scenarios

Patch Description: cherry-picked 2.6.25.y d3e49afbb66109613c3474f2273f5830ac2dcb09. The page decrypt calls in ecryptfs_write() are both pointless and buggy. Pointless because ecryptfs_get_locked_page() has already brought the page up to date, and buggy because prior mmap writes will just be blown away by the decrypt call. This patch also removes the declaration of a now-nonexistent function ecryptfs_write_zeros().

Patch: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=b85452a23dcdeddc4a4ae1816501e80a16bb14a8

Test Case: see Bug decscription

[Tim Gardner (timg-tpi)]

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=b85452a23dcdeddc4a4ae1816501e80a16bb14a8

[Tim Gardner (timg-tpi)]

Updated URL: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=6f137e40d6d2456fd23b0f2f342eabd44c50656a

[Serge Hallyn (serge-hallyn)]

This happens for me too with the Hardy kernel

[Tim Gardner (timg-tpi)]

Please try the test kernel at http://ppa.launchpad.net/timg-tpi/ubuntu when it is done building, linux-2.6.24-20.35ubuntu2 or higher. You'll likely also need the other -20 ABI packages (LUM,LBM,LRM) .

[Dustin Kirkland  (kirkland)]

Tim-

I just tested the kernels in your PPA (linux - 2.6.24-20.35ubuntu5),
and the problem is still present.

FWIW, I did test the Intrepid 2.6.26 kernels and these do not suffer
from the same problem.

:-Dustin

[Adam Wood (adamwood)]

I have tried to reproduce this bug using the 2.6.24-19-generic kernel from the Main repo (version 2.6.24-19.36).

I could NOT reproduce the bug. Have I missed a step or a precondition that causes the bug?

If not, do we need more people to confirm this before we can mark the report Fix Released?

[Serge Hallyn (serge-hallyn)]

I'm running 2.6.24-21-generic and still have the bug.

Could this be because a fix backported to 2.6.24-19-generic would not
have been applied to kernels in Tim's test kernel repo (deb
http://ppa.launchpad.net/timg-tpi/ubuntu hardy main
)?

thanks,
-serge

On Tue, Aug 12, 2008 at 2:41 AM, Adam Wood <email address hidden> wrote:
> I have tried to reproduce this bug using the 2.6.24-19-generic kernel
> from the Main repo (version 2.6.24-19.36).
>
> I could NOT reproduce the bug. Have I missed a step or a precondition
> that causes the bug?
>
> If not, do we need more people to confirm this before we can mark the
> report Fix Released?
>
> --
> Hardy ecryptfs can cause data loss
> https://bugs.launchpad.net/bugs/242448
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Linux Kernel: Unknown
> Status in "linux" source package in Ubuntu: Confirmed
> Status in linux in Ubuntu Hardy: Confirmed
>
> Bug description:
> This bug can cause data loss on an ecryptfs mounted filesystem.
>
> The test case looks like this:
>
> # mkdir /tmp/dir1 /tmp/dir2
> # mount -t ecryptfs /tmp/dir1 /tmp/dir2
> (any ecryptfs mount options are fine, choose defaults)
> # cp /usr/share/common-licenses/GPL-3 /tmp/dir2
> # umount /tmp/dir2
> # mount -t ecryptfs /tmp/dir1 /tmp/dir2
> (choose same options/passphrase as last mount)
> # echo foo >> /tmp/dir2/GPL-3
> # tail /tmp/dir2/GPL-3
> # reset
>
> You will see badly decrypted data printed to screen, whereas you should see the GPLv3 plus "foo" printed to screen. The data in this file is permanently hosed.
>
> The fix for this bug was applied upstream against 2.6.26, and is already in the intrepid kernel.
>
> The git commit diff can be seen here:
> * http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commitdiff;h=d3e49afbb66109613c3474f2273f5830ac2dcb09
>
> I will gladly test a new Hardy kernel as soon as it becomes available.
>
> :-Dustin
>

[Adam Wood (adamwood)]

I've just gone back to test it again and have discovered there may be a time element involved.

After my earlier test I accidentally forgot to unmount /tmp/dir2
I've just unmounted and re-mounted it and there was file corruption.

I've just repeated the test using 2 new directories, /tmp/dir3 and /tmp/dir4. Unmounting and remounting immediately shows that they are decrypting fine.

I'll keep an eye on the new directories and see what happens over time.

[Serge Hallyn (serge-hallyn)]

On Tue, Aug 12, 2008 at 8:42 AM, Adam Wood <email address hidden> wrote:
> I've just gone back to test it again and have discovered there may be a
> time element involved.
>
> After my earlier test I accidentally forgot to unmount /tmp/dir2
> I've just unmounted and re-mounted it and there was file corruption.
>
> I've just repeated the test using 2 new directories, /tmp/dir3 and
> /tmp/dir4. Unmounting and remounting immediately shows that they are
> decrypting fine.

Just to be clear, since you said 'decrypting fine': if you read the
files, they will decrypt fine. It is only if you append to the file
immediately after mount, and the file is more than one block in size
and not an exact multiple of blocksize (iirc).

If you did mean using append, then that is interesting, bc I've never
had it fail to corrupt a file :) (or is that :( ).

-serge

[Adam Wood (adamwood)]

Serge: It does appear to only happen after an append and when the file is "large", maybe the blocksize is the magic number where it starts to go wrong but I couldn't confirm that. It also only presents when you append before you read from the file. I missed that bit of implied information in the bug report.

I've also just discovered that the patch was applied to the git repository before the 2.6.24-19 tag was taken but that patch was only included in the -20 series, I think. I'm going to try building one of those kernels now and see if it fixes the problem. At least I know how to reliably make a mess of things now :).

[Tim Gardner (timg-tpi)]

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=4bddf325870b6076e2395914a51aff665d39c9d0

Even though the discussion thread says it only happens when compiled for SLUB debug, perhaps this patch will have an effect.

[Dustin Kirkland  (kirkland)]

On Wed, Aug 13, 2008 at 8:40 AM, Tim Gardner <email address hidden> wrote:
> Even though the discussion thread says it only happens when compiled for
> SLUB debug, perhaps this patch will have an effect.

Is there a kernel package that I can test?

:-Dustin

[Adam Wood (adamwood)]

Dustin - I'm building one at the moment, if it works you're welcome to a copy. It's -generic and i386. If we get a couple of reports that it works then maybe one of the devs will be kind enough to create a PPA.

If it doesn't work I think I'll try a git bisect of the intrepid tree and help the devs track this one down. Kernel compiles are slow though so I'm hoping it wont be needed. :)

[Dustin Kirkland  (kirkland)]

On Wed, Aug 13, 2008 at 10:15 AM, Adam Wood <email address hidden> wrote:
> Dustin - I'm building one at the moment, if it works you're welcome to a
> copy.

Excellent, Adam. Thanks.

> If it doesn't work I think I'll try a git bisect of the intrepid tree
> and help the devs track this one down.

Sounds good, I'd love to get this fixed. It's somewhere between 2.6.24
and 2.6.26.

:-Dustin

[Adam Wood (adamwood)]

I'm afraid the patch didn't work.

On a brighter note my laptop is now working on tracking down this bug and I will post again later when I have more info and time.

[Adam Wood (adamwood)]

The problem is in fs/ecryptfs/mmap.c

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=e4465fdaeb3f7b5ef47f389d3eac76db79ff20d8
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=eebd2aa355692afaf9906f62118620f1a1c19dbb

The first patch is the important one but because of some function name cleaning in the second patch it doesn't apply cleanly. The second patch listed has much wider ranging changes and in my opinion shouldn't be applied. Thankfully the changes to the ecryptfs files are tiny so I did them by hand and attached a patch that combines all needed changes to fix this bug.

The attached patch is probably not the right format. Sorry about that :-) but i thought it would be better than nothing.

I think the patch can be applied without the need to bump the ABI.

[Tim Gardner (timg-tpi)]

SRU Justification

Impact: Encrypted files can get corrupted.

Patch Description: eCryptfs: make ecryptfs_prepare_write decrypt the page. When the page is not up to date, cryptfs_prepare_write() should be acting much like ecryptfs_readpage(). This includes the painfully obvious step of actually decrypting the page contents read from the lower encrypted file.

Patch: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=d657d315c2b14e093a2eff90f7e3dd722e745f40

Test Case: See bug description.

[Tim Gardner (timg-tpi)]

I was able to verify that the test case no longer shows the bug.

[Serge Hallyn (serge-hallyn)]

Please let me know when this is in your test kernel repo
(deb http://ppa.launchpad.net/timg-tpi/ubuntu hardy main) and I will give it a
shot.

thanks,
-serge

On Mon, Aug 18, 2008 at 11:01 AM, Tim Gardner <email address hidden> wrote:
> I was able to verify that the test case no longer shows the bug.
>
> --
> Hardy ecryptfs can cause data loss
> https://bugs.launchpad.net/bugs/242448
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Linux Kernel: Unknown
> Status in "linux" source package in Ubuntu: Confirmed
> Status in linux in Ubuntu Hardy: Fix Committed
>
> Bug description:
> This bug can cause data loss on an ecryptfs mounted filesystem.
>
> The test case looks like this:
>
> # mkdir /tmp/dir1 /tmp/dir2
> # mount -t ecryptfs /tmp/dir1 /tmp/dir2
> (any ecryptfs mount options are fine, choose defaults)
> # cp /usr/share/common-licenses/GPL-3 /tmp/dir2
> # umount /tmp/dir2
> # mount -t ecryptfs /tmp/dir1 /tmp/dir2
> (choose same options/passphrase as last mount)
> # echo foo >> /tmp/dir2/GPL-3
> # tail /tmp/dir2/GPL-3
> # reset
>
> You will see badly decrypted data printed to screen, whereas you should see the GPLv3 plus "foo" printed to screen. The data in this file is permanently hosed.
>
> The fix for this bug was applied upstream against 2.6.26, and is already in the intrepid kernel.
>
> The git commit diff can be seen here:
> * http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commitdiff;h=d3e49afbb66109613c3474f2273f5830ac2dcb09
>
> I will gladly test a new Hardy kernel as soon as it becomes available.
>
> :-Dustin
>

[Dustin Kirkland  (kirkland)]

On Mon, Aug 18, 2008 at 5:01 PM, Tim Gardner <email address hidden> wrote:
> I was able to verify that the test case no longer shows the bug.

Thanks Tim and Adam!

:-Dustin

[Dustin Kirkland  (kirkland)]

On Mon, Aug 18, 2008 at 5:33 PM, Serge Hallyn <email address hidden> wrote:
> Please let me know when this is in your test kernel repo
> (deb http://ppa.launchpad.net/timg-tpi/ubuntu hardy main) and I will give it a
> shot.

Serge-

You should be able to test Tim's test kernel at:
 * https://launchpad.net/~timg-tpi/+archive

linux - 2.6.24-22.41ubuntu1

:-Dustin

[Serge Hallyn (serge-hallyn)]

Well uname says I'm running 2.6.24-22-generic, but the ecryptfs bug
isn't showing up right now.

On Mon, Aug 18, 2008 at 12:15 PM, Dustin Kirkland
<email address hidden> wrote:
> On Mon, Aug 18, 2008 at 5:33 PM, Serge Hallyn <email address hidden> wrote:
>> Please let me know when this is in your test kernel repo
>> (deb http://ppa.launchpad.net/timg-tpi/ubuntu hardy main) and I will give it a
>> shot.
>
> Serge-
>
> You should be able to test Tim's test kernel at:
> * https://launchpad.net/~timg-tpi/+archive
>
> linux - 2.6.24-22.41ubuntu1
>
> :-Dustin
>
> --
> Hardy ecryptfs can cause data loss
> https://bugs.launchpad.net/bugs/242448
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Linux Kernel: Unknown
> Status in "linux" source package in Ubuntu: Confirmed
> Status in linux in Ubuntu Hardy: Fix Committed
>
> Bug description:
> This bug can cause data loss on an ecryptfs mounted filesystem.
>
> The test case looks like this:
>
> # mkdir /tmp/dir1 /tmp/dir2
> # mount -t ecryptfs /tmp/dir1 /tmp/dir2
> (any ecryptfs mount options are fine, choose defaults)
> # cp /usr/share/common-licenses/GPL-3 /tmp/dir2
> # umount /tmp/dir2
> # mount -t ecryptfs /tmp/dir1 /tmp/dir2
> (choose same options/passphrase as last mount)
> # echo foo >> /tmp/dir2/GPL-3
> # tail /tmp/dir2/GPL-3
> # reset
>
> You will see badly decrypted data printed to screen, whereas you should see the GPLv3 plus "foo" printed to screen. The data in this file is permanently hosed.
>
> The fix for this bug was applied upstream against 2.6.26, and is already in the intrepid kernel.
>
> The git commit diff can be seen here:
> * http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commitdiff;h=d3e49afbb66109613c3474f2273f5830ac2dcb09
>
> I will gladly test a new Hardy kernel as soon as it becomes available.
>
> :-Dustin
>

[Tim Gardner (timg-tpi)]

Serge - that is the right kernel version from my PPA. Looks like the corruption bug is fixed.

[Serge Hallyn (serge-hallyn)]

Excellent, thanks!

I'm still a little sqeemish, but will try using it for my main
datastore again next week.

-serge

On Fri, Aug 22, 2008 at 9:53 AM, Tim Gardner <email address hidden> wrote:
> Serge - that is the right kernel version from my PPA. Looks like the
> corruption bug is fixed.
>
> --
> Hardy ecryptfs can cause data loss
> https://bugs.launchpad.net/bugs/242448
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Linux Kernel: Unknown
> Status in "linux" source package in Ubuntu: Confirmed
> Status in linux in Ubuntu Hardy: Fix Committed
>
> Bug description:
> This bug can cause data loss on an ecryptfs mounted filesystem.
>
> The test case looks like this:
>
> # mkdir /tmp/dir1 /tmp/dir2
> # mount -t ecryptfs /tmp/dir1 /tmp/dir2
> (any ecryptfs mount options are fine, choose defaults)
> # cp /usr/share/common-licenses/GPL-3 /tmp/dir2
> # umount /tmp/dir2
> # mount -t ecryptfs /tmp/dir1 /tmp/dir2
> (choose same options/passphrase as last mount)
> # echo foo >> /tmp/dir2/GPL-3
> # tail /tmp/dir2/GPL-3
> # reset
>
> You will see badly decrypted data printed to screen, whereas you should see the GPLv3 plus "foo" printed to screen. The data in this file is permanently hosed.
>
> The fix for this bug was applied upstream against 2.6.26, and is already in the intrepid kernel.
>
> The git commit diff can be seen here:
> * http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commitdiff;h=d3e49afbb66109613c3474f2273f5830ac2dcb09
>
> I will gladly test a new Hardy kernel as soon as it becomes available.
>
> :-Dustin
>

[Steve Langasek (vorlon)]

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Serge Hallyn (serge-hallyn)]

The bug appears to be fixed for me.

Thanks!

-serge

On Mon, Aug 25, 2008 at 11:54 AM, Steve Langasek
<email address hidden> wrote:
> Accepted into -proposed, please test and give feedback here. Please see
> https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
> enable and use -proposed. Thank you in advance!
>
> --
> Hardy ecryptfs can cause data loss
> https://bugs.launchpad.net/bugs/242448
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Linux Kernel: Unknown
> Status in "linux" source package in Ubuntu: Confirmed
> Status in linux in Ubuntu Hardy: Fix Committed
>
> Bug description:
> This bug can cause data loss on an ecryptfs mounted filesystem.
>
> The test case looks like this:
>
> # mkdir /tmp/dir1 /tmp/dir2
> # mount -t ecryptfs /tmp/dir1 /tmp/dir2
> (any ecryptfs mount options are fine, choose defaults)
> # cp /usr/share/common-licenses/GPL-3 /tmp/dir2
> # umount /tmp/dir2
> # mount -t ecryptfs /tmp/dir1 /tmp/dir2
> (choose same options/passphrase as last mount)
> # echo foo >> /tmp/dir2/GPL-3
> # tail /tmp/dir2/GPL-3
> # reset
>
> You will see badly decrypted data printed to screen, whereas you should see the GPLv3 plus "foo" printed to screen. The data in this file is permanently hosed.
>
> The fix for this bug was applied upstream against 2.6.26, and is already in the intrepid kernel.
>
> The git commit diff can be seen here:
> * http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commitdiff;h=d3e49afbb66109613c3474f2273f5830ac2dcb09
>
> I will gladly test a new Hardy kernel as soon as it becomes available.
>
> :-Dustin
>

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Serge Hallyn (serge-hallyn)]

I am not running intrepid, I'm running hardy. Attempts to create an intrepid
kvm image failed (funky mouse behavior).

I wonder whether this comment was sent to the wrong bug? This bug was
pertaining to the 2.6.24 kernel on hardy only, since the bug had been fixed
separately upstream in 2.6.26.

thanks,
-serge

On Thu, Aug 28, 2008 at 1:25 PM, Leann Ogasawara <email address hidden> wrote:
> The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the
> upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would
> appreciate it if you could please test this newer 2.6.27 Ubuntu kernel.
> There are one of two ways you should be able to test:
>
> 1) If you are comfortable installing packages on your own, the linux-
> image-2.6.27-* package is currently available for you to install and
> test.
>
> --or--
>
> 2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer
> 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4.
> Please watch http://www.ubuntu.com/testing for Alpha5 to be announced.
> You should then be able to test via a LiveCD.
>
> Please let us know immediately if this newer 2.6.27 kernel resolves the
> bug reported here or if the issue remains. More importantly, please
> open a new bug report for each new bug/regression introduced by the
> 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please
> specifically note if the issue does or does not appear in the 2.6.26
> kernel. Thanks again, we really appreicate your help and feedback.
>
> ** Tags added: cft-2.6.27
>
> --
> Hardy ecryptfs can cause data loss
> https://bugs.launchpad.net/bugs/242448
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Linux Kernel: Unknown
> Status in "linux" source package in Ubuntu: Confirmed
> Status in linux in Ubuntu Hardy: Fix Committed
>
> Bug description:
> This bug can cause data loss on an ecryptfs mounted filesystem.
>
> The test case looks like this:
>
> # mkdir /tmp/dir1 /tmp/dir2
> # mount -t ecryptfs /tmp/dir1 /tmp/dir2
> (any ecryptfs mount options are fine, choose defaults)
> # cp /usr/share/common-licenses/GPL-3 /tmp/dir2
> # umount /tmp/dir2
> # mount -t ecryptfs /tmp/dir1 /tmp/dir2
> (choose same options/passphrase as last mount)
> # echo foo >> /tmp/dir2/GPL-3
> # tail /tmp/dir2/GPL-3
> # reset
>
> You will see badly decrypted data printed to screen, whereas you should see the GPLv3 plus "foo" printed to screen. The data in this file is permanently hosed.
>
> The fix for this bug was applied upstream against 2.6.26, and is already in the intrepid kernel.
>
> The git commit diff can be seen here:
> * http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commitdiff;h=d3e49afbb66109613c3474f2273f5830ac2dcb09
>
> I will gladly test a new Hardy kernel as soon as it becomes available.
>
> :-Dustin
>

[Steve Beattie (sbeattie)]

I have reproduced the original problem using the 2.6.24-19.41 generic kernel image from the hardy-updates repository, and can confirm that the 2.6.24-21.42 generic kernel image from hardy-proposed does eliminate the file corrupting behavior, at least when using ecryptfs with the passphrase option.

I also exercised the ecryptfs filesystem by running LTP's filesystem stress tests manually on the encryptfs filesystem and saw no regressions, for what it's worth. (Admittedly, the LTP tests didn't catch this bug.)

Serge, the reason Leann's comment was added to this bug is because the development (intrepid) task's state in launchpad is currently set to "Confirmed" or in other words is still considered an open bug against the development kernel. If you or anyone else can confirm that it was indeed fixed upstream before 2.6.26, then please mark that task as invalid. Thanks!

[Serge Hallyn (serge-hallyn)]

Steve, I'm sorry, I don't know how to find the intrepid/development
version of this bug to mark it as invalid. (a search for "ecryptfs"
didn't find it)

LIke I say I haven't gotten intrepid to install, but Dustin noted in
the very first comment on this bug that intrepid has the 2.6.26 fix
for this bug. So while I don't know how to do it, consider this
confirmation that this bug (242448) is not valid with respect to
intrepid.

[Steve Langasek (vorlon)]

marking as fix released for intrepid.

[Dustin Kirkland  (kirkland)]

On Fri, Aug 29, 2008 at 3:06 AM, Steve Langasek
<email address hidden> wrote:
> marking as fix released for intrepid.

As it should be. This bug was definitely fixed upstream in 2.6.25,
and should not exist in any kernel beyond. Tim backported to 2.6.24
for Hardy.

:-Dustin

[Martin Pitt (pitti)]

linux 2.6.24-21 copied to hardy-updates.