`UtilAcceptVsock:271: accept4 failed 110` causes `git push` to hang indefinitely

[garysassano]

Windows Version

Microsoft Windows [Version 10.0.26100.7309]

WSL Version

2.6.1.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.6.87.2-1

Distro Version

Ubuntu 24.04.3 LTS (Noble Numbat)

Other Software

• VS Code with Remote - WSL extension
• Git credential helper configured via VS Code (GIT_ASKPASS environment variable)

Repro Steps

❯ git push
<3>WSL (40941 - ) ERROR: UtilAcceptVsock:271: accept4 failed 110
^C

To capture detailed trace:

strace -f -o strace.log git push

The strace log shows the following sequence:

1. git push spawns a child process to handle the remote connection
2. Parent and child communicate via pipes
3. Git sends protocol commands (capabilities, option progress false, list for-push)
4. While waiting for a response, the WSL interop layer encounters a timeout on accept4 for a vsock
5. The read() syscall returns ERESTARTSYS and the process hangs

Relevant strace excerpt:

write(4, "list for-push\n", 14)         = 14
read(3, <3>WSL (40941 - ) ERROR: UtilAcceptVsock:271: accept4 failed 110
0x..., 4096)           = ? ERESTARTSYS (To be restarted if SA_RESTART is set)

Error code 110 = ETIMEDOUT (Connection timed out)

Expected Behavior

Git push should complete successfully without hanging.

Actual Behavior

Git often fails to push to the remote because of a network issue triggered by WSL. The command hangs indefinitely and must be killed with Ctrl+C.

The only temporary fix I've found is restarting VS Code, but the problem eventually returns.

Root Cause Hypothesis:

The vsock (Hyper-V socket) is used for communication between the WSL2 VM and the Windows host. The UtilAcceptVsock function is part of WSL's internal infrastructure handling these connections.

The timeout (error 110) suggests the Windows-side service that should accept the vsock connection is:

• Not responding
• Taking too long to respond
• In a blocked or crashed state

Potential triggers:

1. VS Code's Git Credential Helper integration (GIT_ASKPASS environment variable is set)
2. Windows SSH agent or Credential Manager interop
3. WSL networking stack under load or in a degraded state
4. Hyper-V socket infrastructure issue between WSL2 VM and Windows host

Environment variables set during failure:

• WSL2_GUI_APPS_ENABLED=1
• WSL_DISTRO_NAME=Ubuntu
• WSL_INTEROP=/run/WSL/457_interop
• GIT_ASKPASS (pointing to VS Code's credential helper)
• VSCODE_GIT_ASKPASS_* variables

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[garysassano]

WslNetworkingLogs-2025-12-10_06-13-42.zip

strace.log

[github-actions]

Diagnostic information

.wslconfig found
Detected appx version: 2.6.1.0
optional-components.txt not found
Detected user visible error: Wsl/WSL_E_USER_NOT_FOUND
Detected user visible error: Wsl/Service/0x8007274c