Comment 73 for bug 396286

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.