linux-kernel - Re: [PATCH 1/3] memstick/ms_block: Fix some incorrect memory 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]

Date:   Tue, 12 Jul 2022 13:08:50 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Christophe JAILLET <christophe.jaillet@...adoo.fr>
Cc:     Maxim Levitsky <maximlevitsky@...il.com>,
        Alex Dubov <oakad@...oo.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
        linux-mmc@...r.kernel.org
Subject: Re: [PATCH 1/3] memstick/ms_block: Fix some incorrect memory allocation

On Sat, 25 Jun 2022 at 14:55, Christophe JAILLET
<christophe.jaillet@...adoo.fr> wrote:
>
> Some functions of the bitmap API take advantage of the fact that a bitmap
> is an array of long.
>
> So, to make sure this assertion is correct, allocate bitmaps with
> bitmap_zalloc() instead of kzalloc()+hand-computed number of bytes.
>
> While at it, also use bitmap_free() instead of kfree() to keep the
> semantic.
>
> Fixes: 0ab30494bc4f ("memstick: add support for legacy memorysticks")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@...adoo.fr>

Applied for next, thanks!

Kind regards
Uffe


> ---
> I guess that it is not an issue in RL because memory allocation is
> certainly "rounding" to keep memory alignment.
> ---
>  drivers/memstick/core/ms_block.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/memstick/core/ms_block.c b/drivers/memstick/core/ms_block.c
> index 3993bdd4b519..f8f151163667 100644
> --- a/drivers/memstick/core/ms_block.c
> +++ b/drivers/memstick/core/ms_block.c
> @@ -1341,17 +1341,17 @@ static int msb_ftl_initialize(struct msb_data *msb)
>         msb->zone_count = msb->block_count / MS_BLOCKS_IN_ZONE;
>         msb->logical_block_count = msb->zone_count * 496 - 2;
>
> -       msb->used_blocks_bitmap = kzalloc(msb->block_count / 8, GFP_KERNEL);
> -       msb->erased_blocks_bitmap = kzalloc(msb->block_count / 8, GFP_KERNEL);
> +       msb->used_blocks_bitmap = bitmap_zalloc(msb->block_count, GFP_KERNEL);
> +       msb->erased_blocks_bitmap = bitmap_zalloc(msb->block_count, GFP_KERNEL);
>         msb->lba_to_pba_table =
>                 kmalloc_array(msb->logical_block_count, sizeof(u16),
>                               GFP_KERNEL);
>
>         if (!msb->used_blocks_bitmap || !msb->lba_to_pba_table ||
>                                                 !msb->erased_blocks_bitmap) {
> -               kfree(msb->used_blocks_bitmap);
> +               bitmap_free(msb->used_blocks_bitmap);
> +               bitmap_free(msb->erased_blocks_bitmap);
>                 kfree(msb->lba_to_pba_table);
> -               kfree(msb->erased_blocks_bitmap);
>                 return -ENOMEM;
>         }
>
> @@ -1946,7 +1946,7 @@ static DEFINE_MUTEX(msb_disk_lock); /* protects against races in open/release */
>  static void msb_data_clear(struct msb_data *msb)
>  {
>         kfree(msb->boot_page);
> -       kfree(msb->used_blocks_bitmap);
> +       bitmap_free(msb->used_blocks_bitmap);
>         kfree(msb->lba_to_pba_table);
>         kfree(msb->cache);
>         msb->card = NULL;
> --
> 2.34.1
>