Context

The 2026-05-09 internal security audit (tracked in maintainer notebook SECURITY-AUDIT.md) explicitly flagged two areas as "sampled lightly — worth a deeper look":

VirtualAudioBridge (macOS) — shared-memory layout and race conditions.
RigctlPty.cpp — PTY allocation, could have similar tempfile issues to H2.

The H2 fix landing for the Linux DAX FIFO path (GHSA-x8xf-4g5v-ppf9) addresses local-user audio injection on Linux. The same threat model — local user reading or writing audio paths they shouldn't — may apply on macOS via the VirtualAudioBridge shared-memory ring buffers, and may apply to the rigctld PTY allocation on either platform.

Areas to audit

1. src/core/VirtualAudioBridge.cpp + HAL plugin (macOS)

The macOS DAX path uses shared-memory ring buffers between AetherSDR (the GUI app, running as the user) and the HAL plugin (running inside the macOS coreaudiod daemon, root-ish privileges). Threat model questions:

• Shmem segment ownership and permissions: what user owns the shared-memory segment? What mode? Can another local user (e.g., on a multi-user Mac) attach to the segment and read RX audio or write TX audio?
• Ring-buffer index races: the ring-buffer protocol has read/write index pointers updated atomically. If another process is allowed to attach, can it manipulate the indices to cause AetherSDR or the HAL plugin to misread state?
• HAL plugin update path: when AetherSDR ships a new HAL plugin version, how is the old one invalidated? Stale plugin running alongside a new app — what's the security shape?

2. src/core/RigctlPty.cpp (Linux + macOS)

The rigctld PTY allocation may have similar /tmp-style tempfile or symlink issues to H2. Per the audit:

• Where is the PTY allocated? /dev/pts/ (kernel-mediated, fine) or via openpty() returning a slave path that the user creates a symlink at?
• What permissions are on the symlink/slave-path? Mode 0666 vs 0600 etc.
• TOCTOU between PTY allocation and any subsequent chmod/ln calls.

Method

Same approach as the May 9 audit:

1. Read each file end-to-end, not just spot-check.
2. Trace each external attack surface: who writes to which path, with what permissions, who can read it.
3. Cross-check against the local-user threat model: "on a shared Mac/Linux workstation, can user B see or manipulate user A's audio path?"
4. File any findings as DRAFT GitHub Security Advisories (the project convention; see GHSA-7gvg-x594-pprq through GHSA-ccrg-j8cp-qhc4 for examples).
5. Publication held until fixes land in a release tag, per project disclosure norm.

Effort

~1 hour per file for a focused read. Two files = half-day total.

Pickup

Maintainer or AetherClaude — both have audit-pass capability. If filing this as aetherclaude-eligible, agent should produce findings + draft advisories rather than auto-implementing fixes.

Why this is queued (not done with H2)

The H2 fix is well-scoped to the Linux FIFO path. Bundling a macOS shmem audit into the same PR would scope-creep the patch and delay landing. Better engineering hygiene to land the Linux fix, then come back for the platform-parallel review with a clean head.

73, Jeremy KK7GWY & Claude (AI dev partner)