On Thu, Mar 26, 2020 at 01:50:41PM +0100, Igor Mammedov wrote: > On Thu, 26 Mar 2020 13:29:01 +0100 > Igor Mammedov <imamm...@redhat.com> wrote: > > > On Thu, 26 Mar 2020 11:52:36 +0000 > > Peter Maydell <peter.mayd...@linaro.org> wrote: > > > > > Hi; Coverity spots that if hw/acpi/pcihp.c:acpi_pcihp_eject_slot() > > > is passed a zero 'slots' argument then ctz32(slots) will return 32, > > > and then the code that does '1U << slot' is C undefined behaviour > > > because it's an oversized shift. (This is CID 1421896.) > > > > > > Since the pci_write() function in this file can call > > > acpi_pcihp_eject_slot() with an arbitrary value from the guest, > > > I think we need to handle 'slots == 0' safely. But what should > > > the behaviour be? > > > > 0 is not valid value, we should ignore and return early in this case > > like we do with bsel. I'll post a path shortly. > well, looking more that is only true for main bus, for bridges it can be > slot number can be zero,
It can but we don't allow slot zero hotplug with SHPC so it's easier if we don't allow this with ACPI either. > then AML left shifts it and writes into B0EJ > which traps into pci_write(, data) and that is supposed to eject > slot 0 according to guest(AML). > > Michael, > what's your take on it? > > > > > > > > > thanks > > > -- PMM > > > > > > >
