You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.
Describe the bug
It is not guaranteed that the source or destination arguments of strncpy for table entry names assure null-termination. Many standard functions such as strcpy, strlen, strcmp among others rely on arrays of characters to be Null terminated.
System observed on:
Imported from JSC static analysis audit
Additional context
The source table data was loaded via CFE_TBL_Load so yes it came from a file which should be considered "untrusted input". Therefore, there is no guarantee that DefEntry->Name (the source here) is null-terminated. However, the current implementation is relying on the assumption that the source and dest are the same length, and thus the function won't read more than it writes, so it's safe-ish.
Reporter Info
Justin Figueroa, Vantage Systems
The text was updated successfully, but these errors were encountered:
Checklist (Please check before submitting)
Describe the bug
It is not guaranteed that the source or destination arguments of
strncpy
for table entry names assure null-termination. Many standard functions such as strcpy, strlen, strcmp among others rely on arrays of characters to be Null terminated.Expected behavior
CFE_SB_MessageStringGet
Alternatively considered:
FM strncpy approach
However, this approach won't necessarily handle non-terminated sources properly.
Code snips
CS/fsw/src/cs_table_processing.c
Line 697 in 1ce636e
CS/fsw/src/cs_table_processing.c
Line 768 in 1ce636e
System observed on:
Imported from JSC static analysis audit
Additional context
The source table data was loaded via
CFE_TBL_Load
so yes it came from a file which should be considered "untrusted input". Therefore, there is no guarantee that DefEntry->Name (the source here) is null-terminated. However, the current implementation is relying on the assumption that the source and dest are the same length, and thus the function won't read more than it writes, so it's safe-ish.Reporter Info
Justin Figueroa, Vantage Systems
The text was updated successfully, but these errors were encountered: