[pull] master from moby:master#1404
Open
pull[bot] wants to merge 10000 commits intonext-stack:masterfrom
Open
Conversation
When restoring volumes at startup, the local volume driver's constructor
([daemon/volume/local.New]) iterates over all directories found inside the
volume storage path (`/var/lib/docker/volumes`). It does not (currently) check
for presence of other indicators that the directory is an actual volume, such
as the `_data` directory being present, or a `opts.json`.
In situations where `/var/lib/docker/volumes` contains directories that were
not created by docker, this can result in errors when calculating the size
of volumes (`docker system df`);
Before (re)starting the daemon, create some directories;
mkdir /var/lib/docker/volumes/notavolume
echo "some file" > /var/lib/docker/volumes/notavolume/some-file
mkdir /var/lib/docker/volumes/notavolume2
Then, start the daemon, and run `docker system df`. The daemon logs will
now contain warnings about the path not being found:
WARN[2026-02-09T11:27:31.940713593Z] Failed to determine size of volume error="lstat /var/lib/docker/volumes/notavolume/_data: no such file or directory" volume=notavolume
WARN[2026-02-09T11:27:31.940765468Z] Failed to determine size of volume error="lstat /var/lib/docker/volumes/notavolume2/_data: no such file or directory" volume=notavolume2
This patch updates the function to skip directories that neither contain
a `_data` directory, not have a `opts.json` file.
[daemon/volume/local.New]: https://github.com/moby/moby/blob/6c5233e1098dc689b2e665087780695ac8864e95/daemon/volume/local/local.go#L51-L85
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
no diff: same tag, but re-tagged as v0.14.0 microsoft/hcsshim@v0.14.0-rc.1...v0.14.0 Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
…k-upload-test fix: use t.Cleanup to prevent goroutine leak in TestCancelledUpload
vendor: github.com/microsoft/hcsshim v0.14.0
commit 4c24542 changed `PortRange.All()` to omit zero values for ports, but this caused a regression; the zero-value is used in some places to assign an ephemeral port, e.g.: `--port 80` is an implicit `--port 0:80`, or `--port <ephemeral port>:80`, where the daemon picks a random port number from the ephemeral port range as host-port. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
daemon/volume/local: New: ignore non-volume directories
api/types/network: fix handling of unmapped ports (ephemeral ports)
…egistry transport: enable HTTP keep-alive for registry connections
…sk-usage Fix reclaimable image disk usage calculation for in-use images
In saveAppArmorConfig, the privileged check unconditionally overwrites the AppArmor profile to "unconfined", even when the user explicitly set a custom profile via --security-opt apparmor=<profile>. This causes the persisted container.AppArmorProfile to be "unconfined" regardless of user intent. On first container start this is masked because createSpec/WithApparmor runs before saveAppArmorConfig and builds the OCI spec from the in-memory value (which still has the correct profile from creation). But saveAppArmorConfig then overwrites it to "unconfined" and CheckpointTo persists that to disk. On subsequent starts (restart, stop+start, host reboot), the container loads with AppArmorProfile "unconfined", and WithApparmor picks up that stale value — resulting in the container running without its intended AppArmor policy. Fix the condition nesting so that "unconfined" and "docker-default" are only applied as defaults when no explicit profile was set via SecurityOpt. This makes saveAppArmorConfig consistent with the existing behavior in both WithApparmor (oci_linux.go) and execSetPlatformOpt (exec_linux.go), which already give explicit profiles precedence over the privileged default. The bug was introduced in d97a00d (Docker 17.04, #27083) and survived a refactor in 483aa62 (#43130). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Use the same implementation as is used in the client. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
…ivileged daemon: respect explicit AppArmor profile on privileged containers
Not sure why I used this order; let's change to a more logical one. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
daemon: prevent invalid swarm events from unknown action kinds
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
daemon: include moby module version in version response
Signed-off-by: Sahana Narasipura Vasudevarao <nvsahanarao@gmail.com>
This will help adopting source policies in future. A part of issue 51637 Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
client/internal/mod: swap order of "ok" bool
update AUTHORS and .mailmap
When a "directory not empty" error occurs while EnsureRemoveAll operation should be retried once.
Fix typos and misspellings in comments, tests, and docs
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Drop replace rules
ci: validate module-replace: ignore _test.go files
…tchlogs to v1.71.0 Signed-off-by: Mend Renovate <bot@renovateapp.com>
…norepo fix(deps): update module github.com/aws/aws-sdk-go-v2/service/cloudwatchlogs to v1.71.0
The 5-second context timeout may be insufficient for Windows container start-up. Increase to 15 seconds, consistent with other Windows networking tests in the same package. Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The deprecated asm.NewInputTarStream leaves a goroutine hanging if the consumer doesn't fully drain the stream, and provides no signal for when the internal parsing goroutine has completed. Switch to asm.NewInputTarStreamWithDone which returns a done channel, allowing us to detect goroutine completion and surface any errors from the internal tar parsing. Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Signed-off-by: Mend Renovate <bot@renovateapp.com>
…inerd-continuity-0.x fix(deps): update module github.com/containerd/continuity to v0.5.0
NewInputTarStreamWithDone returns an io.ReadCloser whose background goroutine may block on a pipe write if the consumer doesn't fully drain the stream. If digest.FromReader returns early with an error, the subsequent <-done would block forever because the pipe write has no reader. Add defer archive.Close() so the pipe is always broken on exit, allowing the background goroutine to terminate and send on the done channel. Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Move `n.stopping=true` to the top of Stop(), before the nil check, so the reconnect goroutine always sees the correct state. When a swarm is locked, the node exits and handleNodeExit sets `swarmNode=nil` and starts a reconnect watcher goroutine. If Stop() is called while `swarmNode==nil`, it takes an early return without setting `stopping=true`. When the reconnect timer later fires, the goroutine sees `stopping==false` and calls n.start(), spawning an orphaned swarm node that writes encrypted state to disk. The next swarm init then fails with a 503 "Swarm is encrypted and needs to be unlocked" error - the flaky failure often seen in docker-py CI. Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The past tense better conveys that this is a terminal state ("don't
restart") rather than an in-progress action.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
No need to keep it inside the section Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
nodeRunner.Stop() accessed n.swarmNode and n.done after releasing the mutex. A concurrent handleNodeExit() call could set n.swarmNode to nil between the unlock and the field access, causing a nil pointer dereference. Capture both fields into local variables while still holding the lock. Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
When the proxy forwards a UDP datagram to a backend that isn't listening, the kernel queues an ICMP port-unreachable error on the connected socket. This error is returned on the *next* Write() call, not the one that triggered it. As a result, a subsequent write carrying new data silently fails and the datagram is never sent to the backend. The replyLoop already handles this for reads (goto again on ECONNREFUSED). Apply the same treatment to writes in Run() and retry the write when the error is ECONNREFUSED. Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
vendor: github.com/vbatts/tar-split v0.12.3
integration: Try to fix flaky TestNslookupWindows
The daemon may need a bit more time to start, probe the daemon first via `docker version` and then run docker info. Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
gha/windows: Fix flaky Docker info
…king BuildKit's bridge network provider used OptionUseExternalKey to defer netns creation, then wired up a "libnetwork-setkey" reexec binary as an OCI prestart hook. When runc created the container, the hook would dial the controller's external key listener to call SetKey, which bind-mounted /proc/<pid>/ns/net onto a persistent path. Switch to the simpler approach: the daemon creates the network namespace upfront (by not passing OptionUseExternalKey), then passes its path to runc via the OCI spec's NetworkNamespace entry. runc joins the existing netns instead of creating a new one. This is the same pattern used by BuildKit's CNI network provider. This eliminates the prestart hook, the reexec binary invocation, and the unix socket protocol from the BuildKit build path, removing a layer of indirection. Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
daemon/listeners: Support Unix socket on Windows
Fix flaky `Swarm is encrypted and needs to be unlocked` error
builder-next: Stop using libnetwork-setkey reexec for BuildKit networking
The pool optimization in the logging infrastructure can be tricky to get correct. Chaos and data races can ensue if a Message is used after it has been returned to the pool, similar to use-after-free bugs in memory-unsafe languages but without the type confusion. Most logging-related code was written assuming that the log driver unconditionally returns the Log()'ed Message to the pool. But some code, particularly the log copier and ring logger, was written as if the log driver did _not_ return the Message to the pool if Log() returned an error. Most log drivers unconditionally return the Message to the pool, making the ring logger and copier implementations subtly incorrect. Codify the contract to be that ownership of the Message moves to the log driver when Log() returns a nil error, otherwise the caller retains it. This is very convenient for error handling as the fields of the original message can be safely dereferenced instead of having to defensively make copies before calling the driver. Update all the logging infrastructure to adhere to this contract. Signed-off-by: Cory Snider <csnider@mirantis.com>
daemon/logger: refine the Logger contract
Verify that AF_ALG and AF_VSOCK sockets cannot be created inside a container running with the default seccomp profile. The test compiles small C programs inside a debian:trixie-slim container that attempt to create sockets with these address families, then runs them as a non-root user (uid 1000) and asserts that socket creation is denied with EPERM or EAFNOSUPPORT. Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
full diff: https://github.com/moby/profiles/seccomp/compare/v0.2.0...v0.2.1 Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
docker-proxy: Fix dropping UDP datagrams after backend becomes reachable
Test that AF_ALG is also denied through the socketcall(2) multiplexer, which is used by glibc on i386 instead of direct socket(2) syscalls. Two subtests: - AF_ALG_socketcall_int80: uses int $0x80 inline assembly from a native 64-bit binary to invoke the ia32 socketcall path, with MAP_32BIT to keep the args pointer below 4 GB (ia32 compat truncates registers). - AF_ALG_socketcall_i386: cross-compiles a static i386 binary using gcc-i686-linux-gnu where glibc naturally routes socket() through socketcall(2). Both are amd64-only. Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
full diff: https://github.com/moby/profiles/seccomp/compare/v0.2.1...v0.2.2 Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
seccomp: Block AF_ALG sockets in default profile (CVE-2026-31431)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
15 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )