linux-kernel - Re: [PATCH 1/1] mmc: atmel-mci: fix race between stop command and start of next command

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, 26 Jan 2023 14:43:59 +0000
From:   <Ludovic.Desroches@...rochip.com>
To:     <t.schramm@...jaro.org>
CC:     <ulf.hansson@...aro.org>, <Nicolas.Ferre@...rochip.com>,
        <alexandre.belloni@...tlin.com>, <Claudiu.Beznea@...rochip.com>,
        <linux-mmc@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] mmc: atmel-mci: fix race between stop command and
 start of next command

On 30/12/2022 20:43, Tobias Schramm wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> This commit fixes a race between completion of stop command and start of a
> new command.
> Previously the command ready interrupt was enabled before stop command
> was written to the command register. This caused the command ready
> interrupt to fire immediately since the CMDRDY flag is asserted constantly
> while there is no command in progress.
> Consequently the command state machine will immediately advance to the
> next state when the tasklet function is executed again, no matter
> actual completion state of the stop command.
> Thus a new command can then be dispatched immediately, interrupting and
> corrupting the stop command on the CMD line.
> Fix that by dropping the command ready interrupt enable before calling
> atmci_send_stop_cmd. atmci_send_stop_cmd does already enable the
> command ready interrupt, no further writes to ATMCI_IER are necessary.
> 
> Signed-off-by: Tobias Schramm <t.schramm@...jaro.org>

Hi,

In theory this changes make sense. I'm always afraid when something is 
changed in this driver which handles many version of the IP...

As we never encountered this issue until now, I can't really test this 
fix. I checked on an old board at91sam9m10g45-ek that mmc is still 
working and it's okay.

So
Acked-by: Ludovic Desroches <ludovic.desroches@...rochip.com>

Regards,
Ludovic

> ---
>   drivers/mmc/host/atmel-mci.c | 3 ---
>   1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
> index bb9bbf1c927b..dd18440a90c5 100644
> --- a/drivers/mmc/host/atmel-mci.c
> +++ b/drivers/mmc/host/atmel-mci.c
> @@ -1817,7 +1817,6 @@ static void atmci_tasklet_func(struct tasklet_struct *t)
>                                  atmci_writel(host, ATMCI_IER, ATMCI_NOTBUSY);
>                                  state = STATE_WAITING_NOTBUSY;
>                          } else if (host->mrq->stop) {
> -                               atmci_writel(host, ATMCI_IER, ATMCI_CMDRDY);
>                                  atmci_send_stop_cmd(host, data);
>                                  state = STATE_SENDING_STOP;
>                          } else {
> @@ -1850,8 +1849,6 @@ static void atmci_tasklet_func(struct tasklet_struct *t)
>                                   * command to send.
>                                   */
>                                  if (host->mrq->stop) {
> -                                       atmci_writel(host, ATMCI_IER,
> -                                                    ATMCI_CMDRDY);
>                                          atmci_send_stop_cmd(host, data);
>                                          state = STATE_SENDING_STOP;
>                                  } else {
> --
> 2.30.2
>