qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Théo Maillart" <tmaillart@freebox.fr>
Cc: Fam Zheng <fam@euphon.net>, qemu-devel@nongnu.org
Subject: Re: [PATCH] scsi: check inquiry buffer length to prevent crash
Date: Thu, 11 May 2023 13:00:14 +0200	[thread overview]
Message-ID: <22a98a39-ab70-01f4-712a-3fd358d1af57@redhat.com> (raw)
In-Reply-To: <CANDNypxOsD_HLC1Ad_MrGqUizsHgDmBv+zH3yEU6X=BXfNRi=w@mail.gmail.com>

On 5/11/23 12:37, Théo Maillart wrote:
> On Wed, May 10, 2023 at 6:11 PM Paolo Bonzini <pbonzini@redhat.com 
> <mailto:pbonzini@redhat.com>> wrote:
> 
>     On 4/26/23 15:37, Théo Maillart wrote:
>      > --- a/hw/scsi/scsi-generic.c
>      > +++ b/hw/scsi/scsi-generic.c
>      > @@ -191,7 +191,7 @@ static int
>     scsi_handle_inquiry_reply(SCSIGenericReq *r, SCSIDevice *s, int len)
>      >       if ((s->type == TYPE_DISK || s->type == TYPE_ZBC) &&
>      >           (r->req.cmd.buf[1] & 0x01)) {
>      >           page = r->req.cmd.buf[2];
>      > -        if (page == 0xb0) {
>      > +        if (page == 0xb0 && r->buflen >= 12) {
>      >               uint64_t max_transfer = calculate_max_transfer(s);
>      >               stl_be_p(&r->buf[8], max_transfer);
>      >               /* Also take care of the opt xfer len. */
>      > --
> 
>     This is not enough because right below there is a store of bytes 12..15.
> 
> 
> I agree with you, I was wrong, the test should be r->buflen >= 16

This would let the guest see the wrong maximum transfer length, if it 
uses a buffer length of 12.

>     The best thing to do is to:
> 
>     1) do the stores in an "uint8_t buf[8]" on the stack, followed by a
>     memcpy to r->buf + 8.
> 
>     2) add "&& r->buflen > 8" to the condition similar to what you've done
>     above.
> 
> 
> But I don't think this suggestion is necessary, it would basically do
>  the same thing that is done in the current version adding an extra
> memcpy on the stack.

The memcpy can be limited to the actual size of the buffer, i.e. 
memcpy(r->buf + 8, buf, r->buflen - 8).

In fact you need to memcpy both before and after, so that the ldl_be_p 
is done on a large-enough buffer.

> In my opinion the only problem highlighted by this crash is that of 
> writing byte 8 to 15 while the buffer size is 4.
Right, but the bytes that _can_ be written should not change before and 
after the patch.

Paolo



  reply	other threads:[~2023-05-11 11:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-26 13:37 [PATCH] scsi: check inquiry buffer length to prevent crash Théo Maillart
2023-04-26 17:13 ` Théo Maillart
2023-05-10  7:28   ` Théo Maillart
2023-05-10 16:11 ` Paolo Bonzini
2023-05-11 10:37   ` Théo Maillart
2023-05-11 11:00     ` Paolo Bonzini [this message]
2023-05-11 19:58       ` Théo Maillart

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=22a98a39-ab70-01f4-712a-3fd358d1af57@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=fam@euphon.net \
    --cc=qemu-devel@nongnu.org \
    --cc=tmaillart@freebox.fr \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).