linux-kernel - Re: [PATCH v8 5/9] dm: Remove VLA usage from hashes

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: <20180913175439.GA5414@redhat.com>
Date:   Thu, 13 Sep 2018 13:54:39 -0400
From:   Mike Snitzer <snitzer@...hat.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     Herbert Xu <herbert@...dor.apana.org.au>,
        Eric Biggers <ebiggers@...gle.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Giovanni Cabiddu <giovanni.cabiddu@...el.com>,
        Alasdair Kergon <agk@...hat.com>,
        Tudor-Dan Ambarus <tudor.ambarus@...rochip.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Arnd Bergmann <arnd@...db.de>,
        Will Deacon <will.deacon@....com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Matthew Wilcox <willy@...radead.org>,
        "David S. Miller" <davem@...emloft.net>,
        "Gustavo A. R. Silva" <gustavo@...eddedor.com>,
        linux-crypto@...r.kernel.org, dm-devel@...hat.com,
        qat-linux@...el.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 5/9] dm: Remove VLA usage from hashes

On Tue, Aug 07 2018 at  5:18pm -0400,
Kees Cook <keescook@...omium.org> wrote:

> In the quest to remove all stack VLA usage from the kernel[1], this uses
> the new HASH_MAX_DIGESTSIZE from the crypto layer to allocate the upper
> bounds on stack usage.
> 
> [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
> 
> Signed-off-by: Kees Cook <keescook@...omium.org>
> ---
>  drivers/md/dm-integrity.c  | 23 +++++++++++++++++------
>  drivers/md/dm-verity-fec.c |  5 ++++-
>  2 files changed, 21 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c
> index 86438b2f10dd..884edd7cf1d0 100644
> --- a/drivers/md/dm-integrity.c
> +++ b/drivers/md/dm-integrity.c
> @@ -521,7 +521,12 @@ static void section_mac(struct dm_integrity_c *ic, unsigned section, __u8 result
>  		}
>  		memset(result + size, 0, JOURNAL_MAC_SIZE - size);
>  	} else {
> -		__u8 digest[size];
> +		__u8 digest[HASH_MAX_DIGESTSIZE];
> +
> +		if (WARN_ON(size > sizeof(digest))) {
> +			dm_integrity_io_error(ic, "digest_size", -EINVAL);
> +			goto err;
> +		}
>  		r = crypto_shash_final(desc, digest);
>  		if (unlikely(r)) {
>  			dm_integrity_io_error(ic, "crypto_shash_final", r);
> @@ -1244,7 +1249,7 @@ static void integrity_metadata(struct work_struct *w)
>  		struct bio *bio = dm_bio_from_per_bio_data(dio, sizeof(struct dm_integrity_io));
>  		char *checksums;
>  		unsigned extra_space = unlikely(digest_size > ic->tag_size) ? digest_size - ic->tag_size : 0;
> -		char checksums_onstack[ic->tag_size + extra_space];
> +		char checksums_onstack[HASH_MAX_DIGESTSIZE];
>  		unsigned sectors_to_process = dio->range.n_sectors;
>  		sector_t sector = dio->range.logical_sector;
>  
> @@ -1253,8 +1258,14 @@ static void integrity_metadata(struct work_struct *w)
>  
>  		checksums = kmalloc((PAGE_SIZE >> SECTOR_SHIFT >> ic->sb->log2_sectors_per_block) * ic->tag_size + extra_space,
>  				    GFP_NOIO | __GFP_NORETRY | __GFP_NOWARN);
> -		if (!checksums)
> +		if (!checksums) {
>  			checksums = checksums_onstack;
> +			if (WARN_ON(extra_space &&
> +				    digest_size > sizeof(checksums_onstack))) {
> +				r = -EINVAL;
> +				goto error;
> +			}
> +		}
>  
>  		__bio_for_each_segment(bv, bio, iter, dio->orig_bi_iter) {
>  			unsigned pos;

Given the length of the kmalloc() just prior to this new WARN_ON() line
I'm not seeing why you've elected to split the WARN_ON across multiple
lines.

But that style nit aside:

Acked-by: Mike Snitzer <snitzer@...hat.com>