Description
Describe the bug
[Creating this to not lose the data and train of though, need double checking]
In the Windows usermode receive path implementation, a memory access seems to happen at an invalid offset.
In CxPlatDataPathUdpRecvComplete
, the first datagram of the receive payload is accessed this way:
Datagram = (CXPLAT_RECV_DATA*)(IoBlock + 1);
for ( ;
NumberOfBytesTransferred != 0;
NumberOfBytesTransferred -= MessageLength) {
CXPLAT_CONTAINING_RECORD(
Datagram, DATAPATH_RX_PACKET, Data)->IoBlock = IoBlock;
This treats the memory right after the DATAPATH_RX_IO_BLOCK
as an CXPLAT_RECV_DATA
, looks for a container DATAPATH_RX_PACKET
, 8 bytes (modulo alignment) back since DATAPATH_RX_PACKET
starts with a pointer to the IO block.
This aliases the end of the DATAPATH_RX_IO_BLOCK
.
From the computation of the pool size in DataPathInitialize
, the memory is meant to be layout this way.
┌ ┌────────┐◄──── DATAPATH_RX_IO_BLOCK
│ │ │ ──►...
│ │ │ ──►Sqe
│ │ │ ──►...
│ │ │
│ │ │
│ │ │
│ ├────────┤
┌ │ │┌──────┐◄───── DATAPATH_RX_PACKET
│ │ ││ ││ ─►IO_BLOCK*
│ │ ││ ││ ─┐ ─►CXPLAT_RECV_DATA ◄────── QUIC_RX_PACKET
│ │ ││ ││ │ ─►CXPLAT_RECV_DATA
DatagramStride │ │ │├──────┤│ │ ─►...
│ │ ││ ││ │
│ │ ││ ││ │ ClientRecvDataLength
│ │ │├──────┤│ ─┘
│ │ ││ ◄─┼┼───────── Wasted space
└ │ │└──────┘│
│ │┌──────┐│
│ ││ ││
PayloadOffset │ ││ ││
│ ││ ││
│ │├──────┤│ Repeated N times
│ ││ ││
│ ││ ││
│ ││ ││
│ ││ ││
│ │└──────┘│
│ │ │
│ │ ... │
│ │ │
│ │ │
└ ├────────┤◄──── Payload (for N*datagrams)
│ │
│ │
│ │
│ │
│ │
│ │
│ │
└────────┘
There also seem to be some wasted space in the allocation (duplicated memory space from the core layer)
Affected OS
- Windows
- Linux
- macOS
- Other (specify below)
Additional OS information
No response
MsQuic version
main
Steps taken to reproduce bug
Code inspection, needs repro under debugger
Expected behavior
No memory aliasing.
Actual outcome
Memory is aliased (seems to work by luck though)
Additional details
No response
Metadata
Metadata
Assignees
Type
Projects
Status