fix(modulefinder): handle ENOSYS in read_safely for Kubernetes seccomp

[HrMathematiker]

Fixes #1653.

Problem

When running under Kubernetes with the default RuntimeDefault seccomp profile, process_vm_readv is blocked and returns ENOSYS (errno 38). The existing fallback in read_safely() only handles EPERM and EINVAL, so every ELF module validation fails silently.

The result: sentry_get_modules_list() returns 0 modules, debug_meta.images is absent from manually-captured events, and every stack frame shows as unknown_image in Sentry — even when debug symbols have been uploaded correctly.

When does this happen?

• Kubernetes pods using the default RuntimeDefault seccomp profile
• Docker containers (Docker default profile returns EPERM, already handled)
• Bare-metal / VMs (syscall is permitted)

Crash events via crashpad are not affected because the out-of-process handler enumerates modules from /proc/<pid>/maps directly, independent of sentry_get_modules_list().

Root cause

read_safely() in sentry_modulefinder_linux.c:

// Before
if (!rv && (errno == EPERM || errno == EINVAL)) {

// After
if (!rv && (errno == EPERM || errno == EINVAL || errno == ENOSYS)) {

Verification

Confirmed with a static test binary copied into a real K8s pod (Flatcar Linux, kernel 6.12, Seccomp: 2):

FAILED: errno=38 (Function not implemented)

Also reproduced locally using Docker with a custom seccomp profile (SCMP_ACT_ERRNO / errnoRet: 38) — the original code fails, the patched code falls back to memcpy and succeeds.

Fix

One-liner: add || errno == ENOSYS to the existing errno fallback. The address is valid in-process memory, so memcpy is safe.

[sdk-maintainer-bot]

This PR has been automatically closed. The referenced issue does not show a discussion between you and a maintainer.

To avoid wasted effort on both sides, please discuss your proposed approach in the issue first and wait for a maintainer to respond before opening a PR.

Please review our contributing guidelines for more details.

[jpnurmi]

Hi, thanks for the contribution, and sorry about the bot. 😅

What do you think, @supervacuus? The proposed fix looks good to me. Just need a changelog entry but we can fix that.

[supervacuus]

Thanks!

Please, rebase first, add a changelog entry and adapt the comment.

As with the other fallbacks, we will keep them as long as they do not lead to unnecessary crashes in other environments. These errnos are not specific to the address and as such the fallback should be fine.

Edit: I just saw that the danger comment might not be visible to you. Essentially add to changelog something like:

## Unreleased

### Fixes

- Linux: handle `ENOSYS` in the modulefinder's `read_safely()` for seccomp-restricted environments like Kubernetes. ([#1655](https://github.com/getsentry/sentry-native/pull/1655))

at the top

[supervacuus]

We can make the comment less specific/assertive about Kubernetes and phrase it in terms of the actual condition. I’d also keep the new comment focused on why ENOSYS can occur here. The sentence about failing ELF validation and missing debug_meta.images is true for the whole per-module path, not specifically for ENOSYS or the fallback, so it reads as broader module-level rationale rather than justification for adding this errno. Removing it makes the comment more precise.

Suggested change

	// Additionally, Kubernetes default seccomp profiles (RuntimeDefault) block
	// `process_vm_readv` and return `ENOSYS`, causing all ELF module
	// validations to fail and `debug_meta.images` to be absent from
	// manually-captured events.
	// Additionally, in some seccomp-restricted environments,
	// `process_vm_readv` may be unavailable and fail with `ENOSYS`.

[HrMathematiker]

Hello @supervacuus and thanks for your feedback!
I've applied your suggestion with a link to the issue and added an item to the changelog - please, take a look.