Found this by running a 32-bit xfs_logprint on a 64-bit kernel: # xfs_logprint /dev/loop0 xfs_logprint: *** stack smashing detected ***: xfs_logprint terminated Aborted (core dumped) The problem here is that there is no sys_compat_ustat, and the kernel copies out a structure larger than userspace has provided: 32-bit ustat struct from userspace: struct ustat { __daddr_t f_tfree; /* 0 4 */ __ino_t f_tinode; /* 4 4 */ char f_fname[6]; /* 8 6 */ char f_fpack[6]; /* 14 6 */ /* size: 20, cachelines: 1 */ /* last cacheline: 20 bytes */ }; kernel ustat struct: struct ustat { __kernel_daddr_t f_tfree; /* 0 4 */ /* XXX 4 bytes hole, try to pack */ __kernel_ino_t f_tinode; /* 8 8 */ char f_fname[6]; /* 16 6 */ char f_fpack[6]; /* 22 6 */ /* size: 32, cachelines: 1 */ /* sum members: 24, holes: 1, sum holes: 4 */ /* padding: 4 */ /* last cacheline: 32 bytes */ }; ... so userspace is corrupted when this syscall is called. Christoph Hellwig mentioned that he might take a stab at fixing it, since he's done other compat syscalls, but not sure on what schedule, so perhaps I (or our ppc maintainer, if we have one...?) can take a look at the fix. Proposing blocker since this is a memory corruptor in general.
Created attachment 324223 [details] Untested patch for upstream from hch
Created attachment 324224 [details] Untested patch for upstream from hch
Created attachment 324227 [details] Tested RHEL5 patch.
See also http://rhts.redhat.com/cgi-bin/rhts/test_log.cgi?id=5087037
I've tested the patch in comment #3 on ppc, and it resolves the issue I saw.
FWIW, the same problem exists with x86 binaries on x86_64 or ia64.
Oh, sorry, my head is not screwed on straight. x86 already has the compat handler in place.
Moving to 5.4
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Updating PM score.
Need to resend this one, but need to get it upstream first.
Ok, upstream now post-2.6.29: From: Christoph Hellwig <hch> Date: Fri, 28 Nov 2008 09:09:09 +0000 (+0100) Subject: generic compat_sys_ustat X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=2b1c6bd77d4e6a727ffac8630cd154b2144b751a generic compat_sys_ustat Due to a different size of ino_t ustat needs a compat handler, but currently only x86 and mips provide one. Add a generic compat_sys_ustat and switch all architectures over to it. Instead of doing various user copy hacks compat_sys_ustat just reimplements sys_ustat as it's trivial. This was suggested by Arnd Bergmann. Found by Eric Sandeen when running xfstests/017 on ppc64, which causes stack smashing warnings on RHEL/Fedora due to the too large amount of data writen by the syscall. Signed-off-by: Christoph Hellwig <hch> Signed-off-by: Al Viro <viro.org.uk> --- and From: David S. Miller <davem> Date: Sat, 28 Mar 2009 01:15:02 +0000 (-0700) Subject: sparc64: We need to use compat_sys_ustat() as well. X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=6e8a4fa651975ff808dba130eae442f4cea1671c sparc64: We need to use compat_sys_ustat() as well. Sparc was missed in commit 2b1c6bd77d4e6a727ffac8630cd154b2144b751a ("generic compat_sys_ustat"). We definitely need it, since our __kernel_ino_t is "unsigned long". Signed-off-by: David S. Miller <davem> ---
in kernel-2.6.18-138.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5 Please do NOT transition this bugzilla state to VERIFIED until our QE team has sent specific instructions indicating when to do so. However feel free to provide a comment indicating that this fix has been verified.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-1243.html