Docker 20.10.22 restores the configured range for dynamic host ports
The maintenance release repairs random port allocation and updates packaged tools. Its runtime security changes also require distinguishing containerd's CRI service from Docker Engine's own integration.
A dynamically selected container port still needs to fit the host's network policy. Docker Engine 20.10.22 fixes a regression in which random host-port allocation ignored the configured ephemeral port range. The December 16 release notes place that correction alongside packaged runtime updates and a tighter default seccomp profile.
The port fix is a useful example of why maintenance releases deserve a mechanism-level explanation. A service can start successfully and listen on an assigned host port while remaining unreachable through the organization's intended firewall rules. The container is running, but the allocation no longer matches the configuration that made its network access predictable.
I value Docker's repeatable application environment. A declared container port is only part of making that environment reachable. Host-side allocation rules remain an operational dependency outside the image, so restoring their documented behavior matters even when no application file changes.
Random selection still has a configured range
The original issue describes Docker ignoring net.ipv4.ip_local_port_range after an upgrade to the 20 series. It affects publishing exposed ports with -P and publishing a particular container port without specifying a host port. The reporter wanted the allocated values to remain inside a configured range so corresponding security-group rules could permit them.
The reproduction sets a host range of 32678 through 40000. An older installation assigns ports within that interval, while the reported 20-series installation chooses values in 49153 through 65535. Those numbers describe the issue's reproduction. They are not a statement that every host should adopt the same range.
The relevant command shape leaves host-port choice to Docker.
docker run -d -p :80 nginx
The issue uses this form to distinguish dynamic host allocation from an explicit host-port binding. A command with a selected host port expresses a different request. The correction concerns the range from which Docker chooses when it must make that selection itself.
The backport pull request brings the allocation correction into the maintenance branch. The practical result stated by the release notes is that the host's configured ephemeral range again participates in random port selection. Network rules based on that range no longer depend on the older behavior reported in the issue.
The seccomp change restricts VM communication sockets
The default seccomp profile now blocks socket calls for AF_VSOCK. The backport discussion connects this to containerd's profile and a KubeVirt use case. Virtual sockets support communication between guests and hosts. The concern was that ordinary workloads could attempt connections to VMs where the intended caller was a privileged node agent.
This is a different communication path from publishing an application TCP port. Tightening it limits an operation through the default system-call policy. The discussion notes that privileged workloads and custom policies represent separate configurations. The release should therefore be understood as changing the default profile, not eliminating every possible use of virtual sockets.
The distinction also prevents an inaccurate reading of networking maintenance. Correcting dynamic port allocation restores a configured selection rule. The virtual-socket restriction reduces what a container may request under the default security policy. Both affect communication, but they address different mechanisms.
The packaged containerd update has a specific advisory
Docker updates the containerd.io package to 1.6.13 and cites CVE-2022-23471. The containerd advisory published December 7 describes a leak in its CRI stream server. Requesting a TTY launches a goroutine to handle terminal resize events. If the requested process fails to start, that goroutine can remain blocked sending to a receiver that never arrives.
Repeated failures can consume host memory. The advisory identifies Kubernetes and crictl as clients that can use the affected CRI implementation. It lists fixes in containerd 1.6.12 and 1.5.16. Docker's packaged 1.6.13 update includes that correction, but the advisory does not establish that Docker's normal command path exercises the vulnerable CRI service.
My preference is to preserve that qualification in an upgrade explanation. Sharing a runtime dependency is not enough to establish identical exposure through every product that embeds it. The affected interface and failure sequence explain where the vulnerability applies.
Packaged tools advance with the engine
The release also updates Compose to 2.14.1, Docker Scan to 0.23.0 and the Go runtime to 1.18.9. It improves errors for unsupported image formats or OCI artifacts and fixes an SSH parsing failure during builds on hosts using OpenSSH 8.9 or later.
These changes describe several independent maintenance responsibilities in one distribution. The most direct behavioral correction for dynamically published services is the restored host-port range. The runtime updates and seccomp change address different parts of the environment that prepares and executes those services.