Regression between 2.6.32-27 and 2.6.32-26 xfsdump SGI_FS_BULKSTAT errno = 22

Problem still exists under 2.6.32-28 on x86_64:

+ sudo xfsdump -p 10 -L NITWO Ubuntu Home Filesystem -M Written 2011-01-26 -f /media/tvms/Backups/nitwo-ubuntu/home/2011-01-26.xfsdump /home
xfsdump: using file dump (drive_simple) strategy
xfsdump: version 3.0.4 (dump format 3.0) - Running single-threaded
xfsdump: level 0 dump of nitwo-ubuntu:/home
xfsdump: dump date: Wed Jan 26 17:37:29 2011
xfsdump: session id: a4df6f81-16fd-40e5-b21e-199238c008bc
xfsdump: session label: "NITWO Ubuntu Home Filesystem"
xfsdump: ino map phase 1: constructing initial dump list
xfsdump: syssgi( SGI_FS_BULKSTAT ) on fsroot failed: Invalid argument
xfsdump: Dump Status: ERROR

nitwo-ubuntu:~$ uname -a
Linux nitwo-ubuntu 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 23:42:43 UTC 2011 x86_64 GNU/Linux

I cross reported this bug to the SGI Linux XFS support group. Bill Kendall of SGI replied as follows:

=======================
On 02/02/2011 07:30 AM, Michael Lueck wrote:
> Greetings,
>
> Somehow a reported IRIX bug with XFS got into Ubuntu 10.04 (Lucid) starting with kernel 2.6.32-27.
>
> I am cross posting to this list in order to receive details as to what bug got in Ubuntu which has
> been solved in IRIX, hoping with more details Ubuntu might make the same fix.

Aside from the fact that the errno is the same, there's nothing to suggest
that the Ubuntu problem is the the same bug. The IRIX bug is quite old.

>
> Ubuntu has since updated their kernel to 2.6.32-28 and someone already verified at the bug report
> that the problem persists with that kernel version.
>
> "Regression between 2.6.32-27 and 2.6.32-26 xfsdump SGI_FS_BULKSTAT errno = 22"
> https://bugs.launchpad.net/bugs/692848

Between 2.6.32-26 and 2.6.32-27, Ubuntu backported 4 XFS commits from
2.6.35/2.6.36. All are part of a bulkstat security fix.

% git log Ubuntu-2.6.32-26.48..Ubuntu-2.6.32-27.49 -- fs/xfs | grep commit
commit 52d2a4cfbc852da8c3d3b9fa0cac2a07b12f5cfd
    (cherry picked from commit 4536f2ad8b330453d7ebec0746c4374eadd649b1)
commit eb5ab28c8a5e4bb3f1ce05eba166c12175f6c701
    (backported from commit 7b6259e7a83647948fa33a736cc832310c8d85aa)
commit 5f8e8c6ab416bbd58d4f5df512c119a888ff923c
    (cherry picked from commit 1920779e67cbf5ea8afef317777c5bf2b8096188)
commit 52e0d703745f7110f1ecbe83c02cf06a83da82e8
    (backported from commit 7124fe0a5b619d65b739477b3b55a20bf805b06d)

I'm not aware of a similar problem upstream, so it would appear
to be a problem with Ubuntu's backport of these commits.

Bill
=======================

So it would seem that an error crept in when Ubuntu committed these updates to the 2.6.32-27 kernel.

@Bill Nickless, Thank you for confirming the error persists with kernel 2.6.32-28.

According to http://oss.sgi.com/archives/xfs/2011-02/msg00085.html, Ubuntu also needs the "xfs: always use iget in bulkstat" fix. fyi, I included this change in the backport I did to fix CVE-2010-2943 in 2.6.32-longterm/Debian.

I'll attach a copy of this change ported to lucid.

Thank you so much Dann! Please let me know if you would like me to install an updated kernel package, and from where, to confirm the fix for you.

I'm also affected by this bug. I'm running the 2.6.32-28 virtual kernel in a KVM host.

root@db-sec-slave:~# xfsdump -f /var/tmp/xfsdump /vol
xfsdump: using file dump (drive_simple) strategy
xfsdump: version 3.0.4 (dump format 3.0) - Running single-threaded

 ============================= dump label dialog ==============================

