Hardening pc-linux Memory Validation via Dynamic /proc/self/maps Discovery

[Shrey-N]

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I signed and emailed the appropriate Contributor License Agreement to GSFC-SoftwareRelease@mail.nasa.gov and copied cfs-program@lists.nasa.gov.
  (Sent before regarding the older version of the fix in the Checksum repo)

Describe the contribution

Mitigates a root cause of memory related Denial of Service (DoS) vulnerabilities by hardening the pc-linux PSP memory validation layer.

Previously, the pc-linux PSP initialized its memory table with a permissive 0 to SIZE_MAX range, effectively bypassing all validation and masking potential security risks during development and simulation. This PR replaces that permissive range with a platform native discovery mechanism.

Key Changes:

• Implemented CFE_PSP_InitMemoryTableFromProcMaps(), which parses /proc/self/maps at startup to identify mapped and accessible memory regions.
• CFE_PSP_MemValidateRange now correctly enforces boundaries on Linux, rejecting invalid or unmapped addresses.
• Increased CFE_PSP_MEM_TABLE_SIZE to 128 to accommodate the fragmented nature of Linux virtual memory maps.
• Added an adjacent region merging (coalescing) algorithm to optimize the usage of the memory table while maintaining precise attribute mapping (Read/Write).

Testing performed

1. Performed a clean build of pc-linux PSP to verify total compatibility and correct integration of the new /proc dependencies.
2. Instrumented InitMemoryTableFromProcMaps with console traces to confirm the SysMemoryTable accurately mirrors the process's real memory map.
3. Validated CFE_PSP_MemValidateRange behavior by confirming it correctly rejects unmapped addresses (e.g., 0xDEADBEEF) while accepting valid data/stack segments.
4. Verified that identical adjacent memory segments are successfully merged, optimizing table usage and handling Linux fragmentation efficiently.

Expected behavior changes

• CFE_PSP_MemValidateRange on the Linux platform will now correctly return failure (CFE_PSP_INVALID_MEM_ADDR) for non mapped addresses, rather than always returning CFE_PSP_SUCCESS.
• API Change: No changes to the PSP API signatures.

System(s) tested on

• Hardware: PC (x86_64)
• OS: Linux (Generic)
• Versions: cFS / PSP Latest

Additional context

Addresses the lack of platform native memory constraints on the pc-linux development platform, providing a security hardened reference for simulation based testing.

Fixes:- nasa/cFS#945

Contributor Info

• Shrey Naithani
• Note: CLA was previously submitted for the same issue to the cFS ecosystem.

[sylvesterkaczmarek]

What should happen when /proc/self/maps contains more than 128 non-mergeable readable/writable ranges? The current code logs a warning and stops parsing, leaving every later valid mapping absent from the PSP table. A normal process with enough DSOs/threads can therefore start rejecting valid addresses based purely on map order. Could this avoid installing a partial map, or use an explicit fallback/error policy when the table capacity is exceeded?

[Shrey-N]

Hiya @sylvesterkaczmarek thank you for the review, I pushed a fix to prevent installing an incomplete memory map when table capacity is exceeded. If parsing exceeds CFE_PSP_MEM_TABLE_SIZE (128) ranges or yields no entries, the table is cleared and falls back to the permissive 0 to SIZE_MAX range with a warning, matching the fopen failure behavior. I think this should resolve it :)

[sylvesterkaczmarek]

The parser now refuses to install a truncated map: overflow or an empty parse clears the partial table and falls back to the same permissive range used when /proc/self/maps cannot be opened, with a warning. That avoids map-order-dependent false rejections and resolves my concern.