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: <alpine.LNX.2.00.1203161028420.18356@pobox.suse.cz> Date: Fri, 16 Mar 2012 10:29:56 +0100 (CET) From: Jiri Kosina <jkosina@...e.cz> To: Jan Kara <jack@...e.cz> Cc: George Spelvin <linux@...izon.com>, linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: Oops in ext3_block_to_path.isra.40+0x26/0x11b On Fri, 16 Mar 2012, Jan Kara wrote: > > CPU is a Core i3 530, on a Gigabyte motherbord, 4 GB RAM. No ECC, > > unfortunately, so I can't rule out hardware bit rot. Distribution is > > a fairly stock Debian/unstable. > Hmm, is any mounting & unmounting happening during your backup? Because > the oops happened because sb->s_fs_info was NULL. Dissassembly shows: > 16: 48 8b 47 18 mov 0x18(%rdi),%rax > store sb->s_blocksize into RAX > 1a: 48 8b 8f b0 02 00 00 mov 0x2b0(%rdi),%rcx > store sb->s_fs_info into RCX > 21: 48 c1 e8 02 shr $0x2,%rax > This is division from EXT3_ADDR_PER_BLOCK() - RAX carries 1024 after > division so that looks correct. > > 25: 48 85 db test %rbx,%rbx > Now check passed i_block argument. > > 28: 41 89 c4 mov %eax,%r12d > 2b:* 8b b1 94 00 00 00 mov 0x94(%rcx),%esi <-- trapping ins > Try to get RCX->s_addr_per_block_bits... > > sb->s_fs_info is set when a superblock is mounted and cleared when > superblock gets unmounted and otherwise it is never changed. So most likely > it was some memory corruption clearing that pointer (I wouldn't really > suspect HW here). > > It somewhat looks like the issue described here: > http://lkml.indiana.edu/hypermail/linux/kernel/1202.3/00132.html > > Although there we had f_path.dentry (completely different structure) being > NULL. But similarity here is that something stomped NULL over our existing > structure. > > Linus, Jiri, that bug didn't get resolved, did it? I am not aware of anything, but I have a question -- George, did the machine get suspended/resumed before this happened? -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists