** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1909247
Title:
QEMU: use after free vulnerability in esp_do_dma() in hw/scsi/esp.c
** Changed in: qemu
Status: Fix Released => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1909247
Title:
QEMU: use after free vulnerability in esp_do_dma() in hw/scsi/esp.c
This is fixed now, thank you Mark.
Patchset v4:
https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg01000.html
Upstream commits:
https://git.qemu.org/?p=qemu.git;a=commit;h=0db895361b8a82e1114372ff9f48
https://git.qemu.org/?p=qemu.git;a=commit;h=e392255766071c8cac480da3a9ae
Thanks again Alex. I've just posted a v3 to the list which fixes your
extra test cases, and also those contained within the uaf and hw-esp-oob
attachments:
https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg00015.html
--
You received this bug notification because you are a member of qemu-
If Alex is interested in having a fuzz-proof device as a starting point
for fuzzing QEMU's SCSI layer then I don't mind doing the basic work as
I've spent a few months deep in the internals of the ESP controller, and
it makes sense to look at this whilst it is all still fresh. I'd say
there's at
On 3/24/21 4:53 PM, Alexander Bulekov wrote:
> Hi,
> I can still trigger stack-overflows, heap-UAFs and heap-overflows in the
> code, but Mark's patches fixed some of the issues. I didn't want to
> flood the issue-tracker with further problems in this code, since it
> isn't clear what the security
Hi,
I can still trigger stack-overflows, heap-UAFs and heap-overflows in the
code, but Mark's patches fixed some of the issues. I didn't want to
flood the issue-tracker with further problems in this code, since it
isn't clear what the security expectations are for this device. Of
course it is only
Hello,
Thank you all for your comments. Both patches (PJP/comment#8 -
Mark/comment#9) seem to properly fix the UAF reported by Alexander in
comment #6. However, I'm still able to reproduce the heap-bof from the
above hw-esp-oob-issues.zip:
./x86_64-softmmu/qemu-system-x86_64 -m 512 \
-drive
Can you confirm that this is fixed in the v2 of the above patchset?
https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg06550.html
ATB,
Mark.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
On Wednesday, 17 March, 2021, 10:26:36 pm IST, Cheolwoo Myung
wrote:
> Hello PJP, Mauro
>
> Of course. you can post the details with our reproducers.
> I'm glad it helped you.
>
> Thank you.
> - Cheolwoo Myung
>
2021년 3월 17일 (수) 오후 10:30, P J P 님이 작성:
>
>On Monday, 15 March, 2021, 07:54:30
Thank you both for the reproducers. Please see the proposed patchset
here:
https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg06063.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1909247
Hi Mauro,
Oops... I missed that it was a stack-overflow. I went through my list of
crashes, and the closest one I can find is a heap UAF, but it is a write,
rather than a read:
/*
* Autogenerated Fuzzer Test Case
*
* Copyright (c) 2021
*
* This work is licensed under the terms of the GNU
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-35506
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1909247
Title:
QEMU: use after free vulnerability in esp_do_dma() in
Note that the use-after-free was found in v5.2.0 and, as far as I can
tell, is not reproducible anymore on master. The ESP/NCR53C9x emulator
(hw/scsi/esp.c) underwent several changes since v5.2.0. By git-
bisecting, it looks like the original reproducer is neutralized after
commit [1]. However,
Technically, the first one is a heap use-after-free, while the second a
stack buffer overflow. They could be two different manifestations of the
same issue; they both originate from handle_ti() and the root cause may
be the same.
Heap uaf:
Looks the same, or very similar to this one:
/*
* Autogenerated Fuzzer Test Case
*
* This work is licensed under the terms of the GNU GPL, version 2 or
* later. See the COPYING file in the top-level directory.
*/
#include "qemu/osdep.h"
#include "libqos/libqtest.h"
/*
* cat << EOF |
** Tags added: fuzzer
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1909247
Title:
QEMU: use after free vulnerability in esp_do_dma() in hw/scsi/esp.c
Status in QEMU:
New
Bug description:
A
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1909996
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1909247
Title:
QEMU: use after free vulnerability in esp_do_dma() in hw/scsi/esp.c
Status
18 matches
Mail list logo