please enter label for this dump session (timeout in 300 sec)
 -> test dump
session label entered: "test dump"

 --------------------------------- end dialog ---------------------------------

xfsdump: level 0 dump of db-sec-slave:/vol
xfsdump: dump date: Fri Feb 18 07:16:25 2011
xfsdump: session id: 29d11b80-65f0-4dcb-91fc-6c0b46645941
xfsdump: session label: "test dump"
xfsdump: ino map phase 1: constructing initial dump list
xfsdump: syssgi( SGI_FS_BULKSTAT ) on fsroot failed: Invalid argument
xfsdump: Dump Status: ERROR

Thanks for the Lucid backport Dann. When looking quickly at the CVE, it seems that beside of Lucid, this would also affect Karmic, Hardy, and Dapper. I will check and make sure that we update all potentially affected releases.

Maybe I am missing something. In order to check whether older releases might be affected, I created a xfs fs (mkfs.xfs /dev/...), mounted it and run "xfsdump -p10 -Ltest -Mdump -f outfile <mount>" on it. Still I am not able to trigger the error (even in Lucid). Is there a quick way to re-create this with a fresh filesystem or does it take some usage or maybe some special option on creation time?

@Stefan #8, On our server which I first saw the crash on, only three out of the eight or so xfsdump backups regularly scheduled caused this crash. The others all backed up "successfully". The dump I originally started this case with actually produced a partial backup size. The other two backup jobs resulted in 0 length dump files. Thus I decided to focus on the backup job which resulted in some size at all.

I could boot from the -26 kernel build and get 100% success backing up. Reboot to the -27 kernel, xfsdump crashes. The crashing has persisted into the -28 kernel build. For now, -26 is where we must stay.

Getting no responses here, I referenced this bug report with a note to the XFS developer list. Shortly some xfs chances were identified as being done for the -27 kernel, that one was suspected as having gotten overlooked when xfs code changes were merged into the Ubuntu Lucid code.

The thread on the xfs developer list has fallen silent, and now progress has been made on this bug report.

Right, Dann Frazier has pointed out the missing patch in comment #4 on this bug. So for 2.6.32 we should have the fix. I am trying to work out the way to proceed for older releases as the same four patches that have been identified as causing the regression on Lucid, have been backported to Karmic, Hardy and Dapper. Karmic is quite close, but the more we go back the more tweaking is needed. And so I would prefer to be able to verify that the bug exists there and is fixed with the backport.

But it sounds like I may just need to repeat the dump often enough. I will give it a try.

Hi Stefan,

Thanks for your work on this one! The one filesystem we use 'xfsdump' on is our BackupPC "pool" filesystem which is relatively large and densely populated with files. Since upgrading the kernel as the others described xfsdump always fails immediately on that filesystem. It's a 900GB filesystem with 15127929 inodes used according to 'df -i'.

So for us it consistently fails and is not sporadic. Just thought I'd share that data point.

For what it's worth, I use xfs for the root and /home filesystem on my Dell M6500. /home is also encrypted with ECRYPTFS. Since -26, xfsdump always fails immediately on both filesystems. I've been rebooting back to -26 to perform my weekly backups to offline media.

I have a 100mb xfs filesystem that causes xfsdump to fail every time. I created it by copying /usr/include to a newly created xfs filesystem within a file in /tmp/, deleting a few files, and then restoring them from /usr/include again. Should I attach it to this bug, or would you like me to put it up for you to download on my organization's public web server?

I found that gzip'ing the image makes it small enough to attach to this bug. So to replicate the problem under -28, download the attached file and do the following:

