[Bug 396286] Re: 2.6.31-generic: kernel panic near the end of initramfs

[Stefan Bader]

Thanks Martin-Éric,

checking against the code this confirms that the bug occurs in
__destroy_inode at the following position:

232	void __destroy_inode(struct inode *inode)
233	{
234		BUG_ON(inode_has_buffers(inode));
235		ima_inode_free(inode);
236		security_inode_free(inode);
237		fsnotify_inode_delete(inode);
238	#ifdef CONFIG_FS_POSIX_ACL
239		if (inode->i_acl && inode->i_acl != ACL_NOT_CACHED)
240			posix_acl_release(inode->i_acl); /* here */
241		if (inode->i_default_acl && inode->i_default_acl != ACL_NOT_CACHED)
242			posix_acl_release(inode->i_default_acl);
243	#endif
244	}

In EAX is the address of i_acl, so it looks like it is (repeatably) 0xffffb4ff. In theory i_acl is either a pointer to an acl structure or 0xffffffff (ACL_NOT_CACHED) or 0x0 (uninitialized). The address causing the bug seems a bit high for being a valid pointer. But just to be completely sure I put a kernel to http://people.canonical.com/~smb/bug396286/ which tries to catch a double free case.
On the other side 0xffffb4ff might be caused by something either writing 0xb4ff  into the first word (little endian) or 0xb4 at offset 1 into the area that holds the pointer. Before the change that added i_acl and i_default_acl, the last field was a private pointer.  Could something (this would need to be an externally build module) still use the wrong header file?...
One thing to try next would be to check whether the other pointer is corrupted too. I try to get something sensible up and the post here.

-- 
2.6.31-generic: kernel panic near the end of initramfs
https://bugs.launchpad.net/bugs/396286
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to Linux.