Bug 87

Spawned processes can inherit one stray file descriptor

Status

Open

Symptom

File descriptor leak; worst effect seen: test failure only

Where seen

Libmultiprocess tests (mptest)

Trigger

Starting a child process (fork and exec)

First reported

Reported privately in an independent security review, 2026-08-07

Fixed

Not yet

In released binaries

Yes

Defect ever on master

Yes

Summary

Before exec'ing a spawned process, SpawnProcess closes inherited file descriptors in a loop that stops one short of the highest descriptor, and it never visits descriptors above a lowered RLIMIT_NOFILE. A descriptor without FD_CLOEXEC in one of those slots leaks into the spawned process. It was reported privately in an independent security review, and a test reproduces both cases. It has not been seen in practice: the top slot is normally free, Bitcoin Core never lowers the limit, and on master SpawnProcess only runs for the test-only echoipc RPC. Released binaries since v30.0 contain the code. No fix yet.

What happened

• Nothing leaked outside a test. The problem was reported privately in an independent security review, which pointed out that the child's close loop excludes the highest permitted descriptor and that descriptors above a lowered limit are never visited, both shown with standalone models. Most of that report concerns a different window, between socketpair() and fcntl(FD_CLOEXEC), which is the remaining gap described in mp#311 ("clear FD_CLOEXEC in child instead of parent before fork") and tracked there (bug page). The code on master matches the finding.

Root cause

Between fork() and execvp(), SpawnProcess (src/mp/util.cpp) closes every inherited descriptor except the ones it passes to the child:

const int maxFd = MaxFd();
for (int fd = 3; fd < maxFd; ++fd) {
    if (fd != fds[0] && fd != error_fds[0]) close(fd);
}

MaxFd() is documented as "Return highest possible file descriptor" and returns nofile.rlim_cur - 1, an inclusive bound, but the loop treats it as exclusive, so descriptor rlim_cur - 1 is never closed (1023 when getrlimit fails and the fallback is used). The bound also comes from the current soft limit rather than from the descriptors actually open, so a process that opened descriptors and then lowered the limit leaks everything above the new limit.

A leaked descriptor survives exec only if it lacks FD_CLOEXEC, and ryanofsky noted in review of mp#312 that Bitcoin Core does not apply that flag everywhere. The kernel hands out the lowest free number, so the top slot is occupied only near descriptor exhaustion or after an explicit dup2 to a high number. RaiseFileDescriptorLimit in Bitcoin Core only raises the limit. The effect would be an unrelated file or socket held open by the spawned process, possibly delaying EOF on it.

Later hardening of this function did not touch the loop bound: mp#237 ("Made SpawnProcess() behavior safe post fork()"), mp#311, and mp#312 ("report back child errors to parent and throw") reviewed the child code for async-signal safety and CLOEXEC ordering.

Fix

No fix yet. The usual fixes are close_range(3, ~0U, ...) or closefrom(3) where available, or making the loop inclusive.

Reproduction

Two tests in mptest, the libmultiprocess unit test program, check which descriptors a spawned process inherits. The first puts a /dev/null descriptor opened without O_CLOEXEC at rlim_cur - 1 and at rlim_cur - 2, and for each runs sh -c 'test -e /proc/$$/fd/N' through SpawnProcess. The second puts such a descriptor at 100, lowers the soft RLIMIT_NOFILE to 64, spawns the same check, and restores the limit. It was run on 2026-09-26 against Bitcoin Core master bfdcd97, which carries libmultiprocess v13 in its subtree.

Patch: mptest-repro.patch. It applies to Bitcoin Core master; last checked against badc957 on 2026-10-15. From a Bitcoin Core checkout:

curl -sO https://ipcbugs.ofsky.org/repro/mptest-repro.patch
git apply mptest-repro.patch
cmake --build build --target mptest
build/src/ipc/libmultiprocess/test/mptest -f spawn_tests.cpp:132
build/src/ipc/libmultiprocess/test/mptest -f spawn_tests.cpp:152

The descriptor at rlim_cur - 1 was inherited and the one below it was closed; the descriptor above the lowered limit was inherited:

rlim_cur; lim.rlim_cur = 524288; fd; below = 524286; leaked_below = false; fd; top = 524287; leaked_top = true
fd 100 with soft limit 64 inherited; leaked = true

Both results are the same on every run. The test patch is available on request and will be included in the GitHub issue for this bug when it is opened.

Next steps

• Open the drafted libmultiprocess issue (an issue to be opened). It also covers the remaining socketpair() to fcntl(FD_CLOEXEC) window from mp#311.
• Replace the close loop with close_range(3, ~0U, 0) or closefrom(3) where available, and keep an inclusive loop as the fallback.
• Add the two reproduction tests (a descriptor at rlim_cur - 1, and one above a lowered limit) as regression tests.
• After the fix is merged, update Bitcoin Core's libmultiprocess subtree. The same update also brings mp#274, mp#311 and mp#312, which close the wider socket-inheritance problem that Bitcoin Core master still has.

Timeline

• 2019-08-06: introduced by f324c666150b ("Add Connnect/Serve/Spawn/Wait functions"), merged in mp#8; MaxFd() and the loop are unchanged since.
• 2026-08-07: reported privately in an independent security review.
• 2026-09-26: both cases reproduced with tests against Bitcoin Core master.
• Open as of 2026-09 on both libmultiprocess and Bitcoin Core master; released binaries since v30.0 contain it.

Classification

The survey's classification of this bug. The explorer charts these fields across all bugs; the method page explains them.