d3m406@nitwo-ubuntu:/tmp$ gunzip < ~/Desktop/100mb.xfs.gz > /tmp/100mb.xfs
d3m406@nitwo-ubuntu:/tmp$ sudo mkdir -p /mnt/100mb
d3m406@nitwo-ubuntu:/tmp$ sudo mount -o loop /tmp/100mb.xfs /mnt/100mb
d3m406@nitwo-ubuntu:/tmp$ sudo xfsdump /mnt/100mb -f /dev/null -L foo
xfsdump: using file dump (drive_simple) strategy
xfsdump: version 3.0.4 (dump format 3.0) - Running single-threaded
xfsdump: level 0 dump of nitwo-ubuntu:/mnt/100mb
xfsdump: dump date: Tue Feb 22 11:03:38 2011
xfsdump: session id: e2ef0d27-85c8-4273-9937-d5b33d534258
xfsdump: session label: "foo"
xfsdump: ino map phase 1: constructing initial dump list
xfsdump: syssgi( SGI_FS_BULKSTAT ) on fsroot failed: Invalid argument
xfsdump: Dump Status: ERROR
d3m406@nitwo-ubuntu:/tmp$ uname -a
Linux nitwo-ubuntu 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 23:42:43 UTC 2011 x86_64 GNU/Linux

Thanks for all the pointers. So size seems to matter in this case. :) I copied over more data to the xfs fs and this seems to trigger the bug. So now I can go back on releases and make sure about the status there.

For Maverick (2.6.35) the prereq patch is already included and the same for current development (Natty).

I see this has been reproduced on a small filesystem, but for future reference xfs
has a utility called xfs_metadump that helps in these situations. It grabs just the
metadata, so it results in a relatively small file, and the file can then be exploded back
into a sparse image of the original filesystem.

# xfs_metadump /dev/sda1 sda1.meta
# xfs_mdrestore sda1.meta sda1.img
# mount -o loop sda1.img /mnt

Should alleviate some of the pain in having to reproduce the issue on a new filesystem.

For posterity, CVE-2010-2943 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2943) only listed 3 patches despite the initial patch being a series of 4 commits.

https://bugzilla.redhat.com/show_bug.cgi?id=624923 shows all 4 patches. (Plus a QA patch and an additional patch to fix a regression. The Ubuntu backport includes the regression fix). Patch 1/4 was missing from the CVE bulletin and I assume that's why it was missing from the initial backport.

Regression problem is still present in Lucid 2.6.32-29:

d3m406@nitwo-ubuntu:~$ gunzip < ~/Desktop/100mb.xfs.gz > /tmp/100mb.xfs
d3m406@nitwo-ubuntu:~$ sudo mkdir -p /mnt/100mb
d3m406@nitwo-ubuntu:~$ sudo mount -o loop /tmp/100mb.xfs /mnt/100mb
d3m406@nitwo-ubuntu:~$ sudo xfsdump /mnt/100mb -f /dev/null -L foo
xfsdump: using file dump (drive_simple) strategy
xfsdump: version 3.0.4 (dump format 3.0) - Running single-threaded
xfsdump: level 0 dump of nitwo-ubuntu:/mnt/100mb
xfsdump: dump date: Wed Mar 2 12:47:37 2011
xfsdump: session id: 23a4fd59-b62f-43e8-8e24-80b0ea4449dd
xfsdump: session label: "foo"
xfsdump: ino map phase 1: constructing initial dump list
xfsdump: syssgi( SGI_FS_BULKSTAT ) on fsroot failed: Invalid argument
xfsdump: Dump Status: ERROR
d3m406@nitwo-ubuntu:~$ uname -a
Linux nitwo-ubuntu 2.6.32-29-generic #58-Ubuntu SMP Fri Feb 11 20:52:10 UTC 2011 x86_64 GNU/Linux
d3m406@nitwo-ubuntu:~$

Looks like the -29 release was compiled six days before Dann Frazier found the problem in Debian and eleven days before Stefan reproduced the problem in Ubuntu, so that's not too surprising :-)

Added backports for Lucid, Karmic and Hardy to be included for the next proposed cycle. It was decided to skip Dapper. First I could not see that problem there (there were rather other problem which I could not really claim to be a regression as its not clear how well xfs worked back then). Also the additional patch notes that performance should be ok with the radix based inode tree. That was not there before Hardy. So better leave things alone unless someone has real issues.

Thank you so much Stefan!

I switched over 100% to Ubuntu with 7.04 (Feisty Fawn) and XFS has been very stable since then. (Other than 7.10 which was the worst release ever, and I never did get a 7.10 box to production state!)

What about maverick (10.10) and also natty? Are these versions also affected?

As I am sticking with the -26 kernel, none of my servers which run apticron are nagging me for a kernel update. I suppose -26 is too far back and that is the reason I do not get notified. Could someone please attach a comment to this bug report when the new kernel build which includes this fix actually gets distributed so that I may update our systems? Thank you!

