btrfs_uuid_iter_rem is able to return -ENOENT, however this condition is not handled in btrfs_uuid_tree_iterate which can lead to calling btrfs_next_item with freed path argument, leading to a null pointer dereference. Fix it by redoing the search but with an incremented objectid so we don't loop over the same key. Signed-off-by: Nikolay Borisov <kernel@xxxxxxxx> Suggested-by: Chris Mason <clm@xxxxxx> Link: https://lkml.kernel.org/r/57A473B0.2040203@xxxxxxxx --- fs/btrfs/uuid-tree.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) Hello Chris, Since I keep getting those crashes I (hopefully correctly) implemented your suggestion of redoing the search with an incremented key so we don't end up in a loop. Does that look correct? diff --git a/fs/btrfs/uuid-tree.c b/fs/btrfs/uuid-tree.c index 778282944530..6e5b3866a65c 100644 --- a/fs/btrfs/uuid-tree.c +++ b/fs/btrfs/uuid-tree.c @@ -329,8 +329,12 @@ again_search_slot: * entry per UUID exists. */ goto again_search_slot; - } - if (ret < 0 && ret != -ENOENT) + } else if (ret == -ENOENT) { + key.type = 0; + key.offset = 0; + key.objectid++; + goto again_search_slot; + } else if (ret < 0) goto out; } item_size -= sizeof(subid_le); -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
