OOM-kill in dockerd 20.10, tries to allocate 2³² IPAM subnets

[ulidtko]

Very briefly. With IPv6 enabled, and this entry in default-address-pools (daemon.json):

                , {"base":"fd0d:0ce5::/48", "size": 80}

Dockerd fails to start, crashes with fatal error: runtime: out of memory.

Crash log: ubQ795Mx.txt

As can be easily found in the crash log, OOM happens while in ipamutils.splitNetworks:

libnetwork/ipamutils/utils.go

Lines 92 to 93 in 3797618

	func splitNetworks(list []*NetworkToSplit) ([]*net.IPNet, error) {
	localPools := make([]*net.IPNet, 0, len(list))

The config shown, {"base":"fd0d:0ce5::/48", "size": 80} — denotes 2³² /80 subnets. This is over 4 billion subnets.

Related issue: moby/moby#40275

docker version

Client:
 Version:           20.10.21
 API version:       1.41
 Go version:        go1.18.1
 Git commit:        20.10.21-0ubuntu1~22.04.3
 Built:             Thu Apr 27 05:57:17 2023
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true
Server:

Engine:

Version:          20.10.21

API version:      1.41 (minimum version 1.12)

Go version:       go1.18.1

Git commit:       20.10.21-0ubuntu122.04.3

Built:            Thu Apr 27 05:37:25 2023

OS/Arch:          linux/amd64

Experimental:     true

containerd:

Version:          1.7.12

GitCommit:

runc:

Version:          1.1.12-0ubuntu222.04.1

GitCommit:

docker-init:

Version:          0.19.0

GitCommit:

[akerouanton]

Thanks for reporting. This was also reported in moby/moby, under moby/moby#40275.

The following PR introduced a new subnet allocator which doesn't suffer from this issue. It was released in v27.0, on June 25.

• libnet/ipams/default: introduce a linear allocator moby#47768

Note that:

1. Docker Engine v20.10 was EOL'd a year ago, and thus you might miss important security fixes.
2. The code here is now part of moby/moby. This repo is mostly defunct, and new bug reports should be opened there. This repo can't be archived yet as we need to migrate issues and PRs.

[ulidtko]

Thanks so much for accurate response @akerouanton