Maverick and later are ok because the missing patch came in before Maverick. As
soon as kernels with the missing patch are uploaded into proposed there will be
a request for testing posted to this bug.

Accepted linux into hardy-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Greetings Martin, Thank you for this invitation. This morning I followed the step in the documentation you posted a link to. I do not see an updated kernel version queue up for installation. I suppose that is to be expected as I only have the -26 kernel installed.

Manually looking through (in aptitude) I do see higher kernel versions. Which one should I chose to install as I am currently running:

linux-image-2.6.32-26-generic-pae in the x86 architecture.

Thanks!

Michael,

we only have a proposed update for Ubuntu 8.04 LTS (hardy) at the moment. Updates for 10.04 LTS (lucid, which you are using) will follow shortly and will be announced here.

Accepted linux into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Accepted linux-ec2 into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Accepted linux into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Accepted linux-ec2 into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Today I installed kernel:
linux-image-2.6.32-31-generic-pae_2.6.32-31.60_i386.deb

To hopefully test the fix on Lucid. The backup went through 100%. That is a good thing.

However I saw a few warnings when it was backing up the /etc directory. The backup command run was as following, then the full output of backing up /etc

20110321 15:29:07 Starting RUNcmd=/usr/sbin/xfsdump -e -F -f /mnt/ext_backup/ldslnx01/20110321/etc -s etc -L $STAMP"etc" -l 0 /
20110321 15:29:19 Ending RUNcmd=/usr/sbin/xfsdump -e -F -f /mnt/ext_backup/ldslnx01/20110321/etc -s etc -L $STAMP"etc" -l 0 / RC=0

/usr/sbin/xfsdump: using file dump (drive_simple) strategy
/usr/sbin/xfsdump: version 3.0.4 (dump format 3.0) - Running single-threaded
/usr/sbin/xfsdump: level 0 dump of ldslnx01:/
/usr/sbin/xfsdump: dump date: Mon Mar 21 15:29:07 2011
/usr/sbin/xfsdump: session id: 1bd12265-4478-41a3-b1b5-4e2d8e004f4d
/usr/sbin/xfsdump: session label: "etc"
/usr/sbin/xfsdump: ino map phase 1: constructing initial dump list
/usr/sbin/xfsdump: ino map phase 2: skipping (no pruning necessary)
/usr/sbin/xfsdump: ino map phase 3: skipping (only one dump stream)
/usr/sbin/xfsdump: ino map construction complete
/usr/sbin/xfsdump: estimated dump size: 6580992 bytes
/usr/sbin/xfsdump: WARNING: no media label specified
/usr/sbin/xfsdump: creating dump session media file 0 (media 0, file 0)
/usr/sbin/xfsdump: dumping ino map
/usr/sbin/xfsdump: dumping directories
/usr/sbin/xfsdump: WARNING: failed to get bulkstat information for inode 25166008
/usr/sbin/xfsdump: WARNING: failed to get bulkstat information for inode 25167014
/usr/sbin/xfsdump: WARNING: failed to get bulkstat information for inode 25176948
/usr/sbin/xfsdump: WARNING: failed to get bulkstat information for inode 25182342
/usr/sbin/xfsdump: dumping non-directory files
/usr/sbin/xfsdump: ending media file
/usr/sbin/xfsdump: media file size 3713504 bytes
/usr/sbin/xfsdump: dump size (non-dir files) : 3081488 bytes
/usr/sbin/xfsdump: dump complete: 12 seconds elapsed
/usr/sbin/xfsdump: Dump Status: SUCCESS

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed' to 'verification-done'.

If verification is not done by one week from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

I've verified that the proposed "Linux nitwo-ubuntu 2.6.32-31-generic #60-Ubuntu SMP Thu Mar 17 22:15:39 UTC 2011 x86_64 GNU/Linux" fixes the problem.

I also confirmed that the warnings noted in #30 appear to be harmless; I see them too but the resulting dump includes the files and the restored files match the ones backed up.

This is my first time changing tags on a Launchpad report so I hope I correctly changed verification-needed-lucid to verification-done-lucid.

