linux-kernel - Re: [PATCH v4 1/1] test_firmware: fix some memory leaks and racing conditions

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] [day] [month] [year] [list]

Date:   Fri, 21 Apr 2023 17:08:33 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Mirsad Goran Todorovac <mirsad.todorovac@....unizg.hr>
Cc:     Luis Chamberlain <mcgrof@...nel.org>,
        Russ Weight <russell.h.weight@...el.com>,
        linux-kernel@...r.kernel.org,
        Tianfei zhang <tianfei.zhang@...el.com>,
        Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        Zhengchao Shao <shaozhengchao@...wei.com>,
        Colin Ian King <colin.i.king@...il.com>,
        Takashi Iwai <tiwai@...e.de>,
        Kees Cook <keescook@...omium.org>,
        Scott Branden <sbranden@...adcom.com>,
        Dan Carpenter <error27@...il.com>
Subject: Re: [PATCH v4 1/1] test_firmware: fix some memory leaks and racing
 conditions

On Fri, Apr 21, 2023 at 04:57:01PM +0200, Mirsad Goran Todorovac wrote:
> Some functions were called both from locked and unlocked context, so
> the lock was dropped prematurely, introducing a race condition when
> deadlock was avoided.
> 
> Having two locks wouldn't assure a race-proof mutual exclusion.
> 
> __test_dev_config_update_bool(), __test_dev_config_update_u8() and
> __test_dev_config_update_size_t() unlocked versions of the functions
> were introduced to be called from the locked contexts as a workaround
> without releasing the main driver's lock and causing a race condition.
> 
> This should guarantee mutual exclusion and prevent any race conditions.
> 
> Locked versions simply allow for mutual exclusion and call the unlocked
> counterparts, to avoid duplication of code.
> 
> trigger_batched_requests_store() and trigger_batched_requests_async_store()
> now return -EBUSY if called with test_fw_config->reqs already allocated,
> so the memory leak is prevented.
> 
> The same functions now keep track of the allocated buf for firmware in
> req->fw_buf as release_firmware() will not deallocate this storage for us.
> 
> Additionally, in __test_release_all_firmware(), req->fw_buf is released
> before calling release_firmware(reqs->fw) foreach test_fw_config->regs[i].
> 
> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org> 
> Cc: Luis Chamberlain <mcgrof@...nel.org> 
> Cc: Russ Weight <russell.h.weight@...el.com> 
> Cc: Tianfei zhang <tianfei.zhang@...el.com> 
> Cc: Christophe JAILLET <christophe.jaillet@...adoo.fr> 
> Cc: Zhengchao Shao <shaozhengchao@...wei.com> 
> Cc: Colin Ian King <colin.i.king@...il.com> 
> Cc: linux-kernel@...r.kernel.org 
> Cc: Takashi Iwai <tiwai@...e.de>
> Cc: Kees Cook <keescook@...omium.org>
> Cc: Scott Branden <sbranden@...adcom.com>
> Cc: Luis R. Rodriguez <mcgrof@...nel.org>
> Suggested-by: Dan Carpenter <error27@...il.com>
> Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac@....unizg.hr>
> ---
>  lib/test_firmware.c | 81 +++++++++++++++++++++++++++++++++++----------
>  1 file changed, 63 insertions(+), 18 deletions(-)
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- This looks like a new version of a previously submitted patch, but you
  did not list below the --- line any changes from the previous version.
  Please read the section entitled "The canonical patch format" in the
  kernel file, Documentation/process/submitting-patches.rst for what
  needs to be done here to properly describe this.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot