Skip to content

[release/11.0] Guard against empty remote address on macOS accept - #133566

Open
github-actions[bot] wants to merge 1 commit into
release/11.0from
backport/pr-131869-to-release/11.0
Open

[release/11.0] Guard against empty remote address on macOS accept#133566
github-actions[bot] wants to merge 1 commit into
release/11.0from
backport/pr-131869-to-release/11.0

Conversation

@github-actions

@github-actions github-actions Bot commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

Backport of #131869 to release/11.0

/cc @wfurt

Customer Impact

  • Customer reported
  • Found internally

on macOS Accept() can succeed but fails to provide remote address at the same time. We do not handle the condition right and we may end up in permanently broken state in some cases.

Regression

  • Yes
  • No

Testing

new test was added as Ewell as the fix was verify by customer based on the main branch fix.

Risk

low. This just checks for error and swallows the exception

IMPORTANT: If this backport is for a servicing release, please verify that:

  • For .NET 8 and .NET 9: The PR target branch is release/X.0-staging, not release/X.0.
  • For .NET 10+: The PR target branch is release/X.0 (no -staging suffix).

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

Fixes #121848

## Problem

On macOS, when a peer connects to an `AF_INET6` listening socket and
immediately resets the connection (`SO_LINGER=0`), `accept(2)` returns a
valid file descriptor but leaves the remote sockaddr buffer untouched
and reports `addrlen=0`. This kernel behavior was measured with a plain
C repro in the [issue
comment](#121848 (comment))
and does not depend on dual-mode or `IPV6_V6ONLY`.

The 2024 fix (#108616) guarded the `EndPoint.Create` call inside
`FinishOperationAccept` on the Unix path, but the shared
`FinishOperationSyncSuccess` in
[`SocketAsyncEventArgs.cs`](https://github.com/dotnet/runtime/blob/main/src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEventArgs.cs#L1016)
calls `Create` a second time on the same zero-sized `SocketAddress` and
throws `ArgumentException`. For Kestrel this kills the accept loop
permanently while the process stays alive and the port stays bound.

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

@wfurt wfurt added this to the 11.0.0 milestone Sep 10, 2026
@wfurt wfurt self-assigned this Sep 10, 2026
@wfurt wfurt added the Servicing-consider Issue for next servicing release review label Sep 10, 2026
@dotnet-policy-service

Copy link
Copy Markdown
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-System.Net.Sockets Servicing-consider Issue for next servicing release review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant