libcglue select() overruns native socket bitmaps when socket IDs reach 64

Open
  • Is something wrong?
#401 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
42/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c
Domain
backend, networking

Research direction

Start with src/libcglue/select.c, especially the SCE_FD_SET macro and the read- and write-side failure branches. Trace how libc descriptors map to native socket IDs and how sceNetInetSelect() uses its bitmaps and nfds. The issue reports a local adapter and host reproductions; inspect the focused reproducer and adapter changes if available. Done means native IDs through 255 are handled without overrunning buffers, the public fd_set ABI is preserved, and firmware errors propagate correctly.

Written by the indexing model from the issue text.

Description

Summary

src/libcglue/select.c uses newlib's public fd_set for the bitmaps passed to sceNetInetSelect(). With the installed PSP toolchain, FD_SETSIZE is 64 and sizeof(fd_set) is 8 bytes. However, SCE_FD_SET indexes those bitmaps using native PSP socket IDs, with an 8-bit mask.

A valid native socket ID of 98 therefore writes past these stack buffers, even when the application's libc descriptor is only 8. This appears to explain network failures that start after repeated socket creation.

Reviewed source: select.c at 6ef2b21.

Out-of-bounds access

The native bitmaps are declared as:

fd_set scereadfds, scewritefds;

But the macro uses:

#define SCE_FD_SET(n, p) \
    ((p)->fds_bits[((n) & 0xFF) / _NFDBITS] |= (1 << ((n) % _NFDBITS)))

On PSP, _NFDBITS is 32. For native ID 98, this accesses word 3, at byte offset 12, outside an 8-byte fd_set. The following firmware call also receives nfds = 99 with this undersized bitmap.

This is separate from the public descriptor limit: libcglue maps a small libc descriptor to a larger native socket ID. Increasing FD_SETSIZE in only the library is not sufficient, because copying the resulting larger public fd_set back into callers would change the ABI.

Real-device observations

While debugging an application with PSPLink:

  • The application descriptor was 8; __descriptormap[8]->descriptor was 98.
  • The write-side sceNetInetSelect() returned -1. Calling sceNetInetGetErrno() in that same paused request thread returned 9 (EBADF).
  • The application showed curl errors 43 (CURLE_BAD_FUNCTION_ARGUMENT) and later 7 (CURLE_COULDNT_CONNECT). These are application-level symptoms; the out-of-bounds indexing above is the concrete source defect.

Environment: GCC 15.2.0, curl 8.10.1, mbedTLS 2.28.10. The application link map confirmed the original select() came from libcglue.a(select.o). The reviewed commit above identifies the source inspected, not an asserted revision of the installed SDK.

Related error-handling defects

In the write-side failure branch, errno is not updated from sceNetInetGetErrno(), unlike the read-side branch. A previous connect() error such as EINPROGRESS can therefore survive a failed select() call. A host mock of the upstream function reproduced this.

Also, setting count = -1 does not stop the descriptor loop. Later readiness can increment it back to zero and hide the failure; this was reproduced with mocked firmware results as well.

Local fix and validation

A project-local adapter uses separate 256-bit native bitmaps, fully initializes them, preserves the public fd_set ABI, and propagates firmware errors immediately with the correct errno.

Validation of that adapter:

  • Host tests with AddressSanitizer and UndefinedBehaviorSanitizer cover native IDs 0, 31, 32, 63, 64, 98, 127, 128 and 255, stale errno, hard-error propagation and zero timeout.
  • On the real PSP, 80 consecutive UDP socket open/select-for-write/close cycles passed. All 80 native IDs were >=64, with a maximum of 180; failures: 0. Networking was already initialized by the application.

The 80-cycle result validates the corrected adapter; it is not a claim that the unpatched SDK was run through the same full loop. Extended application/video testing of the SDK-level fix is still pending.

Would a dedicated native socket bitmap, kept separate from newlib's public fd_set, be the preferred upstream fix? I can provide the focused reproducer and adapter changes if useful.

Dominant language
C
Stars
1.2k
Forks
190
Avg merge
1d 15h
Merged PRs (30d)
12

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pspdev/pspsdk

All issues in pspdev/pspsdk

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.