Skip to content

Fix CoreFoundation number interop ABI in Apple proxy handling - #135089

Merged
vitek-karas merged 1 commit into
dotnet:mainfrom
vitek-karas:vitek-karas-cfnumber-proxy-crash
Oct 5, 2026
Merged

vitek-karas merged 1 commit into
dotnet:mainfrom
vitek-karas:vitek-karas-cfnumber-proxy-crash

Conversation

@vitek-karas

@vitek-karas vitek-karas commented Oct 2, 2026 •

Copy link
Copy Markdown
Member

Apple proxy handling can crash in CFNumberGetValue when running under the CoreCLR interpreter. CFNumberType was declared as a 32-bit enum, but native CoreFoundation uses CFIndex, which is 64-bit on all supported .NET Apple targets. The simulator repro received 0x100000009 instead of the requested type value 9.

This fixes the native declaration by using a long-backed enum and a byte return matching Apple's one-byte Boolean. No proxy logic or interpreter implementation changes are needed.

Adds six Apple-only theory cases to the existing HTTP unit-test project. They evaluate an in-memory PAC script and exercise the source-linked production CFProxy.PortNumber implementation, covering ports 1, 80, 443, 8080, 65535, and DIRECT. They require neither system proxy changes nor network connections.

Validation

  • Before product changes, reproduced the crash on an iOS 26.5 arm64 simulator through the actual production MacProxy PAC callback. The new regression also crashed against the unfixed declaration. With the fix, the original repro completed all ten lookups.
  • Full iOS simulator unit suite under the CoreCLR interpreter: 2,558 passed, 40 existing skips; all six new cases passed.
  • Full macOS unit suite: 2,683 passed, 4 existing skips. After moving the new source-inclusion group to the end of the project, the targeted regression was rebuilt and rerun: 6 passed.
  • macOS functional suite: 4,766 passed, 43 skipped, 3 IPv6 link-local failures. All three failures also reproduced against the exactly unfixed production declaration.

Resolves #134617

Note

This pull request was prepared with GitHub Copilot.

Match CFNumberType to the 64-bit CFIndex used by supported Apple targets and CFNumberGetValue to the native one-byte Boolean return. Add network-independent PAC proxy-port regression coverage using the shared production interop.

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

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

@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.

@vitek-karas
vitek-karas merged commit c700290 into dotnet:main Oct 5, 2026
87 checks passed
@vitek-karas

Copy link
Copy Markdown
Member Author

/backport to release/11.0

@github-actions

github-actions Bot commented Oct 5, 2026

Copy link
Copy Markdown
Contributor

Started backporting to release/11.0 (link to workflow run)

JulieLeeMSFT pushed a commit that referenced this pull request Oct 5, 2026
…andling (#135198)

Backport of #135089 to release/11.0

/cc @vitek-karas

## Customer Impact

- [x] Customer reported
- [ ] Found internally

#134617
Crash using SocketsHttpHandler on a network with proxy configured. Seems
to only repro on iOS with CoreCLR runtime.

## Regression

- [x] Yes
- [ ] No

Compared to .NET 10 this is a regression. .NET 10 uses mono runtime. The
bug exists there as well, but the different runtime seems to not cause
the crash here (tested locally that the same code works on .NET 10 while
it crashes on .NET 11) - the crash can be masked if the runtime uses
zero-initialized memory for the interop calls, which is likely with
mono's interpreter.

## Testing

New test which closely mimics customer reported behavior. Validated that
the new test fails on unfixed runtime with the same failure as customer
reporter. After the fix the test passes.

## Risk

Low - the change only affects the code which crashes - before the change
the code would always crash, so fixing it doesn't introduce a behavior
change.

**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.

Co-authored-by: Vitek Karas <10670590+vitek-karas@users.noreply.github.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
@dotnet-milestone-bot dotnet-milestone-bot Bot added this to the 12.0-preview1 milestone Oct 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[iOS][CoreCLR] SIGSEGV in CFNumberGetValue from MacProxy: CFNumberType is passed as 32-bit, but the native type is CFIndex

2 participants