| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20090224155119.GC22108@duck.suse.cz> Date: Tue, 24 Feb 2009 16:51:20 +0100 From: Jan Kara <jack@...e.cz> To: "Sachin P. Sant" <sachinp@...ibm.com> Cc: Paul Mackerras <paulus@...ba.org>, Andrew Morton <akpm@...ux-foundation.org>, Mel Gorman <mel@....ul.ie>, linuxppc-dev@...abs.org, linux-ext4@...r.kernel.org, Jan Kara <jack@....cz>, linux-kernel <linux-kernel@...r.kernel.org>, Mark Nelson <markn@....ibm.com> Subject: Re: Crash (ext3 ) during 2.6.29-rc6 boot Hello, On Tue 24-02-09 12:08:37, Sachin P. Sant wrote: > Jan Kara wrote: >> Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy >> somehow got beyond end of the page referenced by bh->b_data. So it means >> that le16_to_cpu(entry->e_value_offs) + size > page_size. But >> ext3_xattr_find_entry() calls ext3_xattr_check_entry() which in >> particular checks whether e_value_offs + e_value_size isn't greater than >> bh->b_size. So I see no way how memcpy can get beyond end of the page. >> Sachin, is the problem reproducible? If yes, can you send us contents >> > Yes, i am able to recreate this problem easily. As i had mentioned if the > earlier kernel is booted with selinux enabled and then 2.6.29-rc6 is booted > i get this crash. But if i specify selinux=0 at command line, 2.6.29-rc6 boots > without any problem. > >> of the page just before the faulting address (i.e., for current fault it >> would be 0xc00000003f370000-0xc00000003f37ffff). As far as I can >> remember powerpc monitor could dump it. >> > Here is the page dump. This time it crashed while accessing address > 0xc00000002d670000. Thanks for the dump. > Unable to handle kernel paging request for data at address 0xc0000 > 0002d670000 > Faulting instruction address: 0xc000000000039574 > cpu 0x1: Vector: 300 (Data Access) at [c00000004288b0b0] > pc: c000000000039574: .memcpy+0x74/0x244 > lr: c0000000001b497c: .ext3_xattr_get+0x288/0x2f4 > sp: c00000004288b330 > msr: 8000000000009032 > > 1:mon> d 0xc00000002d660000 > ............................... <SNIP> ............................... > > c00000002d66efd0 0000000000000000 0000000000000000 |................| > c00000002d66efe0 0000000000000000 0000000000000000 |................| > c00000002d66eff0 0000000000000000 0000000000000000 |................| > c00000002d66f000 000002ea00040000 01000000e200d20a |................| > c00000002d66f010 0000000000000000 0000000000000000 |................| > c00000002d66f020 0706e40f00000000 1b000000e200d20a |................| > c00000002d66f030 73656c696e757800 0000000000000000 |selinux.........| > c00000002d66f040 0000000000000000 0000000000000000 |................| > c00000002d66f050 0000000000000000 0000000000000000 |................| > c00000002d66f060 0000000000000000 0000000000000000 |................| > > ............................... <SNIP> ............................... > > c00000002d66ff60 0000000000000000 0000000000000000 |................| > c00000002d66ff70 0000000000000000 0000000000000000 |................| > c00000002d66ff80 0000000000000000 0000000000000000 |................| > c00000002d66ff90 0000000000000000 0000000000000000 |................| > c00000002d66ffa0 0000000000000000 0000000000000000 |................| > c00000002d66ffb0 0000000000000000 0000000000000000 |................| > c00000002d66ffc0 0000000000000000 0000000000000000 |................| > c00000002d66ffd0 0000000000000000 0000000000000000 |................| > c00000002d66ffe0 0000000073797374 656d5f753a6f626a |....system_u:obj| > c00000002d66fff0 6563745f723a7573 725f743a73300000 |ect_r:usr_t:s0..| > c00000002d670000 **************** **************** | | > 1:mon> r > R00 = 000000000000e40f R16 = 000000000000005d > R01 = c00000004288b330 R17 = 0000000000000000 > R02 = c0000000009f59b8 R18 = 00000000fffbfe9e > R03 = c000000044aa34a0 R19 = 0000000010042638 > R04 = c00000002d66fff4 R20 = 0000000010041610 > R05 = 0000000000000003 R21 = 00000000000000ff > R06 = 0000000000000000 R22 = 0000000000000006 > R07 = 0000000000000001 R23 = c0000000007d27c1 > R08 = 723a7573725f743a R24 = c00000002c0cd758 > R09 = 3a6f626a6563745f R25 = c000000044aa3488 > R10 = c00000000017b43c R26 = c00000002c0cd6f0 > R11 = c00000002d66f020 R27 = c00000002c0cd860 > R12 = d0000000023c14b0 R28 = c00000002c0b0840 > R13 = c000000000a93680 R29 = 000000000000001b > R14 = 00000000000041ed R30 = c0000000009880b0 > R15 = 0000000010040000 R31 = ffffffffffffffde > pc = c000000000039574 .memcpy+0x74/0x244 > lr = c0000000001b497c .ext3_xattr_get+0x288/0x2f4 > msr = 8000000000009032 cr = 4400044b > ctr = 0000000000000000 xer = 0000000020000001 trap = 300 > dar = c00000002d670000 dsisr = 40000000 > 1:mon> zr > >> BTW, I suppose you use 4KB blocksize on the filesystem, right? >> > Yes. > > dumpe2fs /dev/sda3 | grep -i "block size" dumpe2fs 1.39 (29-May-2006) > Block size: 4096 OK. The xattr block causing oops is completely correct. To me it seems more like some problem in powerpc memcpy() (I saw there went some changes into in in the end of December) - we call it to copy 27 bytes from address 0xc00000002d66ffe4 (which is one byte before end of the page). Could some of the powerpc guys have a look whether this could be the case? I'm not quite fluent in the powerpc assembly so it would take me ages ;). Honza -- Jan Kara <jack@...e.cz> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists