SIGSEGV in `QuicSendBufferFill` After Connection Start Failure
@ProjectsByJackHe is already working on this.
Since Jul 21, 2026.
Assessment
This issue has not been assessed yet.
Description
Describe the bug
Summary
The Basic.ConnectionCloseFromCallback test reliably crashes with SIGSEGV
when ip6-localhost cannot be resolved. Address resolution fails during
connection startup, and the subsequent stream-send cleanup dereferences a null
list entry in QuicSendBufferFill().
Affected OS
- Windows
- Linux
- macOS
- Other (specify below)
Additional OS information
No response
MsQuic version
The issue was reproduced with the official MsQuic repository at:
Branch: main
Commit: c227199009273e328895e4c44ce2118571b3d5c6
Describe: v2.5.0-481-gc22719900
Test date: 2026-07-20
### Steps taken to reproduce bug
## Reproduction Environment
```text
Operating system: Linux
Architecture: x86-64
Build type: Release with debug information
Test executable: msquictest
The host does not define an IPv6 loopback hostname in /etc/hosts. In
particular, the following names and address are absent:
::1
ip6-localhost
ip6-loopback
The host only defines the IPv4 localhost entry:
127.0.0.1 localhost
The resolver state can be confirmed with:
getent hosts localhost
getent hosts ip6-localhost
Observed results:
$ getent hosts localhost
127.0.0.1 localhost
$ getent hosts ip6-localhost
# No output; exit status 2
Reproduction Conditions
The crash requires the following conditions:
ip6-localhostdoes not resolve on the test host.Basic.ConnectionCloseFromCallbackstarts a connection using the address
selected by the test's unspecified-address path.- The Linux test path selects
ip6-localhostfor that connection. - Address resolution fails while a stream send request is pending.
- Connection shutdown cancels the pending stream send request.
Steps to Reproduce
-
Check out and build MsQuic, including
msquictest. -
Ensure that
ip6-localhostdoes not resolve:getent hosts ip6-localhostThe command must produce no address and return a nonzero status.
-
From the directory containing
msquictest, run:./msquictest --gtest_filter=Basic.ConnectionCloseFromCallback
Actual Result
The test process terminates with signal 11:
Segmentation fault (core dumped)
The shell commonly reports exit status 139.
Expected Result
The connection-start failure should be reported through the normal test or API
error path. Pending stream send requests should be cancelled safely, and the
test process should not crash.
Failure Sequence
GDB shows the following sequence:
- The test uses
ip6-localhostas the server name. CxPlatDataPathResolveAddress()fails to resolve the name.QuicConnStart()enters local connection-close processing.- Stream shutdown cancels a pending send request.
QuicStreamCompleteSendRequest()callsQuicSendBufferFill().QuicSendBufferFill()advances through a null list link and crashes.
Resolver state captured immediately after the resolution failure:
ServerName = "ip6-localhost"
Status = 4294967293 # -3
RemoteAddress family = 0
GDB Backtrace
#0 QuicSendBufferFill
at src/core/send_buffer.c:155
#1 QuicStreamCompleteSendRequest
at src/core/stream_send.c:469
#2 QuicStreamCancelRequests
at src/core/stream_send.c:1646
#3 QuicStreamSendShutdown
at src/core/stream_send.c:188
#4 QuicStreamShutdown
at src/core/stream.c:585
#5 QuicStreamSetShutdown
at src/core/stream_set.c:222
#6 QuicConnTryClose
at src/core/connection.c:1701
#7 QuicConnCloseLocally
at src/core/connection.c:1745
#8 QuicConnStart
at src/core/connection.c:2001
#9 QuicConnProcessApiOperation
at src/core/connection.c:7850
#10 QuicConnDrainOperations
at src/core/connection.c:8111
At the crash point:
Entry = 0x0
Connection->Send.SendStreams.Flink is non-null, but the stream link reached
by the traversal has a null Flink. The crash occurs when the loop at
Entry = Entry->Flink attempts to continue the traversal.
Expected behavior
The connection-start failure should be reported through the normal test or API
error path. Pending stream send requests should be cancelled safely, and the
test process should not crash.
Actual outcome
The test process terminates with signal 11:
Segmentation fault (core dumped)
The shell commonly reports exit status 139.
Additional details
No response
- Dominant language
- C
- Stars
- 4.8k
- Forks
- 698
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 35
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/msquic
-
Area: Build Triaged
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
-
Area: Testing HowFound: MSR Triaged
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Area: Core HowFound: MSR Triaged
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
All issues in microsoft/msquic
Similar issues
-
[adam] AdamNet network read doesn't cap to MAX_ADAM_PACKET_LEN, overflows client receive buffers Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
FujiNetWIFI/fujinet-firmware#1649 · 2 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
HarbourMasters/Shipwright#7229 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
riscv-software-src/riscv-isa-sim#2435 · 1 comment ·
-
bug Self Built Image SNAPSHOT Supported Device target/ramips
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100