WSLService can become unresponsive when init transactions wait indefinitely under session locks

[SylvainM98]

WSLService can become unresponsive when init transactions wait indefinitely under session locks

Summary

When the Linux guest stops responding, process launches can wait indefinitely. A concurrent shutdown can then block behind the same instance lock while holding the session lock, causing distribution enumeration, shutdown, and service termination to stop progressing.

Two request/response operations and one send operation in WslCoreInstance use the infinite default SocketChannel timeout while holding locks needed by other session operations.

Impact

If the guest remains connected but stops responding, the affected operation can wait indefinitely while holding locks needed by shutdown and other session operations. This can prevent distribution enumeration, shutdown, and service termination from progressing.

Code analysis

On Windows, SocketChannel::DefaultSocketTimeout is INFINITE.

The following operations omitted the existing m_socketTimeout value:

sessionLeader->GetChannel().Transaction<LX_INIT_CREATE_PROCESS_UTILITY_VM>(messageSpan)
m_initChannel->GetChannel().StartTransaction()

The affected paths are:

• WslCoreInstance::CreateLxProcess() while holding WslCoreInstance::m_lock;
• WslCoreInstance::Initialize() while holding m_lock, with its caller also holding LxssUserSessionImpl::m_instanceLock;
• WslCoreInstance::UpdateTimezone() while holding the channel lock, with its caller holding m_instanceLock.

RequestStop() and Stop() also require m_lock. A guest that does not answer a process-creation transaction can therefore prevent the shutdown path from acquiring the lock and progressing.

The same class already uses m_socketTimeout for comparable init operations. The value comes from DistributionStartTimeout, which defaults to 60 seconds and is configurable.

Expected behavior

A non-responsive guest may cause the individual operation to fail, but it must not leave WSLService, shutdown, enumeration, or unrelated session operations blocked indefinitely.

Proposed change

Pass m_socketTimeout to all three transactions:

Transaction<LX_INIT_CREATE_PROCESS_UTILITY_VM>(messageSpan, nullptr, m_socketTimeout)
StartTransaction(m_socketTimeout)

This applies the timeout policy already used by the surrounding code and does not introduce a new timeout value.

Tests

The added unit tests verify that:

• the peer receives the transaction request;
• a peer that remains connected without responding produces HRESULT_FROM_WIN32(ERROR_TIMEOUT) within a bounded interval;
• a valid response received before the deadline succeeds normally.

These tests validate SocketChannel::Transaction timeout propagation and behavior. They do not constitute a complete reproduction using a real WslCoreInstance or Linux guest.

[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-wsl-logs.ps1 -LogProfile networking instead, 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'.

[SylvainM98]

This report is based on static analysis of the current source tree. I will not attach machine logs. The unbounded transaction paths and their lock context are identified directly in the issue, and PR #41385 contains the proposed change and unit coverage. Please review the source-level findings and CI results.