linux-kernel - Re: [patch V2 7/8] dm verity fec: Check result of init

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]

Date:   Thu, 19 Apr 2018 09:46:47 -0400
From:   Mike Snitzer <snitzer@...hat.com>
To:     Thomas Gleixner <tglx@...utronix.de>, NeilBrown <neilb@...e.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        Segher Boessenkool <segher@...nel.crashing.org>,
        Kernel Hardening <kernel-hardening@...ts.openwall.com>,
        Andrew Morton <akpm@...uxfoundation.org>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Richard Weinberger <richard@....at>,
        David Woodhouse <dwmw2@...radead.org>,
        Alasdair Kergon <agk@...hat.com>,
        Anton Vorontsov <anton@...msg.org>,
        Colin Cross <ccross@...roid.com>,
        Tony Luck <tony.luck@...el.com>
Subject: Re: [patch V2 7/8] dm verity fec: Check result of init_rs()

On Thu, Apr 19 2018 at  6:04am -0400,
Thomas Gleixner <tglx@...utronix.de> wrote:

> From: Thomas Gleixner <tglx@...utronix.de>
> 
> The allocation of the reed solomon control structure can fail, but
> fec_alloc_bufs() ignores that and subsequent operations in dm verity use
> the potential NULL pointer unconditionally.
> 
> Add a proper check and abort if init_rs() fails.

This changelog makes little sense: init_rs() isn't in play relative to
this patch.

And it runs counter to this commit's changelog:

commit 34c96507e8f6be497c15497be05f489fb34c5880
Author: NeilBrown <neilb@...e.com>
Date:   Mon Apr 10 12:13:00 2017 +1000

    dm verity fec: fix GFP flags used with mempool_alloc()

    mempool_alloc() cannot fail for GFP_NOIO allocation, so there is no
    point testing for failure.

    One place the code tested for failure was passing "0" as the GFP
    flags.  This is most unusual and is probably meant to be GFP_NOIO,
    so that is changed.

    Also, allocation from ->extra_pool and ->prealloc_pool are repeated
    before releasing the previous allocation.  This can deadlock if the code
    is servicing a write under high memory pressure.  To avoid deadlocks,
    change these to use GFP_NOWAIT and leave the error handling in place.

    Signed-off-by: NeilBrown <neilb@...e.com>
    Signed-off-by: Mike Snitzer <snitzer@...hat.com>

Seems there is no real need for this patch.  Neil, what do you think?

Thanks,
Mike


> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> Cc: Boris Brezillon <boris.brezillon@...e-electrons.com>
> Cc: Tony Luck <tony.luck@...el.com>
> Cc: Kees Cook <keescook@...omium.org>
> Cc: Segher Boessenkool <segher@...nel.crashing.org>
> Cc: Kernel Hardening <kernel-hardening@...ts.openwall.com>
> Cc: Richard Weinberger <richard@....at>
> Cc: Mike Snitzer <snitzer@...hat.com>
> Cc: Anton Vorontsov <anton@...msg.org>
> Cc: Colin Cross <ccross@...roid.com>
> Cc: Andrew Morton <akpm@...uxfoundation.org>
> Cc: David Woodhouse <dwmw2@...radead.org>
> Cc: Alasdair Kergon <agk@...hat.com>
> 
> ---
>  drivers/md/dm-verity-fec.c |    7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> --- a/drivers/md/dm-verity-fec.c
> +++ b/drivers/md/dm-verity-fec.c
> @@ -308,8 +308,13 @@ static int fec_alloc_bufs(struct dm_veri
>  {
>  	unsigned n;
>  
> -	if (!fio->rs)
> +	if (!fio->rs) {
>  		fio->rs = mempool_alloc(v->fec->rs_pool, GFP_NOIO);
> +		if (!fio->rs) {
> +			DMERR("failed to allocate RS control structure");
> +			return -ENOMEM;
> +		}
> +	}
>  
>  	fec_for_each_prealloc_buffer(n) {
>  		if (fio->bufs[n])
> 
> 
> 
> 
>