@Bill Nickless #33, thank you for your quick work in both verifying and taking a shot at updating the tags on this bug report. Hopefully soon these new Lucid kernels will be released, and this problem will fade into memories... :-)

I have been running xfsdumps on both Karmic and Hardy with the proposed kernel and both passed.

I've also been running xfsdump/amanda via proposed kernel for Lucid, and it works great. Thanks! :)

This bug was fixed in the package linux - 2.6.24-29.88

---------------
linux (2.6.24-29.88) hardy-proposed; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #736290

  [Steve Conklin]

  * Ubuntu-2.6.24-29.87
  * [Config] Allow insertchanges to work in later version chroots

  [Upstream Kernel Changes]

  * do_exit(): make sure that we run with get_fs() == USER_DS,
    CVE-2010-4258
    - LP: #723945
    - CVE-2010-4258
  * Make the bulkstat_one compat ioctl handling more sane
    - LP: #692848
  * Fix xfs_bulkstat_one size checks & error handling
    - LP: #692848
  * xfs: always use iget in bulkstat
    - LP: #692848
  * x25: Prevent crashing when parsing bad X.25 facilities CVE-2010-4164
    - LP: #731199
    - CVE-2010-4164
  * Revised [CVE-2010-4346 Hardy] install_special_mapping skips
    security_file_mmap check. CVE-2010-4346
    - LP: #731971
    - CVE-2010-4346

linux (2.6.24-29.87) hardy-proposed; urgency=low

  [ Steve Conklin ]

  * Release Tracking Bug
    - LP: #725138

  [Upstream Kernel Changes]

  * bluetooth: Fix missing NULL check, CVE-2010-4242
    - LP: #714846
    - CVE-2010-4242
  * NFS: fix the return value of nfs_file_fsync()
    - LP: #585657
  * bio: take care not overflow page count when mapping/copying user data,
    CVE-2010-4162
    - LP: #721441
    - CVE-2010-4162
  * filter: make sure filters dont read uninitialized memory
    - LP: #721282
    - CVE-2010-4158
  * tty: Make tiocgicount a handler, CVE-2010-4076, CVE-2010-4077
    - LP: #720189
    - CVE-2010-4077
  * block: check for proper length of iov entries earlier in
    blk_rq_map_user_iov(), CVE-2010-4163
    - LP: #721504
    - CVE-2010-4163
 -- Brad Figg <email address hidden> Wed, 16 Mar 2011 09:43:35 -0700

Checking in on this... Is there additional testing which needs to get done? Or is this code ready to release to Lucid stable? Is there an ETA as to when this update will be distributed to Lucid stable? Thank you!

Accepted linux-ec2 into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

This bug was fixed in the package linux - 2.6.32-31.61

---------------
linux (2.6.32-31.61) lucid-proposed; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #754842

  [ Upstream Kernel Changes ]

  * x86, quirk: Fix SB600 revision check
    - LP: #742056

