From: Prasad J Pandit <pjp@fedoraproject.org>
When cancelling pending DMA requests in ide_cancel_dma_sync,
the s->blk object could be null, leading to a null dereference.
Add check to avoid it.
Reported-by: Chensongnian <chensongnian@huawei.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
---
hw/ide/core.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 0b48b64..04474b3 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -681,8 +681,10 @@ void ide_cancel_dma_sync(IDEState *s)
#ifdef DEBUG_IDE
printf("%s: draining all remaining requests", __func__);
#endif
- blk_drain(s->blk);
- assert(s->bus->dma->aiocb == NULL);
+ if (s->blk) {
+ blk_drain(s->blk);
+ assert(s->bus->dma->aiocb == NULL);
+ }
}
}
--
2.9.4
On Fri, Jul 14, 2017 at 03:30:29PM +0530, P J P wrote: > From: Prasad J Pandit <pjp@fedoraproject.org> > > When cancelling pending DMA requests in ide_cancel_dma_sync, > the s->blk object could be null, leading to a null dereference. > Add check to avoid it. Please include details on how to reproduce the bug and/or which code path triggers this NULL dereference. > Reported-by: Chensongnian <chensongnian@huawei.com> > Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> > --- > hw/ide/core.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/hw/ide/core.c b/hw/ide/core.c > index 0b48b64..04474b3 100644 > --- a/hw/ide/core.c > +++ b/hw/ide/core.c > @@ -681,8 +681,10 @@ void ide_cancel_dma_sync(IDEState *s) > #ifdef DEBUG_IDE > printf("%s: draining all remaining requests", __func__); > #endif > - blk_drain(s->blk); > - assert(s->bus->dma->aiocb == NULL); > + if (s->blk) { > + blk_drain(s->blk); > + assert(s->bus->dma->aiocb == NULL); > + } > } > } > > -- > 2.9.4 > >
On Fri, Jul 14, 2017 at 7:00 AM, P J P <ppandit@redhat.com> wrote: > From: Prasad J Pandit <pjp@fedoraproject.org> > - blk_drain(s->blk); > - assert(s->bus->dma->aiocb == NULL); This assert looks weird > + if (s->blk) { > + blk_drain(s->blk); > + assert(s->bus->dma->aiocb == NULL); > + }
On 07/14/2017 06:00 AM, P J P wrote: > From: Prasad J Pandit <pjp@fedoraproject.org> > > When cancelling pending DMA requests in ide_cancel_dma_sync, > the s->blk object could be null, leading to a null dereference. > Add check to avoid it. > > Reported-by: Chensongnian <chensongnian@huawei.com> > Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> > --- > hw/ide/core.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/hw/ide/core.c b/hw/ide/core.c > index 0b48b64..04474b3 100644 > --- a/hw/ide/core.c > +++ b/hw/ide/core.c > @@ -681,8 +681,10 @@ void ide_cancel_dma_sync(IDEState *s) > #ifdef DEBUG_IDE > printf("%s: draining all remaining requests", __func__); > #endif > - blk_drain(s->blk); > - assert(s->bus->dma->aiocb == NULL); > + if (s->blk) { > + blk_drain(s->blk); > + assert(s->bus->dma->aiocb == NULL); > + } > } > } > > I guess this occurs through ide_exec_cmd cmd_device_reset ide_cancel_dma_sync though if s->blk does not exist, we should usually not be able to address this device with a reset command as such. (core.c:2021) -- but this is only for secondary devices. I guess we don't guard against nonexistent primary devices......? Further, how do we have s->bus->dma->aiocb if there's no blk device? What DMA request did we accept...? Can you please submit a stack that illustrates the code path followed so this fix can be properly verified and tested? Thanks, --John
© 2016 - 2024 Red Hat, Inc.