fix(libkernel): return EFAULT from getsockname and getpeername without a length pointer

[Bonjourcestmatt]

What

getsockname and getpeername with a NULL length pointer now fail with EFAULT (14) before the descriptor is looked up, so an invalid descriptor with a NULL length reports EFAULT instead of EBADF. FreeBSD 11.4 (sys/kern/uipc_syscalls.c, release/11.4.0): getsockname1() and getpeername1() start with error = copyin(uap->alen, &len, sizeof(len)); and only then call kern_getsockname() / kern_getpeername(), where getsock_cap() rejects a bad descriptor. A NULL address with a valid length pointer still fails with EFAULT after the lookup, so an invalid descriptor there still gives EBADF.

Overlap: no open PR changes getsockname_nid_postfix or getpeername_nid_postfix (checked the diffs of the open PRs listed by tools/pr_overlap.py; #6884 and #7090 only call them in tests/other code).

Tested

• Windows 11, WinLibs GCC 15.2.0 UCRT, Release: guest_socket_descriptors_tests has a new AddressQueryErrors case (EFAULT with a NULL length on a valid and on an invalid descriptor, EBADF with a valid length on an invalid descriptor) and passes; full non-GPU suite 757 of 758, the one failure (patched_libraries) passed on two reruns alone, so it is flaky under the parallel run; python tools/check_conventions.py --base origin/main passes.
• I did not run the new checks against main without the fix; the invalid-descriptor checks fail there by reading the old code (the lookup came first and returned 9).
• Not run: Linux and macOS, no console. Only the FreeBSD source was used as reference; the console's behaviour is unverified.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw; no silent stubs added
• No notes, investigation .md files or images added to the repository
• New third-party code is a submodule built from source (none added)
• Generic behaviour, not specific to one title
• Depends on: none
• Fixes: none
• Unblocks: none
• GPUs tested: n/a
• AI-assisted: yes

AI-assisted: yes

🤖 Generated with Claude Code

[github-actions]

Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.

Pull request	Shared files not compared
PR 5021	core/libs/prx/libkernel/Socket/src/Udp.cpp
PR 6044	core/libs/tests/GuestSocketDescriptors.cpp
PR 6977	core/libs/prx/libkernel/Socket/src/Udp.cpp
PR 7075	core/libs/prx/libkernel/Socket/src/Udp.cpp
PR 7088	core/libs/prx/libkernel/Socket/src/Udp.cpp
PR 7129	core/libs/prx/libkernel/Socket/src/Udp.cpp
PR 7201	core/libs/prx/libkernel/Socket/src/Udp.cpp
PR 7332	core/libs/prx/libkernel/Socket/src/Udp.cpp

[wachi35676]

Ran the negative control on Windows 11 (MinGW GCC 15.2) and Ubuntu 24.04 (GCC 13.3), with this PR merged onto main 9f25d0bf5. With only GuestSocketDescriptors.cpp from this PR, guest_socket_descriptors aborts on main on both. With the PR it passes, and the socket/sce_net set passes (Windows 38/38, Linux 26/26).

Two neighbouring cases in the same lines still differ from release/11.4.0. They predate this PR. I mention them because the description says a NULL address with a valid length "still fails with EFAULT after the lookup", and that only holds for a non-zero length on a connected socket. Probes at this head:

• getsockname(fd, NULL, &len) with len == 0 gives -1/EFAULT. FreeBSD skips the copyout when the length is 0 (L1554) and returns 0.
• getpeername on an unconnected TCP socket with a NULL address and len = 16 gives EFAULT. FreeBSD returns ENOTCONN from kern_getpeername (L1683) before any copyout. With a real buffer this PR already gives 57.

AI-assisted: yes (Claude Code); results above were run on this machine.