[FIX] Fix unchecked fopen() and alloc_demuxer_data() return values in process_hex() #2211
[FIX] Fix unchecked fopen() and alloc_demuxer_data() return values in process_hex() #2211NexionisJake wants to merge 1 commit into
fopen() and alloc_demuxer_data() return values in process_hex() #2211Conversation
…ss_hex() - Add NULL check for fopen() return; call fatal() with appropriate error code if the file cannot be opened, preventing a segfault on fgets(). - Add NULL check for alloc_demuxer_data() return; close the already-opened file handle before calling fatal() to avoid a resource leak. Fixes CCExtractor#2201
CCExtractor CI platform finished running the test files on linux. Below is a summary of the test results, when compared to test for commit 03ad9e8...:
Your PR breaks these cases:
NOTE: The following tests have been failing on the master branch as well as the PR:
Congratulations: Merging this PR would fix the following tests:
It seems that not all tests were passed completely. This is an indication that the output of some files is not as expected (but might be according to you). Check the result page for more info. |
CCExtractor CI platform finished running the test files on windows. Below is a summary of the test results, when compared to test for commit 03ad9e8...:
Your PR breaks these cases:
NOTE: The following tests have been failing on the master branch as well as the PR:
Congratulations: Merging this PR would fix the following tests:
It seems that not all tests were passed completely. This is an indication that the output of some files is not as expected (but might be according to you). Check the result page for more info. |
fopen() and alloc_demuxer_data() return values in process_hex()
|
Closing — the fopen()/alloc_demuxer_data() NULL checks in process_hex() are now covered by #2202 (just merged). Thanks for the contribution. |
fopen()return; callfatal()with appropriateerror code if the file cannot be opened, preventing a segfault on
fgets().alloc_demuxer_data()return; close thealready-opened file handle before calling
fatal()to avoid a resourceleak.
Fixes #2201
In raising this pull request, I confirm the following :
Reason for this PR:
real user has reported and for which a sample exists.
Sanity check:
.com/CCExtractor/ccextractor/blob/master/.github/CONTRIBUTING.md).
exist.
If it's just a bug fix, I have NOT added it to the changelog.
reproducible bug.
Repro instructions:
process_hex()insrc/lib_ccx/general_loop.cis reachable whenCCExtractor is built with
-DWTV_DEBUGand a.hexdump file is passedas input.
Crash 1 — NULL
fopen()(segfault onfgets):-DWTV_DEBUG.process_hex()with a filename that does not exist or is notreadable.
fris NULL, and the immediately followingfgets(line, max-1, fr)dereferences it → segfault.fatal(CCX_COMMON_EXIT_FILE_CREATION_FAILED, ...)iscalled with a clear error message before any dereference occurs.
Crash 2 — NULL
alloc_demuxer_data()(NULL dereference + fd leak):-DWTV_DEBUG.alloc_demuxer_data()to returnNULL).
datais NULL, the loop body writes intodata->buffer→ segfault;fris also leaked.fris closed first, thenfatal(EXIT_NOT_ENOUGH_MEMORY, ...)is called cleanly.The fix is two surgical NULL checks matching the existing error-handling
style used throughout the file (
EXIT_NOT_ENOUGH_MEMORY) and the restof the project (
CCX_COMMON_EXIT_FILE_CREATION_FAILED— same pattern asccx_encoders_spupng.c:1137). No other lines were changed.Note: PR #2202 also addresses this issue but omits the
fclose(fr)before the second
fatal()call, leaving a file descriptor leak. ThisPR includes that cleanup.