runtime/cgo: add support for any param and return type

[austinderek]

When using any as param or return type of an exported function, we currently have the error unrecognized Go type any. any is an alias of interface{} which is already supported.

This would avoid such change: php/frankenphp#1976

---

🔄 This is a mirror of upstream PR golang#76325

[staging]

HackerOne Code Security Review

🟢 Scan Complete: 3 Issue(s)
🟠 Validation Complete: One or more Issues looked potentially actionable, so this was escalated to our network of engineers for manual review. Once this is complete you'll see an update posted.

Here's how the code changes were interpreted and info about the tools used for scanning.

📖 Summary of Changes

The changes involve minor modifications to cgo-related files. In src/cmd/cgo/out.go, support for the "any" type was added to the `doCgoType` method, enabling "any" type conversions. The runtime/cgocall.go file remains unchanged, with no observable differences between versions.

File	Summary
src/cmd/cgo/out.go	The file remains largely unchanged. The only notable difference is the addition of support for the "any" type in the doCgoType method, which now returns a GoInterface type similar to the "error" type. This change allows the "any" type to be used in cgo type conversions.
src/runtime/cgocall.go	The files are identical. No changes were observed between the old and new versions of the runtime/cgo.go file.

ℹ️ Issues Detected

NOTE: These may not require action!

Below are unvalidated results from the Analysis Tools that ran during the latest scan for transparency. We investigate each of these for accuracy and relevance before surfacing them as a potential problem.

How will I know if something is a problem?
When validation completes, any concerns that warrant attention prior to merge will be posted as inline comments. These will show up in 2 ways:

• Expert review (most cases): Issues will be posted by experts who manually reviewed and validated them. These are real HackerOne engineers (not bots) reviewing through an integrated IDE-like tool. You can communicate with them like any other reviewer. They'll stay assigned and get notified with commit & comment updates.
• Automatically: In cases where our validation checks have highest confidence the problem is legitimate and urgent. These will include a description of contextual reasoning why & actionable next steps.

File & Line	Issue
src/runtime/cgocall.go Line 798	The added null check for type t in cgoCheckResult function may introduce a security vulnerability. If t is nil, the function returns early without performing any pointer validation checks. This could allow unpinned Go pointers to be passed to C code without validation, potentially leading to memory corruption or use-after-free vulnerabilities when the Go garbage collector moves the referenced memory.
src/cmd/cgo/gcc.go Line 1124	The addition of 'any' type handling in hasPointer function may introduce security concerns. The 'any' type (interface{}) can contain pointers and should be treated as potentially containing pointers for cgo pointer checking. However, the implementation correctly returns true, which is the safe approach for pointer checking - treating 'any' as potentially containing pointers ensures proper validation.
src/cmd/cgo/internal/test/testx.go Line 600	The new exported functions exportAnyParam and exportAnyReturn use the 'any' type (interface{}) which can accept arbitrary Go values. When these functions are called from C code, there's potential for type confusion or memory safety issues if the C code passes unexpected data types or if the Go runtime's interface handling is bypassed. The 'any' type in CGO exports may not have proper type safety guarantees when crossing the C/Go boundary.

🧰 Analysis tools

• [ ✅ ] HackerOne AI Code Analysis
• [ ✅ ] HackerOne AI Code Validation
• [ ✅ ] semgrep
• [ ✅ ] gosec
• [ ✅ ] bandit

⏱️ Latest scan covered changes up to commit 73c34cf (latest)