[Qemu-devel] [PATCH] ide: check BlockBackend object in ide_cancel_dma_sync

[Qemu-devel] [PATCH] ide: check BlockBackend object in ide_cancel_dma_sync

[P J P]

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

Re: [Qemu-devel] [PATCH] ide: check BlockBackend object in ide_cancel_dma_sync

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

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
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [Qemu-devel] [PATCH] ide: check BlockBackend object in ide_cancel_dma_sync

[Philippe Mathieu-Daudé]

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);
> +        }

Re: [Qemu-devel] [PATCH] ide: check BlockBackend object in ide_cancel_dma_sync

[John Snow]

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