linux (2.6.32-31.60) lucid-proposed; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #734950

  [ Paolo Pisati ]

  * SAUCE: Clear new_profile in error path
    - LP: #732700

  [ Tim Gardner ]

  * [Config] CONFIG_BOOT_PRINTK_DELAY=y
    - LP: #733191

  [ Upstream Kernel Changes ]

  * Revert "drm/radeon/bo: add some fallback placements for VRAM only
    objects."
    - LP: #652934
  * drm/radeon: fall back to GTT if bo creation/validation in VRAM fails.
    - LP: #652934
  * drm/radeon/kms: Fix retrying ttm_bo_init() after it failed once.
    - LP: #652934
  * xfs: always use iget in bulkstat
    - LP: #692848
  * drm/radeon/kms: make the mac rv630 quirk generic
    - LP: #728687
  * drm/radeon/kms: add pll debugging output
    - LP: #728687
  * drm/radeon: remove 0x4243 pci id
    - LP: #728687
  * drm/radeon/kms: fix s/r issues with bios scratch regs
    - LP: #728687
  * drm/i915/lvds: Add AOpen i915GMm-HFS to the list of false-positive LVDS
    - LP: #728687
  * drm/i915: Add dependency on CONFIG_TMPFS
    - LP: #728687
  * Linux 2.6.32.29+drm33.14
    - LP: #728687
  * NFSD: memory corruption due to writing beyond the stat array
    - LP: #728687
  * mptfusion: mptctl_release is required in mptctl.c
    - LP: #728687
  * mptfusion: Fix Incorrect return value in mptscsih_dev_reset
    - LP: #728687
  * ocfs2_connection_find() returns pointer to bad structure
    - LP: #728687
  * x25: decrement netdev reference counts on unload
    - LP: #728687
  * x86, hpet: Disable per-cpu hpet timer if ARAT is supported
    - LP: #728687
  * OHCI: work around for nVidia shutdown problem
    - LP: #728687
  * x86/pvclock: Zero last_value on resume
    - LP: #728687
  * av7110: check for negative array offset
    - LP: #728687
  * CRED: Fix get_task_cred() and task_state() to not resurrect dead
    credentials
    - LP: #728687
  * bonding/vlan: Avoid mangled NAs on slaves without VLAN tag insertion
    - LP: #728687
  * CRED: Fix kernel panic upon security_file_alloc() failure.
    - LP: #728687
  * CRED: Fix BUG() upon security_cred_alloc_blank() failure
    - LP: #728687
  * CRED: Fix memory and refcount leaks upon security_prepare_creds()
    failure
    - LP: #728687
  * sendfile(): check f_op.splice_write() rather than f_op.sendpage()
    - LP: #728687
  * isdn: hisax: Replace the bogus access to irq stats
    - LP: #728687
  * ixgbe: add support for 82599 based Express Module X520-P2
    - LP: #728687
  * ixgbe: prevent speculative processing of descriptors before ready
    - LP: #728687
  * scsi_dh_alua: add netapp to dev list
    - LP: #728687
  * scsi_dh_alua: Add IBM Power Virtual SCSI ALUA device to dev list
    - LP: #728687
  * dm raid1: fail writes if errors are not handled and log fails
    - LP: #728687
  * GFS2: Fix bmap allocation corner-case bug
    - LP: #728687
  * dm raid1: fix null pointer dereference in suspend
    - LP: #728687
  * sunrpc/...

On our server we tested this fix on, I disconnected the testing repository. This morning I was notified that linux-image-2.6.32-31-generic-pae_2.6.32-31.61_i386.deb was available. I pulled down that build, IPL'ed, and performed a backup. The backup completed flawlessly. Next up, testing this same kernel build at a client site.

Thank you so much for getting this fixed code into production! We really appreciate it! :-)

This bug was fixed in the package linux - 2.6.31-23.75

---------------
linux (2.6.31-23.75) karmic-proposed; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #737663

  [ Upstream Kernel Changes ]

  * do_exit(): make sure that we run with get_fs() == USER_DS,
    CVE-2010-4258
    - LP: #723945
    - CVE-2010-4258
  * xfs: always use iget in bulkstat
    - LP: #692848
  * x25: Prevent crashing when parsing bad X.25 facilities CVE-2010-4164
    - LP: #731199
    - CVE-2010-4164
  * Revised [CVE-2010-4345 Karmic] install_special_mapping skips
    security_file_mmap check. CVE-2010-4346
    - LP: #731971
    - CVE-2010-4346
  * econet: Fix crash in aun_incoming(). CVE-2010-4342
    - LP: #736394
    - CVE-2010-4342
 -- Brad Figg <email address hidden> Fri, 18 Mar 2011 09:43:00 -0700

Can confirm that 2.6.32-316-ec2 fixes my problems with xfsdump.

This bug was fixed in the package linux-ec2 - 2.6.31-308.29

---------------
linux-ec2 (2.6.31-308.29) karmic-proposed; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #737761

  [ Brad Figg ]

  * Rebased to 2.6.31-23.75

  [ Ubuntu: 2.6.31-23.75 ]

  * Release Tracking Bug
    - LP: #737663
  * do_exit(): make sure that we run with get_fs() == USER_DS,
    CVE-2010-4258
    - LP: #723945
    - CVE-2010-4258
  * xfs: always use iget in bulkstat
    - LP: #692848
  * x25: Prevent crashing when parsing bad X.25 facilities CVE-2010-4164
    - LP: #731199
    - CVE-2010-4164
  * Revised [CVE-2010-4345 Karmic] install_special_mapping skips
    security_file_mmap check. CVE-2010-4346
    - LP: #731971
    - CVE-2010-4346
  * econet: Fix crash in aun_incoming(). CVE-2010-4342
    - LP: #736394
    - CVE-2010-4342
 -- Brad Figg <email address hidden> Fri, 18 Mar 2011 11:55:37 -0700

