Socket connect with payload via SocketAsyncEventArgs fails

[mgravell]

Description

Appears to have been introduced here with the removal of the early pin /cc @stephentoub

WSAConnect supports connect+transmit, which is supported in SocketAsyncEventArgs, and implemented in DoOperationConnectEx - however, a critical bug stops it working when a buffer is specified, faulting with "The system detected an invalid pointer address in attempting to use a pointer argument in a call.".

This is because the code sends (IntPtr)((byte*)_singleBufferHandle.Pointer + _offset), as the payload pointer, but _singleBufferHandle is not initialized until after ConnectEx, in ProcessIOCPResult (to avoid pins in the synchronous case).

Proposed fix: pass bufferPtr instead.

This API should probably be passing bufferPtr here, which is the same address via fixed (fine for the synchronous case, and ends up pinned while fixed in the async case)

Reproduction Steps

Fails on net7.0

(note I haven't bothered with a server here; not needed for demonstration)

using var client = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
var saea = new SocketAsyncEventArgs();
saea.RemoteEndPoint = new IPEndPoint(IPAddress.Loopback, 42);
saea.SetBuffer(new byte[42]); // <== the presence of the buffer is what triggers the failure

Console.WriteLine(client.ConnectAsync(saea)); // reports false, so: not pending
Console.WriteLine(saea.SocketError); // reports Fault

Expected behavior

Connects and transmits; specifically, ConnectAsync should return true (pending), or should report false (complete) with a suitable SocketError

Actual behavior

ConnectAsync reports false (complete) with SocketError as Fault

Regression?

Yes; works in net6.0

Known Workarounds

connect without a buffer, then send afterwards

Configuration

No response

Other information

No response

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Appears to have been introduced here /cc @stephentoub

WSAConnect supports connect+transmit, which is supported in SocketAsyncEventArgs, and implemented in DoOperationConnectEx - however, a critical bug stops it working when a buffer is specified, faulting with "The system detected an invalid pointer address in attempting to use a pointer argument in a call.".

This is because the code sends (IntPtr)((byte*)_singleBufferHandle.Pointer + _offset), as the payload pointer, but _singleBufferHandle is not initialized until after ConnectEx, in ProcessIOCPResult (to avoid pins in the synchronous case).

Proposed fix: pass bufferPtr instead.

This API should probably be passing bufferPtr here, which is the same address via fixed (fine for the synchronous case, and ends up pinned while fixed in the async case)

Reproduction Steps

Requires preview CLR?

(note I haven't bothered with a server here; not needed for demonstration)

using var client = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
var saea = new SocketAsyncEventArgs();
saea.RemoteEndPoint = new IPEndPoint(IPAddress.Loopback, 42);
saea.SetBuffer(new byte[42]); // <== the presence of the buffer is what triggers the failure
// normally we would configure a callback, check the bool etc - not needed to demonstrate failure
client.ConnectAsync(saea); // BOOM!!!

Expected behavior

Connects and transmits

Actual behavior

Faults with invalid address

Regression?

Works in CLR7

Known Workarounds

connect without a buffer, then send afterwards

Configuration

No response

Other information

No response

Author:	mgravell
Assignees:	-
Labels:	area-System.Net.Sockets
Milestone:	-

[wfurt]

Is this essentially #1476? AFAIK that was never fully implemented and supported. But I assume the break was not intentional so we should look into it.

[antonfirsov]

@wfurt isn't TFO more than just "data in SYN"?

Standard TCP already allows data to be carried in SYN packets [RFC793], Section 3.4) but forbids the receiver from delivering it to the application until the 3WHS is completed.

I would assume ConnectEx allows sending data, but the 3WHS should be completed in order to receive the data, unless the TFO flag is set.

This is definitely platform-specific behavior though, on Unix the buffer is ignored in all versions.

[mgravell]

This is definitely platform-specific behavior though, on Unix the buffer is ignored in all versions.

"connects successfully without sending the buffer" would also be an acceptable outcome, if that is the documented and intended behaviour; it is odd that it is different between platforms; "fails in an obscure way if a buffer is set": not so much

[antonfirsov]

I would merge #79669 to fix the 7.0 regression and keep the Windows behavior consistent across .NET versions, and open a separate issue to document the platform differences. In my understanding, cross-platform behavior is only possible with TFO (#1476).

[mgravell]

@antonfirsov fortunately it is somewhat discoverable by checking the BytesTransferred upon completion, which arguably people should always be doing - I believe this will be zero on platforms where the connect did not include the buffer

[antonfirsov]

Reopening, to track backport, this is a regression.

[antonfirsov]

Backport PR #79866 has been merged.

[karelz]

Fixed in main (8.0) in PR #79669 and in 7.0.3 in PR #79866.