A NULL pointer dereference issue was found in the SCSI emulation support of QEMU. It could occur in the scsi_req_continue() function in hw/scsi/scsi-bus.c while handling the 'Information Transfer' command (CMD_TI) of the am53c974 SCSI host bus adapter. A privileged guest user may abuse this issue to crash the QEMU process on the host, resulting in a denial of service condition.
Acknowledgments: Name: Cheolwoo Myung
Created qemu tracking bugs for this issue: Affects: fedora-all [bug 1909772] Created xen tracking bugs for this issue: Affects: fedora-all [bug 1909773]
In reply to comment #0: > It could occur in the scsi_req_continue() function in > hw/scsi/scsi-bus.c while handling the 'Information Transfer' command > (CMD_TI) of the am53c974 SCSI host bus adapter. More specifically, scsi_req_continue() accepts a 'req' pointer to SCSIRequest which is immediately used to access the 'req->io_canceled' field without any validation. The caller is responsible for passing a valid pointer to scsi_req_continue(). This is not the case for esp_do_dma() in hw/scsi/esp.c which may call scsi_req_continue() with a NULL argument, leading to subsequent NULL pointer dereference.
Statement: This issue does not affect Red Hat Enterprise Linux, Red Hat OpenStack Platform and RHEL Advanced Virtualization, as the `qemu-kvm` package does not include support for the am53c974 SCSI controller emulation.
Please refer to the following upstream bug for how to reproduce this issue: https://bugs.launchpad.net/qemu/+bug/1910723
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-35504
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=0db895361b8a82e1114372ff9f4857abea605701 https://git.qemu.org/?p=qemu.git;a=commit;h=e392255766071c8cac480da3a9ae4f94e56d7cbc https://git.qemu.org/?p=qemu.git;a=commit;h=e5455b8c1c6170c788f3c0fd577cc3be53539a99 https://git.qemu.org/?p=qemu.git;a=commit;h=c5fef9112b15c4b5494791cdf8bbb40bc1938dd3 https://git.qemu.org/?p=qemu.git;a=commit;h=7b320a8e67a534925048cbabfa51431e0349dafd https://git.qemu.org/?p=qemu.git;a=commit;h=99545751734035b76bd372c4e7215bb337428d89 https://git.qemu.org/?p=qemu.git;a=commit;h=fa7505c154d4d00ad89a747be2eda556643ce00e https://git.qemu.org/?p=qemu.git;a=commit;h=fbc6510e3379fa8f8370bf71198f0ce733bf07f9 https://git.qemu.org/?p=qemu.git;a=commit;h=0ebb5fd80589835153a0c2baa1b8cc7a04e67a93 https://git.qemu.org/?p=qemu.git;a=commit;h=324c8809897c8c53ad05c3a7147d272f1711cd5e https://git.qemu.org/?p=qemu.git;a=commit;h=607206948cacda4a80be5b976dba490970a18a76
It is strongly recommended to apply all the commits listed above, to fix the numerous issues that were addressed in the patchset alongside this CVE. That being said, the specific commit strictly needed for this CVE should be the following one: https://git.qemu.org/?p=qemu.git;a=commit;h=0db895361b8a82e1114372ff9f4857abea605701
External References: https://www.openwall.com/lists/oss-security/2021/04/16/3