linux-kernel - Re: [PATCH 1/2] Revert "UBIFS: Fix potential integer overflow in allocation"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGXu5jJyeoKdqo86+tWoq1n34sELSAXQu8LSBpEbiu2oFg2JPQ@mail.gmail.com>
Date:   Mon, 2 Jul 2018 09:00:05 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Richard Weinberger <richard@....at>
Cc:     Linux mtd <linux-mtd@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Silvio Cesare <silvio.cesare@...il.com>,
        "# 3.4.x" <stable@...r.kernel.org>
Subject: Re: [PATCH 1/2] Revert "UBIFS: Fix potential integer overflow in allocation"

On Sun, Jul 1, 2018 at 2:20 PM, Richard Weinberger <richard@....at> wrote:
> This reverts commit 353748a359f1821ee934afc579cf04572406b420.
> It bypassed the linux-mtd review process and fixes the issue not as it
> should.

Ah, sorry, I thought you were CCed on the original report.

> Cc: Kees Cook <keescook@...omium.org>
> Cc: Silvio Cesare <silvio.cesare@...il.com>
> Cc: stable@...r.kernel.org
> Signed-off-by: Richard Weinberger <richard@....at>
> ---
>  fs/ubifs/journal.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/fs/ubifs/journal.c b/fs/ubifs/journal.c
> index 07b4956e0425..da8afdfccaa6 100644
> --- a/fs/ubifs/journal.c
> +++ b/fs/ubifs/journal.c
> @@ -1282,11 +1282,10 @@ static int truncate_data_node(const struct ubifs_info *c, const struct inode *in
>                               int *new_len)
>  {
>         void *buf;
> -       int err, compr_type;
> -       u32 dlen, out_len, old_dlen;
> +       int err, dlen, compr_type, out_len, old_dlen;

What's wrong with making these unsigned?

>
>         out_len = le32_to_cpu(dn->size);
> -       buf = kmalloc_array(out_len, WORST_COMPR_FACTOR, GFP_NOFS);
> +       buf = kmalloc(out_len * WORST_COMPR_FACTOR, GFP_NOFS);
>         if (!buf)
>                 return -ENOMEM;

Please leave the kmalloc() -> kmalloc_array() change, as that has
happened treewide already. We don't want to have any multiplications
in the size argument for the allocators (i.e. they should use 2-factor
arg version like here, or use array_size() for things like vmalloc()).

Thanks!

-Kees

-- 
Kees Cook
Pixel Security