-
Daniel Xu authored
If capture-output is requested but one of the channels goes unused (eg. we attempt to capture stderr but the command never writes to stderr), we can leak memory. guest_exec_output_watch() is (from what I understand) unconditionally called for both streams if output capture is requested. The first call will always pass the `p->size == p->length` check b/c both values are 0. Then GUEST_EXEC_IO_SIZE bytes will be allocated for the stream. But when we reap the exited process there's a `gei->err.length > 0` check to actually free the buffer. Which does not get run if the command doesn't write to the stream. Fix by making free() unconditional. Reviewed-by:
Konstantin Kostiuk <kkostiuk@redhat.com> Signed-off-by:
Daniel Xu <dxu@dxuuu.xyz> Signed-off-by:
Konstantin Kostiuk <kkostiuk@redhat.com>
Daniel Xu authoredIf capture-output is requested but one of the channels goes unused (eg. we attempt to capture stderr but the command never writes to stderr), we can leak memory. guest_exec_output_watch() is (from what I understand) unconditionally called for both streams if output capture is requested. The first call will always pass the `p->size == p->length` check b/c both values are 0. Then GUEST_EXEC_IO_SIZE bytes will be allocated for the stream. But when we reap the exited process there's a `gei->err.length > 0` check to actually free the buffer. Which does not get run if the command doesn't write to the stream. Fix by making free() unconditional. Reviewed-by:
Konstantin Kostiuk <kkostiuk@redhat.com> Signed-off-by:
Daniel Xu <dxu@dxuuu.xyz> Signed-off-by:
Konstantin Kostiuk <kkostiuk@redhat.com>