fix(security): bounds-check untrusted shmem offsets in port and libunit

[andypost]

Summary

Audit-driven shared-memory bounds-check pass (PR-B from security-audit.md / PR #10). CVE-track — bundles five findings clustered around the "trust untrusted-input-from-shmem-peer" theme.

Findings addressed

• V5 [High] chunk_id no bounds check (port_memory.c)
• V5 [High] chunk_id + nchunks overflow (port_memory.c)
• V5 [Medium] TOCTOU on shmem mmap_id lookup (port_memory.c)
• V10 [Medium] response field count*size overflow (nxt_unit.c)
• V10 [Low] sptr offset dereferenced without bounds (nxt_unit.c)

Cross-cutting helper

File-static helper nxt_port_mmap_chunk_range_valid in src/nxt_port_memory.c and two siblings in src/nxt_unit.c (nxt_unit_response_buf_size, nxt_unit_sptr_in_buf). None exported through public headers; libunit ABI unchanged (nxt_unit.h, nxt_unit_sptr.h, nxt_unit_request.h, nxt_unit_field.h struct layouts and inline-helper bodies untouched).

Notes on the TOCTOU fix

nxt_port_get_port_incoming_mmap() had a real lookup-vs-deref window: the function released process->incoming.mutex before returning, then the caller dereferenced mmap_handler->hdr and only afterwards bumped the existing atomic refcount. The fix bumps the (existing) use_count refcount under the mutex inside the lookup — no new refcount field invented. The sole caller adopts that reference; the previously-explicit handler_use(+1) at the buf-parent assignment site is now removed, and every error path between lookup and buf creation drops the lookup ref.

Test plan

• ./configure --openssl && make builds unitd clean under -Werror.
• nxt_unit.c compile-checked standalone with stock CFLAGS (-Werror).
• pytest-3 --collect-only test/ collects 898 tests (imports parse).
• Full root-required pytest run — not exercised in the worktree; needs sudo pytest-3 test/ in a normal checkout.
• Targeted libunit smoke (Python WSGI / PHP) from a runtime-equipped environment to exercise the new sptr validation on real router→app traffic.

Upstream

Same fixes apply to freeunitorg/freeunit; will forward after merge. Maintainer should consider disclosure timing — V5 chunk_id bounds is the closest to RCE-shaped finding in this bundle.

Generated by Claude Code

[gemini-code-assist]

Code Review

This pull request introduces several security hardening measures, including bounds-checking for shared-memory offsets, addressing a TOCTOU vulnerability in mmap handler refcounting, preventing integer overflows during response buffer allocation, and validating string pointers (sptrs) in incoming requests. A critical issue was identified in the nxt_unit_sptr_in_buf function, where the bounds check for the sptr struct itself is insufficient, potentially allowing an out-of-bounds read when accessing its members.

[gemini-code-assist]

The current check is insufficient to prevent an out-of-bounds read. It does not ensure that the entire nxt_unit_sptr_t struct is within the buffer before its members are accessed. For example, if sptr_off is equal to buf_size, this check passes, but sptr would point just beyond the buffer, and accessing sptr->offset would be an out-of-bounds read. A similar issue occurs if sptr is only partially inside the buffer.

To fix this, you must validate that the sptr struct itself is fully contained within the buffer.

    if (sptr_off > buf_size - sizeof(nxt_unit_sptr_t)) {
        return 0;
    }

[andypost]

Gemini's [security-critical] finding addressed in d010e207: nxt_unit_sptr_in_buf now checks sptr_off > buf_size - sizeof(nxt_unit_sptr_t) before dereferencing sptr->offset, so the struct itself is fully bounded inside the buffer before any member access. Force-pushed; build clean.