All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: "Alexander Bulekov" <alxndr@bu.edu>,
	"Prasad J Pandit" <pjp@fedoraproject.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	Qemu-block <qemu-block@nongnu.org>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>
Subject: Re: [PATCH v3 03/11] hw/sd/sdcard: Do not switch to ReceivingData if address is invalid
Date: Mon, 15 Jun 2020 15:06:17 +0100	[thread overview]
Message-ID: <CAFEAcA-6Vv5Q31Z0bsXPpWanEj8Z0gBeZFWTCrQF3W8RuaQiMQ@mail.gmail.com> (raw)
In-Reply-To: <20200605102230.21493-4-philmd@redhat.com>

On Fri, 5 Jun 2020 at 11:25, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>
> From: Philippe Mathieu-Daudé <f4bug@amsat.org>
>
> Only move the state machine to ReceivingData if there is no
> pending error.  This avoids later OOB access while processing
> commands queued.
>
>   "SD Specifications Part 1 Physical Layer Simplified Spec. v3.01"
>
>   4.3.3 Data Read
>
>   Read command is rejected if BLOCK_LEN_ERROR or ADDRESS_ERROR
>   occurred and no data transfer is performed.
>
>   4.3.4 Data Write
>
>   Write command is rejected if BLOCK_LEN_ERROR or ADDRESS_ERROR
>   occurred and no data transfer is performed.

It's not clear from the spec that this should also
apply to WP_VIOLATION errors. The text about WP_VIOLATION
suggests that it is handled by aborting the data transfer
(ie set the error bit, stay in receive-data state, wait for
a stop command, but ignore all further data transfer),
which is I think distinct from "rejecting" the command.

If that theory is right then moving the check for the
ADDRESS_ERROR in this patch is correct but the WP_VIOLATION
tests should stay as they are, I think.

NB: is the buffer overrun we're trying to protect against
caused by passing sd_wp_addr() a bad address? Maybe we
should assert in sd_addr_to_wpnum() that the address is
in range, as a defence.

thanks
-- PMM


  reply	other threads:[~2020-06-15 14:07 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-05 10:22 [PATCH v3 00/11] hw/sd/sdcard: Fix CVE-2020-13253 & cleanups Philippe Mathieu-Daudé
2020-06-05 10:22 ` [PATCH v3 01/11] MAINTAINERS: Cc qemu-block mailing list Philippe Mathieu-Daudé
2020-06-05 10:22 ` [PATCH v3 02/11] hw/sd/sdcard: Update coding style to make checkpatch.pl happy Philippe Mathieu-Daudé
2020-06-15 13:30   ` Peter Maydell
2020-06-05 10:22 ` [PATCH v3 03/11] hw/sd/sdcard: Do not switch to ReceivingData if address is invalid Philippe Mathieu-Daudé
2020-06-15 14:06   ` Peter Maydell [this message]
2020-07-13 16:36     ` Philippe Mathieu-Daudé
2020-07-13 16:49       ` Philippe Mathieu-Daudé
2020-06-05 10:22 ` [PATCH v3 04/11] hw/sd/sdcard: Restrict Class 6 commands to SCSD cards Philippe Mathieu-Daudé
2020-06-15 13:28   ` Peter Maydell
2020-06-05 10:22 ` [PATCH v3 05/11] hw/sd/sdcard: Update the SDState documentation Philippe Mathieu-Daudé
2020-06-15 14:07   ` Peter Maydell
2020-06-05 10:22 ` [PATCH v3 06/11] hw/sd/sdcard: Simplify cmd_valid_while_locked() Philippe Mathieu-Daudé
2020-06-15 14:08   ` Peter Maydell
2020-06-05 10:22 ` [PATCH v3 07/11] hw/sd/sdcard: Constify sd_crc*()'s message argument Philippe Mathieu-Daudé
2020-06-05 10:22 ` [PATCH v3 08/11] hw/sd/sdcard: Make iolen unsigned Philippe Mathieu-Daudé
2020-06-15 14:13   ` Peter Maydell
2020-06-05 10:22 ` [PATCH v3 09/11] hw/sd/sdcard: Correctly display the command name in trace events Philippe Mathieu-Daudé
2020-06-15 14:20   ` Peter Maydell
2020-06-05 10:22 ` [PATCH v3 10/11] hw/sd/sdcard: Display offset in read/write_data() " Philippe Mathieu-Daudé
2020-06-15 14:21   ` Peter Maydell
2020-06-05 10:22 ` [PATCH v3 11/11] hw/sd/sdcard: Simplify realize() a bit Philippe Mathieu-Daudé
2020-06-15 14:24   ` Peter Maydell
2020-06-08 17:48 ` [PATCH v3 00/11] hw/sd/sdcard: Fix CVE-2020-13253 & cleanups Philippe Mathieu-Daudé
2020-07-06 16:31   ` Alistair Francis
2020-07-06 18:01     ` Philippe Mathieu-Daudé
2020-06-15  7:33 ` Philippe Mathieu-Daudé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFEAcA-6Vv5Q31Z0bsXPpWanEj8Z0gBeZFWTCrQF3W8RuaQiMQ@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=alxndr@bu.edu \
    --cc=f4bug@amsat.org \
    --cc=philmd@redhat.com \
    --cc=pjp@fedoraproject.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.