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 <ker...@kyup.com>
Suggested-by: Chris Mason <c...@fb.com>
Link: https://lkml.kernel.org/r/57a473b0.2040...@kyup.com
---
 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to