This bug was fixed in the package linux-ec2 - 2.6.32-316.31

---------------
linux-ec2 (2.6.32-316.31) lucid-proposed; urgency=low

  [ Stefan Bader ]

  * XEN: x86: Flush TLB if PGD entry is changed in i386 PAE mode
    - LP: #742056
  * XEN: x86: Emit "mem=nopentium ignored" warning when not supported
    - LP: #742056
  * XEN: x86: Fix panic when handling "mem={invalid}" param
    - LP: #742056
  * XEN: x86/mm: Handle mm_fault_error() in kernel space
    - LP: #742056
  * SAUCE: XEN: Do not force sched_clock_stable
    - LP: #727459

linux-ec2 (2.6.32-316.30) lucid-proposed; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #767978

  [ Brad Figg ]

  * Rebased to 2.6.32-32.62

  [ Ubuntu: 2.6.32-32.62 ]

  * Release Tracking Bug
    - LP: #767370
  * (config) Disable CONFIG_NET_NS
    - LP: #720095
  * Revert "drm/radeon/kms: Fix retrying ttm_bo_init() after it failed
    once."
    - LP: #736234
  * Revert "drm/radeon: fall back to GTT if bo creation/validation in VRAM
    fails."
    - LP: #736234
  * x86: pvclock: Move scale_delta into common header
  * KVM: x86: Fix a possible backwards warp of kvmclock
  * KVM: x86: Fix kvmclock bug
  * cpuset: add a missing unlock in cpuset_write_resmask()
    - LP: #736234
  * keyboard: integer underflow bug
    - LP: #736234
  * RxRPC: Fix v1 keys
    - LP: #736234
  * ixgbe: fix for 82599 erratum on Header Splitting
    - LP: #736234
  * mm: fix possible cause of a page_mapped BUG
    - LP: #736234
  * powerpc/kdump: CPUs assume the context of the oopsing CPU
    - LP: #736234
  * powerpc/kdump: Use chip->shutdown to disable IRQs
    - LP: #736234
  * powerpc: Use more accurate limit for first segment memory allocations
    - LP: #736234
  * powerpc/pseries: Add hcall to read 4 ptes at a time in real mode
    - LP: #736234
  * powerpc/kexec: Speedup kexec hash PTE tear down
    - LP: #736234
  * powerpc/crashdump: Do not fail on NULL pointer dereferencing
    - LP: #736234
  * powerpc/kexec: Fix orphaned offline CPUs across kexec
    - LP: #736234
  * netfilter: nf_log: avoid oops in (un)bind with invalid nfproto values
    - LP: #736234
  * nfsd: wrong index used in inner loop
    - LP: #736234
  * r8169: use RxFIFO overflow workaround for 8168c chipset.
    - LP: #736234
  * Staging: comedi: jr3_pci: Don't ioremap too much space. Check result.
    - LP: #736234
  * net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules,
    CVE-2011-1019
    - LP: #736234
    - CVE-2011-1019
  * ip6ip6: autoload ip6 tunnel
    - LP: #736234
  * Linux 2.6.32.33
    - LP: #736234
  * drm/radeon: fall back to GTT if bo creation/validation in VRAM fails.
    - LP: #652934, #736234
  * drm/radeon/kms: Fix retrying ttm_bo_init() after it failed once.
    - LP: #652934, #736234
  * drm: fix unsigned vs signed comparison issue in modeset ctl ioctl,
    CVE-2011-1013
    - LP: #736234
    - CVE-2011-1013
  * Linux 2.6.32.33+drm33.15
    - LP: #736234
  * econet: Fix crash in aun_incoming(). CVE-2010-4342
    - LP: #736394
    - CVE-2010-4342
  * igb: only use vlan_gro_receive if vlans are registered, CVE-2010-4263
    - LP: #737024
    - CVE-2010-4263
  * irda: prevent integer underflow in IRLMP...

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".