Skip to content

fix(forwarder): null-check allocations and fix resource leaks in quicforward#5807

Merged
guhetier merged 5 commits intomicrosoft:mainfrom
MarkedMuichiro:fix/quicforward-null-alloc
Mar 4, 2026
Merged

fix(forwarder): null-check allocations and fix resource leaks in quicforward#5807
guhetier merged 5 commits intomicrosoft:mainfrom
MarkedMuichiro:fix/quicforward-null-alloc

Conversation

@MarkedMuichiro
Copy link
Contributor

@MarkedMuichiro MarkedMuichiro commented Feb 21, 2026

Description

Fixes #5806.

In quicforward.cpp, MsQuicStream and MsQuicConnection objects are allocated with new(std::nothrow) in ConnectionCallback and ListenerCallback, but the results are never null-checked before being dereferenced. Under OOM conditions this causes a null pointer dereference and crash. The correct guard pattern already exists in MsQuicAutoAcceptListener in msquic.hpp and is applied here consistently.

Ownership notes:

  • ListenerCallback returns QUIC_STATUS_OUT_OF_MEMORY on allocation failure.
    Confirmed via listener.c that failure returns are permitted — MsQuic
    refuses the connection and retains handle ownership, so no manual cleanup
    of the raw connection handle is needed.
  • ConnectionCallback explicitly closes the raw stream handle on allocation
    failure, matching the pattern in spinquic.cpp. Sequential allocation is
    intentional — MsQuicConnection's constructor calls SetCallbackHandler
    immediately, so a consolidated null-check would risk closing a handle
    not yet owned by the caller.

Testing

No existing tests cover these OOM paths. Built successfully on Linux (GitHub Codespaces) and validated normal forwarding behavior is unaffected. Reliably triggering these paths requires fault injection that does not currently exist for this code. Happy to add coverage if maintainers have a preferred approach.

Documentation

None.

…forward

- Check MsQuicStream allocs in ConnectionCallback; close raw stream
  handle on failure instead of leaking it
- Check MsQuicConnection allocs in ListenerCallback; return
  QUIC_STATUS_OUT_OF_MEMORY so MsQuic refuses connection cleanly
- Free SendContext before CXPLAT_FRE_ASSERT fires on unexpected
  send errors in StreamCallback
@MarkedMuichiro MarkedMuichiro requested a review from a team as a code owner February 21, 2026 22:37
@codecov
Copy link

codecov bot commented Mar 2, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.67%. Comparing base (72c4d31) to head (4ced9c5).
⚠️ Report is 17 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #5807      +/-   ##
==========================================
+ Coverage   85.04%   85.67%   +0.63%     
==========================================
  Files          60       60              
  Lines       18729    18729              
==========================================
+ Hits        15928    16046     +118     
+ Misses       2801     2683     -118     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Collaborator

@guhetier guhetier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, except some nit style.

Add braces

Co-authored-by: Guillaume Hetier <hetier.guillaume@gmail.com>
@MarkedMuichiro
Copy link
Contributor Author

Looks good to me, except some nit style.

Done. Thank you!

@MarkedMuichiro MarkedMuichiro requested a review from guhetier March 2, 2026 23:11
@guhetier guhetier merged commit 6c26eab into microsoft:main Mar 4, 2026
527 of 528 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Null pointer dereference on allocation failure in quicforward

2 participants