Bug 10802
Summary: | BUG at fs/hfs/bnode.c:416 with corrupted image | ||
---|---|---|---|
Product: | File System | Reporter: | Eric Sesterhenn (snakebyte) |
Component: | HFS/HFSPLUS | Assignee: | Christoph Hellwig (hch) |
Status: | CLOSED OBSOLETE | ||
Severity: | normal | CC: | alan, hch, lnx1138, vladc6 |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.27-rc6 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | Corrupted Image |
Description
Eric Sesterhenn
2008-05-27 01:21:23 UTC
Created attachment 16289 [details]
Corrupted Image
Verified Hello, I am wondering if there has been any additional findings with this bug. A test team reported basically the same problem to my group internally while they were testing an enterprise linux release originally based on a 2.6.27 kernel. I haven't had a chance to investigate this to deeply yet but this is what I have so far. I have done a couple of debug patches trying to find out why it was having problems encountering a duplicate bnode and still have to refine the debug output to isolate that. One part of the debug patch replaced the BUG_ON() with a test and an error that is returned by hfs_bnode_create() when it encounters the error condition. I mainly did this because whenever we hit the BUG_ON which kills the calling process, we seem to leave a btree lock held which was initially acquired by the call to hfs_find_init() in hfs_cat_create(). This in turn causes subsequent accesses to hang and also prevents unmounting the fs. --- linux-2.6.27.19-5/fs/hfs/bnode.c.orig 2009-05-08 10:42:30.000000000 -0500 +++ linux-2.6.27.19-5/fs/hfs/bnode.c 2009-05-08 10:56:01.000000000 -0500 @@ -413,7 +413,10 @@ struct hfs_bnode *hfs_bnode_create(struc spin_lock(&tree->hash_lock); node = hfs_bnode_findhash(tree, num); spin_unlock(&tree->hash_lock); - BUG_ON(node); + if (unlikely(node)) { + printk(KERN_ERR "hfs: bnode %d already exists in B*Tree!\n", num); + return ERR_PTR(-EEXIST); + } node = __hfs_bnode_create(tree, num); if (!node) return ERR_PTR(-ENOMEM); Replacing the BUG_ON is likely not the fix but it does avoid hangs for subsequent accesses and also allows the fs to be unmounted. This is because the error propagates back down to hfs_cat_create() allowing it to invoke hfs_find_exit() on the error path which releases the tree lock. My understanding of the fsfuzzer tests are not necessarily to completely bulletproof the fs but at a minimum allow it to more gracefully handle unexpected problems with metadata to avoid security exploits and crashes. I am not sure that this one is that bad unless you consider the tree lock being held by hitting this condition as a denial of service exploit. I would appreciate any help in finding the cause and a solution for the reported problem. I'll try to do some debugging on my own as well but I am not all too familiar yet with the HFS data structures. CC'ed Christoph Hellwig since he took over maintainership. I'm only looking at hfsplus for now. |