[Security] NULL Pointer Dereference in LC_SendHkCmd (CWE-476) — Same Pattern as CVE-2026-15352

[aqueel707]

Description:
NULL Pointer Dereference (CWE-476) in LC_SendHkCmd — Same Pattern as CVE-2026-15352

The LC_SendHkCmd() function in apps/lc/fsw/src/lc_cmds.c dereferences
LC_OperData.WRTPtr and LC_OperData.ARTPtr without NULL checks when
processing Housekeeping Telemetry requests. These pointers are set via
CFE_TBL_GetAddress() during initialization, which sets them to NULL on
failure. If table loading fails, a subsequent housekeeping request causes
a segmentation fault, crashing the LC application.

This is the same vulnerability pattern as CVE-2026-15352 in the HS
application, which was fixed in HS v7.0.1 and received CISA advisory
ICSA-26-197-03 on July 16, 2026.

To Reproduce:

1. Review lc_cmds.c, function LC_SendHkCmd() starting at line 114
2. Observe that LC_OperData.WRTPtr is dereferenced at line ~152
   without NULL check:
   LC_OperData.WRTPtr[TableIndex + 3 - i].WatchResult
3. Observe that LC_OperData.ARTPtr is dereferenced at line ~191
   without NULL check:
   LC_OperData.ARTPtr[TableIndex + 1 - i].CurrentState
4. These pointers come from CFE_TBL_GetAddress() which sets them
   to NULL on failure
5. Compile standalone reproducer with AddressSanitizer:
   gcc -fsanitize=address -g -o poc poc.c && ./poc
6. Observe SEGV crash confirming NULL pointer dereference

Expected behavior:
LC_SendHkCmd() should verify that WRTPtr and ARTPtr are non-NULL before
dereferencing, consistent with the fix applied to HS in v7.0.1 where
NULL checks were added before all pointer dereferences
(e.g., "if (EMEntryPtr != NULL && ...)").

Code snips:
// lc_cmds.c line ~152 — NO NULL CHECK before dereference
switch (LC_OperData.WRTPtr[TableIndex + 3 - i].WatchResult)

// lc_cmds.c line ~191 — NO NULL CHECK before dereference
switch (LC_OperData.ARTPtr[TableIndex + 1 - i].CurrentState)

// lc_cmds.c line ~228 — NO NULL CHECK before dereference
switch (LC_OperData.ARTPtr[TableIndex + 1 - i].ActionResult)

// Compare with HS fix (hs_cmds.c line 90):
if (EMEntryPtr != NULL && EMEntryPtr->ActionType != HS_EMTActType_NOACT)

// ASAN output from standalone PoC:
// ERROR: AddressSanitizer: SEGV on unknown address 0x000000000003
// The signal is caused by a READ memory access.
// Hint: address points to the zero page.
// #0 in LC_SendHkCmd_Vulnerable lc_null_deref_poc.c:53
// SUMMARY: AddressSanitizer: SEGV in LC_SendHkCmd_Vulnerable

System observed on:

• Code review performed on latest main branch (Aug 2, 2026)
• PoC compiled on Linux (Kali) with GCC + AddressSanitizer
• Affected: NASA LC (Limit Checker) application, all versions

Additional context:
CVE-2026-15352 (CISA ICSA-26-197-03) identified the identical pattern
in the cFS HS application — NULL pointer dereference in the housekeeping
telemetry handler. The fix in HS v7.0.1 added NULL checks before pointer
dereferences. This same fix was not applied to the LC application.

Suggested fix — add NULL guards before the loops:

if (LC_OperData.WRTPtr != NULL)
{
// existing WRTPtr loop (lines 144-170)
}

if (LC_OperData.ARTPtr != NULL)
{
// existing ARTPtr loops (lines 180-260)
}

[dzbaker]

Tagging @ddstewar for awareness.

[ddstewar]

Same question as on the other issue. Are the required changes limited to the LC? Or are there broader changes needed to multiple submodules?

[aqueel707]

The required changes are limited to LC. Specifically, LC_SendHkCmd in fsw/src/lc_cmds.c dereferences LC_OperData.WRTPtr (line 149) and LC_OperData.ARTPtr (line 191) without validating that either pointer is non-NULL. If the watchpoint or actionpoint result tables have not been successfully loaded, these pointers could be NULL when the HK command is processed.

The fix follows the same pattern applied in the HS app for CVE-2026-15352 (commit b7530d9 by @jphickey): add NULL checks on the table pointers before dereferencing. No changes are needed to other submodules — I reviewed this pattern across CS, DS, HK, MD, MM, and SC, and only LC and FM (issue nasa/FM#152) were affected.

[ddstewar]

Thank you. We will address this. It will need to be done on that repository.

[aqueel707]

Thank you. Would it be appropriate to request a CVE for this through CISA, similar to CVE-2026-15352 (ICSA-26-197-03) for the HS app? Happy to coordinate if helpful.