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

Date:   Fri, 27 Jan 2023 11:57:00 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Ludovic.Desroches@...rochip.com, t.schramm@...jaro.org
Cc:     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 Thu, 26 Jan 2023 at 15:44, <Ludovic.Desroches@...rochip.com> wrote:
>
> 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

Thanks for your ack and thoughts!

It's not clear to me whether the problem is hypothetical or in fact a
real problem. Tobias can you help to fill in here?

Nevertheless I have applied this for next, to allow more testing to be
done. In the meantime, we can discuss whether we should add a stable
tag or leave that to later as manual backports.

[...]

Kind regards
Uffe