Btrfs: don't access non-existent key when csum tree is empty
authorFilipe Manana <fdmanana@gmail.com>
Wed, 9 Apr 2014 13:38:34 +0000 (14:38 +0100)
committerChris Mason <clm@fb.com>
Tue, 10 Jun 2014 00:20:44 +0000 (17:20 -0700)
commit35045bf2fd7c030f2583dbd80a2015f427778bf1
tree22a4244b8da4ed5a9c569a381ca7887d96934649
parentde348ee022175401e77d7662b7ca6e231a94e3fd
Btrfs: don't access non-existent key when csum tree is empty

When the csum tree is empty, our leaf (path->nodes[0]) has a number
of items equal to 0 and since btrfs_header_nritems() returns an
unsigned integer (and so is our local nritems variable) the following
comparison always evaluates to false:

     if (path->slots[0] >= nritems - 1) {

As the casting rules lead to:

     if ((u32)0 >= (u32)4294967295) {

This makes us access key at slot paths->slots[0] + 1 (1) of the empty leaf
some lines below:

    btrfs_item_key_to_cpu(path->nodes[0], &found_key, slot);
    if (found_key.objectid != BTRFS_EXTENT_CSUM_OBJECTID ||
        found_key.type != BTRFS_EXTENT_CSUM_KEY) {
found_next = 1;
goto insert;
    }

So just don't access such non-existent slot and don't set found_next to 1
when the tree is empty. It's very unlikely we'll get a random key with the
objectid and type values above, which is where we could go into trouble.

If nritems is 0, just set found_next to 1 anyway as it will make us insert
a csum item covering our whole extent (or the whole leaf) when the tree is
empty.

Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Signed-off-by: Chris Mason <clm@fb.com>
fs/btrfs/file-item.c