[for-4.0] migration/ram.c: Fix use-after-free in multifd_recv_unfill_packet()

Coverity points out (CID 1400442) that in this code:

    if (packet->pages_alloc > p->pages->allocated) {
        multifd_pages_clear(p->pages);
        multifd_pages_init(packet->pages_alloc);
    }

we free p->pages in multifd_pages_clear() but continue to
use it in the following code. We also leak memory, because
multifd_pages_init() returns the pointer to a new MultiFDPages_t
struct but we are ignoring its return value.

Fix both of these bugs by adding the missing assignment of
the newly created struct to p->pages.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
I don't know anything about the multifd code, but this seems like
the obvious fix based on looking at what the clear and init
functions are doing. I have only run 'make check' on this,
so review and testing definitely in order. I think we should
really put this into 4.0, which means ideally I'd like to
commit it to master today or tomorrow, though...
---
 migration/ram.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Peter Maydell <peter.maydell@linaro.org> wrote:
> Coverity points out (CID 1400442) that in this code:
>
>     if (packet->pages_alloc > p->pages->allocated) {
>         multifd_pages_clear(p->pages);
>         multifd_pages_init(packet->pages_alloc);
>     }
>
> we free p->pages in multifd_pages_clear() but continue to
> use it in the following code. We also leak memory, because
> multifd_pages_init() returns the pointer to a new MultiFDPages_t
> struct but we are ignoring its return value.
>
> Fix both of these bugs by adding the missing assignment of
> the newly created struct to p->pages.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---

ouch,

good catch.

Reviewed-by: Juan Quintela <quintela@redhat.com>



> I don't know anything about the multifd code, but this seems like
> the obvious fix based on looking at what the clear and init
> functions are doing. I have only run 'make check' on this,
> so review and testing definitely in order. I think we should
> really put this into 4.0, which means ideally I'd like to
> commit it to master today or tomorrow, though...
> ---
>  migration/ram.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/migration/ram.c b/migration/ram.c
> index f68beeeeffc..1ca9ba77b6a 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -851,7 +851,7 @@ static int multifd_recv_unfill_packet(MultiFDRecvParams *p, Error **errp)
>       */
>      if (packet->pages_alloc > p->pages->allocated) {
>          multifd_pages_clear(p->pages);
> -        multifd_pages_init(packet->pages_alloc);
> +        p->pages = multifd_pages_init(packet->pages_alloc);
>      }
>  
>      p->pages->used = be32_to_cpu(packet->pages_used);

On 4/9/19 5:18 PM, Peter Maydell wrote:
> Coverity points out (CID 1400442) that in this code:
> 
>     if (packet->pages_alloc > p->pages->allocated) {
>         multifd_pages_clear(p->pages);
>         multifd_pages_init(packet->pages_alloc);
>     }
> 
> we free p->pages in multifd_pages_clear() but continue to
> use it in the following code. We also leak memory, because
> multifd_pages_init() returns the pointer to a new MultiFDPages_t
> struct but we are ignoring its return value.
> 
> Fix both of these bugs by adding the missing assignment of
> the newly created struct to p->pages.
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>

> ---
> I don't know anything about the multifd code, but this seems like
> the obvious fix based on looking at what the clear and init
> functions are doing. I have only run 'make check' on this,
> so review and testing definitely in order. I think we should
> really put this into 4.0, which means ideally I'd like to
> commit it to master today or tomorrow, though...
> ---
>  migration/ram.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index f68beeeeffc..1ca9ba77b6a 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -851,7 +851,7 @@ static int multifd_recv_unfill_packet(MultiFDRecvParams *p, Error **errp)
>       */
>      if (packet->pages_alloc > p->pages->allocated) {
>          multifd_pages_clear(p->pages);
> -        multifd_pages_init(packet->pages_alloc);
> +        p->pages = multifd_pages_init(packet->pages_alloc);
>      }
>  
>      p->pages->used = be32_to_cpu(packet->pages_used);
>

On Tue, 9 Apr 2019 at 22:42, Juan Quintela <quintela@redhat.com> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> wrote:
> > Coverity points out (CID 1400442) that in this code:
> >
> >     if (packet->pages_alloc > p->pages->allocated) {
> >         multifd_pages_clear(p->pages);
> >         multifd_pages_init(packet->pages_alloc);
> >     }
> >
> > we free p->pages in multifd_pages_clear() but continue to
> > use it in the following code. We also leak memory, because
> > multifd_pages_init() returns the pointer to a new MultiFDPages_t
> > struct but we are ignoring its return value.
> >
> > Fix both of these bugs by adding the missing assignment of
> > the newly created struct to p->pages.
> >
> > Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> > ---
>
> ouch,
>
> good catch.
>
> Reviewed-by: Juan Quintela <quintela@redhat.com>

Thanks for the quick review. Applied to master for rc3.

-- PMM