[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Segfault in hw/scsi/scsi-disk.c caused by null pointer

From: Denis Krienbühl
Subject: Re: Segfault in hw/scsi/scsi-disk.c caused by null pointer
Date: Fri, 12 Aug 2022 17:26:13 +0200

I see, thanks for pointing me in the direction of those commits.

I figured a new version would not have the same issue, so we’ll upgrade.

Cheers, Denis

> On 12 Aug 2022, at 17:11, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 8/12/22 16:50, Peter Maydell wrote:
>> As I said previously, this is still absolutely wrong.
>> If we ever get to this function with either of these
>> fields being NULL then there has been a serious problem,
>> probably a memory corruption or use-after-free, or
>> possibly an attempt to use a partially constructed object.
> Yeah, this would still be a use-after-free.  s->version is never
> written (see for example release_string in hw/core/qdev-properties.c)
> so it means that the storage for "s" has been reused.
> The bug has been fixed in version 5.2 of QEMU with the following commit:
> 7a8202c521 scsi/scsi_bus: switch search direction in scsi_device_find
> 7bed89958b device_core: use drain_call_rcu in in qmp_device_add
> 2d24a64661 device-core: use RCU for list of children of a bus
> 42a90a899e scsi: switch to bus->check_address
> a23151e8cc device-core: use atomic_set on .realized property
> 8ddf958e8d scsi/scsi-bus: scsi_device_find: don't return unrealized devices
> 8ff3449560 scsi/scsi_bus: Add scsi_device_get
> 07a47d4a18 virtio-scsi: use scsi_device_get
> 8cfe8013ba scsi/scsi_bus: fix races in REPORT LUNS
> Feel free to pass this information to Canonical so that they can fix
> their old version of QEMU.
> Paolo

reply via email to

[Prev in Thread] Current Thread [Next in Thread]