VScode dev containers seg fault on Intel-based Macs on Docker Desktop 4.41

[wh807]

Description

After updating to Docker Desktop 4.41.0, I was unable to connect via vscode. I'm on Intel Mac. The VSCode server says "an error occurred attaching to the container".

Things I have tried:
reinstall the vscode server and re-attach, does not work
rm -rf /home/.vscode-server

Please take a look and let me know if you need more info. It was working the day before yesterday before I installed the new docker desktop update. Are there files or bugs that are incompatible with VSCode server after the update?

Reproduce

Run the container and try to connect from VSCode "attach to running container"

Expected behavior

should have connected vscode to container

docker version

Client:
 Version:           28.1.1
 API version:       1.49
 Go version:        go1.23.8
 Git commit:        4eba377
 Built:             Fri Apr 18 09:49:45 2025
 OS/Arch:           darwin/amd64
 Context:           desktop-linux

Server: Docker Desktop 4.41.0 (190950)
 Engine:
  Version:          28.1.1
  API version:      1.49 (minimum version 1.24)
  Go version:       go1.23.8
  Git commit:       01f442b
  Built:            Fri Apr 18 09:52:57 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.7.27
  GitCommit:        05044ec0a9a75232cad458027ca83437aae3f4da
 runc:
  Version:          1.2.5
  GitCommit:        v1.2.5-0-g59923ef
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client:
 Version:    28.1.1
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v1.1.7
    Path:     /Users/.docker/cli-plugins/docker-ai
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.23.0-desktop.1
    Path:     /Users/.docker/cli-plugins/docker-buildx
  cloud: Docker Cloud (Docker Inc.)
    Version:  v0.3.0
    Path:     /Users/.docker/cli-plugins/docker-cloud
  compose: Docker Compose (Docker Inc.)
    Version:  v2.35.1-desktop.1
    Path:     /Users/.docker/cli-plugins/docker-compose
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.38
    Path:     /Users/.docker/cli-plugins/docker-debug
  desktop: Docker Desktop commands (Docker Inc.)
    Version:  v0.1.8
    Path:     /Users/.docker/cli-plugins/docker-desktop
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.2
    Path:     /Users/.docker/cli-plugins/docker-dev
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.27
    Path:     /Users/.docker/cli-plugins/docker-extension
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     /Users/.docker/cli-plugins/docker-init
  mcp: Docker MCP Plugin (Docker Inc.)
    Version:  dev
    Path:     /Users/.docker/cli-plugins/docker-mcp
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     /Users/.docker/cli-plugins/docker-sbom
  scout: Docker Scout (Docker Inc.)
    Version:  v1.17.1
    Path:     /Users/.docker/cli-plugins/docker-scout

Server:
 Containers: 4
  Running: 1
  Paused: 0
  Stopped: 3
 Images: 4
 Server Version: 28.1.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 05044ec0a9a75232cad458027ca83437aae3f4da
 runc version: v1.2.5-0-g59923ef
 init version: de40ad0
 Security Options:
  seccomp
   Profile: unconfined
  cgroupns
 Kernel Version: 6.10.14-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 7.656GiB
 Name: docker-desktop
 ID: 1dbccd90-20ae-45f9-ba5d-58daf6462643
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=unix:///web.archive.org/web/20260207214353/https://users/Library/Containers/com.docker.docker/Data/docker-cli.sock
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: DOCKER_INSECURE_NO_IPTABLES_RAW is set
WARNING: daemon is not using the default seccomp profile

Diagnostics ID

5F4BCBFA-FF30-4767-BFDE-5F98047BC754/20250430194123

Additional Info

...
[2605 ms] Start: Run in container: mkdir -p '/tmp/devcontainers-a20e0c5c-8f8a-4556-9073-14da83e78bb61746040830209' && cat > '/tmp/devcontainers-a20e0c5c-8f8a-4556-9073-14da83e78bb61746040830209/env-loginInteractiveShell.json' << 'envJSON'
[2613 ms]
[2613 ms]
[2748 ms] Segmentation fault
[2771 ms] Command failed: /home/user/.vscode-server/bin/17baf841131aa23349f217ca7c570c76ee87b957/bin/code-server --log debug --force-disable-user-env --server-data-dir /home/user/.vscode-server --use-host-proxy --telemetry-level all --accept-server-license-terms --host 127.0.0.1 --port 0 --connection-token-file /home/user/.vscode-server/data/Machine/.connection-token-17baf841131aa23349f217ca7c570c76ee87b957 --extensions-download-dir /home/user/.vscode-server/extensionsCache --start-server --disable-websocket-compression --skip-requirements-check
[2771 ms] Segmentation fault
[2771 ms] Exit code 139
[12306 ms] Extensions cache, remote removals: None
[72313 ms] Extensions cache, remote removals: None
[132325 ms] Extensions cache, remote removals: None
...

