Remove CXPLAT_FRE_ASSERT around QuicCryptoFrameEncode#6102
Merged
guhetier merged 1 commit intoJun 16, 2026
Conversation
anrossi
approved these changes
Jun 15, 2026
mtfriesen
approved these changes
Jun 16, 2026
There was a problem hiding this comment.
Pull request overview
This PR updates the recvfuzz tool on release/2.5 to avoid asserting on QuicCryptoFrameEncode failures that can legitimately occur when the CRYPTO frame won’t fit into the remaining QUIC INITIAL payload. This prevents deterministic startup crashes in the stress/recvfuzz schannel configuration and aligns behavior with main.
Changes:
- Remove
CXPLAT_FRE_ASSERTwrappingQuicCryptoFrameEncodeinWriteCryptoFrame. - Allow
WriteCryptoFrameto proceed without crashing when the CRYPTO frame cannot be encoded due to remaining buffer constraints.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
QuicCryptoFrameEncode legitimately returns FALSE when the encoded CRYPTO frame would not fit in the remaining INITIAL packet payload. This happens on schannel builds whose ClientHello has grown beyond ~1200 bytes (e.g. WinServerPrerelease offering ML-KEM keyshares), causing recvfuzz on release/2.5 to crash with STATUS_ASSERTION_FAILURE before doing any actual fuzzing. A fuzzer should not assert on the return value of an encode helper anyway; the existing call sites already tolerate a no-op encode. Match the behavior already present on main (commit cc81b15). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
guhetier
force-pushed
the
guhetier/recvfuzz_remove_crypto_assert_2_5_copilot
branch
from
6efffa1 to
9e7de98
Compare
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
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.
Description
QuicCryptoFrameEncodelegitimately returnsFALSEwhen the CRYPTO frame would not fit in the remaining QUIC INITIAL packet payload. Onrelease/2.5,recvfuzz'sWriteCryptoFramewraps this call inCXPLAT_FRE_ASSERT, which crashes the process withSTATUS_ASSERTION_FAILURE(0xC0000420) before any actual fuzzing happens.This is currently firing deterministically on the
recvfuzz (Debug, windows, WinServerPrerelease, x64, schannel, -Test)stress job: the schannel ClientHello on the WinServerPrerelease image is ~1521 bytes (offers ML-KEM keyshares), which does not fit in the ~1170-byte INITIAL payloadrecvfuzzbudgets for it.A fuzzer should not assert on the return value of an encode helper anyway. This change just drops the
CXPLAT_FRE_ASSERTwrapper, matching the behavior already present onmain(commitcc81b151b, PR #5727). The TODO onmainabout properly fragmenting CRYPTO frames across multiple INITIAL packets still applies and is tracked separately.Root-cause analysis was done from a process dump captured via diagnostic PR #6101 (now closed).
Testing
Existing CI matrix (Stress workflow recvfuzz job) is the test: it crashes deterministically on
release/2.5today and should stop crashing with this change. Verified locally that the Debug x64 schannel build succeeds.Documentation
No documentation impact.