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:   Tue, 24 Jan 2023 11:45:53 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Tobias Schramm <t.schramm@...jaro.org>,
        Ludovic Desroches <ludovic.desroches@...rochip.com>
Cc:     Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Claudiu Beznea <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 Fri, 30 Dec 2022 at 20:43, Tobias Schramm <t.schramm@...jaro.org> wrote:
>
> 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>

This looks reasonable to me. I assume we should tag this for stable kernels too?

Moreover, I would like to get an ack from Ludovic before applying.

Kind regards
Uffe

> ---
>  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
>