[sfrycertinia]

I have the exact same issue. Also on Intel Mac. Reverting to 4.40.0 and VSCode devcontainers start working again for me.

[krishanjmistry]

I've just hit the same issue with VSCode devcontainers following the Docker Desktop update to 4.41.1 - Intel Mac as well.

Can also confirm that downgrading to 4.40.0 (engine 28.0.4) helped me.

Linked issues:
microsoft/vscode-remote-release#10921

[wh807]

ok thanks guys! can confirm that it works for me again after reverting to 4.40.0.

[drob0362]

I've just hit the same issue with VSCode devcontainers following the Docker Desktop update to 4.41.1 - Intel Mac as well.

Can also confirm that downgrading to 4.40.0 (engine 28.0.4) helped me.

Linked issues: microsoft/vscode-remote-release#10921

I'm the author of the linked issue above. Great to know that there is a workaround, though sadly not an option for me as I am using a corporate laptop and therefore do not have the ability to downgrade Docker.

[krishanjmistry]

It appears a change in how memory protection keys are utilised might have something to do with this.

Out of curiosity, I dug into this a bit further using strace on the vscode-server binary

On Docker Desktop 4.41.0, the segmentation fault SIGSEGV arises with an si_code of SEGV_PKUERR. Here's an excerpt of captured traces:

[...]
618   pkey_alloc(0, PKEY_DISABLE_ACCESS) = 1
[...]
618   pkey_alloc(0, PKEY_DISABLE_ACCESS) = 1
[...]
618   pkey_mprotect(0x172413413000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, 1) = 0
[...]
618   --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_PKUERR, si_addr=0x172413413298, si_pkey=1} ---
[...]

The following difference was noticed when the following call was made on 4.40.0:

[...]
2117  pkey_alloc(0, PKEY_DISABLE_ACCESS) = -1 ENOSYS (Function not implemented)
[...]

On 4.40.0, by my understanding, as the functionality is not present, no pkey_mprotect calls are made - so you don't end up in the branch that leads to the seg fault on 4.41.0.

My intuition would be this has been triggered as a result of the following item listed in the Docker Desktop 4.41.0 release notes under the Bug fixes and enhancements / For all platforms section

Enabled the memory protection keys mechanism in the Docker Desktop Linux VM, allowing containers like Oracle database images to run correctly.

Where the actual issue is, I don't know!

Some (maybe) useful reading on surrounding topics:
https://docs.kernel.org/core-api/protection-keys.html
https://man7.org/linux/man-pages/man2/sigaction.2.html
https://man7.org/linux/man-pages/man7/pkeys.7.html

[sfrycertinia]

Looks like this usage of protection keys is in the V8 implementation that Node.js uses.

[ctalledo]

Hi folks, Cesar from Docker here. Thanks for filing this issue and the investigation.

My intuition would be this has been triggered as a result of the following item listed in the Docker Desktop 4.41.0 release notes under the Bug fixes and enhancements / For all platforms section

Enabled the memory protection keys mechanism in the Docker Desktop Linux VM, allowing containers like Oracle database images to run correctly.

Yes that must be the case; in Docker Desktop 4.41, we enabled the Linux mem protection keys mechanism in the Linux VM that Docker Deskop runs. Some container images (e.g., Oracle database images) require that mechanism to be present in the kernel.

Nothing wrong with that per-se, since we are only enabling a new functionality in the VM's Linux kernel, which applications can choose to use or not. However the fact that it triggers a segmentation fault in the vscode-server with code SEGV_PKUERR (which means "protection key access violation") very likely implies a bug in how the vscode-server binary is using the mechanism, or an issue related to how the Linux mem protection keys mechanism is working on Mac with Intel (since I believe all users reporting this issue are on such platform).

@krishanjmistry: would it be possible for you to attach a larger portion of the vscode-server strace (around the seg fault), so we can better understand what vscode is trying to do and why it's failing?

[ctalledo]

Update:

Unable to repro with Docker Desktop 4.41 + VScode dev containers on Linux, Mac (ARM CPU), and Windows hosts.

For Linux, the strace shows vscode-server using mem protection keys without problem:

[pid  2726] pkey_alloc(0, PKEY_DISABLE_ACCESS) = 1
[pid  2726] pkey_mprotect(0x24a12deda000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, 1) = 0
[pid  2726] pkey_mprotect(0x24a12dedb000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, 1) = 0
...

For Mac (ARM), the pkey_* system calls are not supported, so things work.

For Windows (Intel CPU, DD with Hyper-V), the strace shows vscode-server failing to allocate a mem protection key, but the error is ignored as the VS code dev container works properly:

[pid  2057] pkey_alloc(0, PKEY_DISABLE_ACCESS) = -1 EINVAL (Invalid argument)

Thus the problem appears to be specific to Mac + Intel chip.