While zalloc() takes a size_t type, adding 1 to the le32 variable
will overflow.
A carefully crafted ext4 filesystem can exhibit an inode size of 0xffffffff
and as consequence zalloc() will do a zero allocation.

Later in the function the inode size is again used for copying data.
So an attacker can overwrite memory.

Avoid the overflow by using the __builtin_add_overflow() helper.

Signed-off-by: Richard Weinberger <rich...@nod.at>
---
I have found and verified this bug in u-boot.
But Barebox uses the same code, so it is most likely affected too.

Thanks,
//richard
---
 fs/ext4/ext4_common.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 4bfb55ad0d..a38593105f 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -369,13 +369,18 @@ char *ext4fs_read_symlink(struct ext2fs_node *node)
        char *symlink;
        struct ext2fs_node *diro = node;
        int status, ret;
+       size_t alloc_size;
 
        if (!diro->inode_read) {
                ret = ext4fs_read_inode(diro->data, diro->ino, &diro->inode);
                if (ret)
                        return NULL;
        }
-       symlink = zalloc(le32_to_cpu(diro->inode.size) + 1);
+
+       if (__builtin_add_overflow(le32_to_cpu(diro->inode.size), 1, 
&alloc_size))
+               return NULL;
+
+       symlink = zalloc(alloc_size);
        if (!symlink)
                return 0;
 
-- 
2.35.3


Reply via email to