qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	qemu-devel@nongnu.org, alxndr@bu.edu
Subject: Re: [PATCH 0/4] esp: fix asserts/segfaults discovered by fuzzer
Date: Wed, 17 Mar 2021 08:59:48 +0100	[thread overview]
Message-ID: <d4b1bdcf-82e9-b921-9e28-d7a6a0ddf39a@redhat.com> (raw)
In-Reply-To: <20210316233024.13560-1-mark.cave-ayland@ilande.co.uk>

On 17/03/21 00:30, Mark Cave-Ayland wrote:
> Recently there have been a number of issues raised on Launchpad as a result of
> fuzzing the am53c974 (ESP) device. I spent some time over the past couple of
> days checking to see if anything had improved since my last patchset: from
> what I can tell the issues are still present, but the cmdfifo related failures
> now assert rather than corrupting memory.
> 
> This patchset applied to master passes my local tests using the qtest fuzz test
> cases added by Alexander for the following Launchpad bugs:
> 
>    https://bugs.launchpad.net/qemu/+bug/1919035
>    https://bugs.launchpad.net/qemu/+bug/1919036
>    https://bugs.launchpad.net/qemu/+bug/1910723
>    https://bugs.launchpad.net/qemu/+bug/1909247
>    
> I'm posting this now just before soft freeze since I see that some of the issues
> have recently been allocated CVEs and so it could be argued that even though
> they have existed for some time, it is worth fixing them for 6.0.
> 
> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>

They are certainly something that we can fix for 6.0.  However, please 
include the testcases even if they are ugly, they can be cleaned up 
later or (if never cleaned up) they still count as regression tests.

Paolo



      parent reply	other threads:[~2021-03-17  8:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-16 23:30 [PATCH 0/4] esp: fix asserts/segfaults discovered by fuzzer Mark Cave-Ayland
2021-03-16 23:30 ` [PATCH 1/4] esp: don't underflow cmdfifo if no message out/command data is present Mark Cave-Ayland
2021-03-17 15:14   ` Alexander Bulekov
2021-03-17 16:07     ` Alexander Bulekov
2021-03-17 15:37   ` Alexander Bulekov
2021-03-16 23:30 ` [PATCH 2/4] esp: don't overflow cmdfifo if TC is larger than the cmdfifo size Mark Cave-Ayland
2021-03-17  0:19   ` Philippe Mathieu-Daudé
2021-03-17 16:07   ` Alexander Bulekov
2021-03-16 23:30 ` [PATCH 3/4] esp: ensure cmdfifo is not empty and current_dev is non-NULL Mark Cave-Ayland
2021-03-17  0:18   ` Philippe Mathieu-Daudé
2021-03-17 15:47   ` Alexander Bulekov
2021-03-16 23:30 ` [PATCH 4/4] esp: always check current_req is not NULL before use in DMA callbacks Mark Cave-Ayland
2021-03-17  0:20 ` [PATCH 0/4] esp: fix asserts/segfaults discovered by fuzzer Philippe Mathieu-Daudé
2021-03-17  7:59 ` Paolo Bonzini [this message]

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=d4b1bdcf-82e9-b921-9e28-d7a6a0ddf39a@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=alxndr@bu.edu \
    --cc=mark.cave-ayland@ilande.co.uk \
    --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 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).