From 0f90cc1ecb2db92e5388e07b8662b6c4a3a64f6c Mon Sep 17 00:00:00 2001

From: Kir Kolyshkin <kolyshkin@gmail.com>

Date: Tue, 15 Sep 2020 21:46:32 -0700

Subject: [PATCH] runc run: fix panic on error

In case (*initProcess).start did not set sentRun, and ierr is nil,

runc run panics:

```

panic: runtime error: invalid memory address or nil pointer dereference [recovered]

	panic: runtime error: invalid memory address or nil pointer dereference

[signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0x68a117]

goroutine 1 [running]:

github.com/urfave/cli.HandleAction.func1(0xc0002277d8)

	/home/kir/go/src/github.com/projectatomic/runc/Godeps/_workspace/src/github.com/urfave/cli/app.go:478 +0x22d

panic(0x730b60, 0xa06fc0)

	/usr/lib/golang/src/runtime/panic.go:969 +0x166

github.com/opencontainers/runc/libcontainer.(*genericError).Error(0x0, 0xc0002ca0e0, 0xe)

	/home/kir/go/src/github.com/projectatomic/runc/Godeps/_workspace/src/github.com/opencontainers/runc/libcontainer/generic_error.go:93 +0x37

github.com/opencontainers/runc/libcontainer.createSystemError(0x7fcd20, 0x0, 0x78c23e, 0xe, 0xc000098050, 0x0)

	/home/kir/go/src/github.com/projectatomic/runc/Godeps/_workspace/src/github.com/opencontainers/runc/libcontainer/generic_error.go:78 +0x14c

github.com/opencontainers/runc/libcontainer.newSystemErrorWithCause(...)

	/home/kir/go/src/github.com/projectatomic/runc/Godeps/_workspace/src/github.com/opencontainers/runc/libcontainer/generic_error.go:63

github.com/opencontainers/runc/libcontainer.(*initProcess).start(0xc000298000, 0x0, 0x0)

	/home/kir/go/src/github.com/projectatomic/runc/Godeps/_workspace/src/github.com/opencontainers/runc/libcontainer/process_linux.go:361 +0x94b

....

```

This is caused by the fact that `ierr` is a typed variable (rather than a

generic `error`), and when `newSystemErrorWithCause(ierr, ...)` is called

with a typed variable, the check `if err != nil` in `createSystemError`

does not work, since err has a type. This Golang peculiarity is described

in https://golang.org/doc/faq#nil_error.

After this patch (tested by temporarily modifying the source to set

`sentRun` to `false`) it no longer panics, instead we get:

```

container_linux.go:247: starting container process caused "container init failed"

```

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>

---

 libcontainer/process_linux.go | 5 ++++-

 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libcontainer/process_linux.go b/libcontainer/process_linux.go

index 7c92c93a..53df9fa5 100644

--- docker-0be3e217c42ecf554bf5117bec9c832bd3f3b6fd/runc-66aedde759f33c190954815fb765eedc1d782dd9/libcontainer/process_linux.go

+++ docker-0be3e217c42ecf554bf5117bec9c832bd3f3b6fd/runc-66aedde759f33c190954815fb765eedc1d782dd9/libcontainer/process_linux.go

@@ -364,7 +364,10 @@ loop:

 		return newSystemError(fmt.Errorf("container init exited prematurely"))

 	}

 	if !sentRun {

-		return newSystemErrorWithCause(ierr, "container init")

+		if ierr != nil {

+			return newSystemErrorWithCause(ierr, "container init")

+		}

+		return newSystemError(errors.New("container init failed"))

 	}

 	if p.config.Config.Namespaces.Contains(configs.NEWNS) && !sentResume {

 		return newSystemError(fmt.Errorf("could not synchronise after executing prestart hooks with container process"))