nsenter.c may have a resource leak after calling the bail function

[peppaJoeng]

I am learning the code of nsenter.c, and I found that in the join_namespaces function, memory is first allocated for the namespaces variable through realloc, and then there may be a failure when parsing the namespace path, thus calling the bail function. The bail function returns an error, and then calls exit to exit the process.

https://github.com/opencontainers/runc/blob/ff8c4c7b72ae369361ef76d12590c3165f46bca8/libcontainer/nsenter/nsexec.c#L496C1-L511C1

One explanation I can think of is that after the process exits after calling exit, the operating system will reclaim the memory, which may not cause actual impact. However, this way of writing does not meet the requirements of release after use. After all, not all OSes follow this practice.

What's more, join_namespaces is called through the fork child process in the nsexec function. I have doubts about whether the memory of the child process exits but the parent process does not exit.

As runc is an open source library, the code may be referenced by other three parties, and they may call the code of runc in the form of a resident process. There is a possibility of a memory leak.

[cyphar]

If you would like to send a patch to fix the "memory leaks" in nsexec, I'd be happy to review them, but I'm not sure how much sense it would make given the following...

After all, not all OSes follow this practice.

• runc only runs on Linux.
• I am not aware of any operating system where a process with a memory leak when it died would result in the memory leak continuing to exist -- if it did exist, that would be an operating system bug because every C program assumes that this is the case. Where would the leak even be? With virtual memory, a process's memory mappings are dynamic and thus once the process is dead there is no concept of the memory being "used".

As runc is an open source library, the code may be referenced by other three parties, and they may call the code of runc in the form of a resident process. There is a possibility of a memory leak.

This is not possible, exit will always kill the current process. In addition, the C code in nsenter is spawned in a very specific way such that you cannot call it from Go code, it's called during initialisation for "runc init".

What's more, join_namespaces is called through the fork child process in the nsexec function. I have doubts about whether the memory of the child process exits but the parent process does not exit.

Once nsexec is done, it returns to Go where all of the allocated memory is going to be overwritten by the Go runtime (Go doesn't use libc malloc, so the "allocated memory" disappears once the Go runtime starts working).

[peppaJoeng]

Thanks for your answer. This does have something to do with CGO's memory management. I can understand this problem in this way. Use the init function to spawn an nsexec process (in fact, we also follow this method) to ensure that when the nsexec process exits, the memory allocated by C is taken over by Go. If the entire GO process exits, the OS is responsible for recycling. The essence is that the memory is taken over by the OS after the process exits.

In our scenario, we try to access the container's network namespace to manipulate the NIC. So we re-execute the binary program through the exec.Cmd function, and then call reexec.Init() to enter the container.

Anyway, to some extent, releasing memory space after use does not cause memory leaks in practice.