On 02/28/2011 06:00 PM, Eric Sandeen wrote:
On 2/28/11 4:58 PM, Jeffrey Hundstad wrote:
Hello,
I'm compiling the main Linux branch commit 493f3358cb289ccf716c5a14fa5bb52ab75943e5 with no other patches. It boots and seems to operate fine. When I do an xfs_fsr it Kernel panics. I can easily reproduce it
Kernel Panic: (hand copied, photo available)
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: f87aca93
Pid: 262, comm: xfs_fsr Not tainted 2.6.38-rc6-493f3358cb2+ #1
Call Trace:
[<c12991ac>] ? panic+0x50/0x150
[<c102ed71>] ? __stack_chk_fail+0x10/0x18
[<f87aca93>] ? xfs_ioc_fsgeometry_v1+0x56/0x5d [xfs]
[<f87aca93>] ? xfs_ioc_fsgeometry_v1+0x56/0x5d [xfs]
[<f87ae062>] ? xfs_file_ioctl+0x33c/0x6fe [xfs]
[<c1047f1a>] ? sched_clock_cpu+0x130/0x140
[<c1050f41>] ? trace_hardirqs_off+0xb/0xd
[<c1047f57>] ? local_clock+0x2d/0x4e
[<c1050f6e>] ? lock_release_holdtime+0x2b/0xcd
[<c10a925a>] ? check_valid_pointer+0x1c/0x48
[<c10a99c8>] ? check_object+0x122/0x156
[<f87add26>] ? xfs_file_ioctl+0x0/0x6fe [xfs]
[<c10bf5c9>] ? do_vfs_ioctl+0x483/0x4c8
[<c10aab72>] ? kmeme_chache_free+0x8f/0x9b
[<c10b41b4>] ? fcheck_files+0xa1/0xd0
[<c10bf64f>] ? sys_ioctl+0x41/0x61
[<c1002893>] ? sysenter_do_call+0x12/0x32
You can find the config, initrd.img, vmlinuz and crash screen at:
http://krypton.mnsu.edu/~j3gum/linux-error-20110228/
- gcc (Debian 4.4.5-13) 4.4.5
- xfs_fsr version 3.1.4
Please let know if you'd like more info.
I tried to extract your vmlinuz to a vmlinux to disassemble and look at stack usage of functions, but that was painful and did not seem to work out in the end. :)
Can you do:
objdump -d vmlinux | scripts/checkstack.pl
and similar for xfs if it's a module:
objdump -d xfs.ko | scripts/checkstack.pl
and see how big each of the functions on the above backtrace is, in your kernel?
Sadly, I didn't have the vmlinux file around anymore. I'll be glad to
recreate it when I get in tomorrow. However, I have revered commit
3a3675b7f23f83ca8c67c9c2b6edf707fd28d1ba and the problem seems to have
vanished. I'm guessing the stack at this point is a little to fragile
for a memset. The patch is:
commit 3a3675b7f23f83ca8c67c9c2b6edf707fd28d1ba
Author: Dan Rosenberg <drosenberg@xxxxxxxxxxxxx>
Date: Mon Feb 14 13:45:28 2011 +0000
xfs: prevent leaking uninitialized stack memory in FSGEOMETRY_V1
The FSGEOMETRY_V1 ioctl (and its compat equivalent) calls out to
xfs_fs_geometry() with a version number of 3. This code path does not
fill in the logsunit member of the passed xfs_fsop_geom_t, leading to
the leaking of four bytes of uninitialized stack data to potentially
unprivileged callers.
v2 switches to memset() to avoid future issues if structure members
change, on suggestion of Dave Chinner.
Signed-off-by: Dan Rosenberg <drosenberg@xxxxxxxxxxxxx>
Reviewed-by: Eugene Teo <eugeneteo@xxxxxxxxxx>
Signed-off-by: Alex Elder <aelder@xxxxxxx>
diff --git b/fs/xfs/xfs_fsops.c a/fs/xfs/xfs_fsops.c
index cec89dd..85668ef 100644
--- b/fs/xfs/xfs_fsops.c
+++ a/fs/xfs/xfs_fsops.c
@@ -53,6 +53,9 @@ xfs_fs_geometry(
xfs_fsop_geom_t *geo,
int new_version)
{
+
+ memset(geo, 0, sizeof(*geo));
+
geo->blocksize = mp->m_sb.sb_blocksize;
geo->rtextsize = mp->m_sb.sb_rextsize;
geo->agblocks = mp->m_sb.sb_agblocks;
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
