Added 1rtt fuzzing - #5727
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5727 +/- ##
==========================================
- Coverage 86.37% 83.93% -2.44%
==========================================
Files 60 60
Lines 18731 18731
==========================================
- Hits 16178 15721 -457
- Misses 2553 3010 +457 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…gaurasingh/1rtt-fuzz
guhetier
left a comment
guhetier
left a comment
There was a problem hiding this comment.
Please expend the PR description to explain more specifically what you added / what is not implemented for now.
guhetier
left a comment
guhetier
left a comment
There was a problem hiding this comment.
Some nitpicks, but the logic seems largely good to me.
…gaurasingh/1rtt-fuzz
|
@copilot Could you help review this? Check the field ordering of the generated frames is consistent with RFC 9000 and RFC 9001, if you have RFC 9000 and 9001 in your training data. |
|
@copilot Could you help review this? Check the field ordering of the generated frames is consistent with RFC 9000 and RFC 9001, if you have RFC 9000 and 9001 in your training data. |
Reviewed in 7b1f022: frame field ordering in recvfuzz appears consistent with RFC 9000/9001 for the implemented frame types. Specifically, STREAM (type, stream_id, offset?, length?, data), RESET_STREAM (type, stream_id, app_error_code, final_size), STOP_SENDING (type, stream_id, app_error_code), MAX_DATA (type, maximum_data), MAX_STREAM_DATA (type, stream_id, maximum_stream_data), CRYPTO (via QuicCryptoFrameEncode), ACK (via QuicAckFrameEncode), PING, and HANDSHAKE_DONE are ordered correctly. CONNECTION_CLOSE is encoded as transport close (0x1c) with error_code, frame_type, reason_length, reason_phrase, which matches RFC 9000 for that variant. |
guhetier
left a comment
guhetier
left a comment
There was a problem hiding this comment.
Looks good to me once the style is fixed.
…gaurasingh/1rtt-fuzz
## Description `QuicCryptoFrameEncode` legitimately returns `FALSE` when the CRYPTO frame would not fit in the remaining QUIC INITIAL packet payload. On `release/2.5`, `recvfuzz`'s `WriteCryptoFrame` wraps this call in `CXPLAT_FRE_ASSERT`, which crashes the process with `STATUS_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 payload `recvfuzz` budgets for it. A fuzzer should not assert on the return value of an encode helper anyway. This change just drops the `CXPLAT_FRE_ASSERT` wrapper, matching the behavior already present on `main` (commit `cc81b151b`, PR #5727). The TODO on `main` about 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.5` today and should stop crashing with this change. Verified locally that the Debug x64 schannel build succeeds. ## Documentation No documentation impact. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Description
Implemented 1rtt fuzzing in recvfuzz tool
Fixes #5721 .
Purpose
Fuzzing is done to find vulnerabilites
Testing
Locally
Documentation
No