CF_CFDP_R_ProcessFd does not bound received FD PDU offset against the declared transaction file size
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 120
- Forks
- 77
- Avg merge
- 7d 18h
- Merged PRs (30d)
- 3
Description
Checklist (Please check before submitting)
- I reviewed the Contributing Guide.
- I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.
Describe the bug
CF_CFDP_R_ProcessFd() never compares fd->offset against txn->fsize. A CFDP file arrives as data, not as a command, so its offsets are attacker-controlled regardless of who is authorized to send commands.
Four FD PDUs totalling 82 bytes, 12 of them crafted, cause the receiver to write and retain a 4 GiB file for a transfer declared as 4 bytes. The transaction is reported as successful: files_recv increments, file_size_mismatch stays at 0, and the file is recorded as successfully retained.
The impact is storage exhaustion plus loss of file-length integrity, and a success report for a transfer that did not succeed. This is not a memory-safety defect; there is no sanitizer report because there is nothing for a sanitizer to catch.
The same application already enforces this bound on the sending side (cf_cfdp_s.c:302), and the file_size_mismatch counter exists for exactly this condition, but it is never reached on the receive path.
To Reproduce
- Start a CFDP receive transaction declaring a 4-byte file size.
- Send four FD PDUs, 82 bytes total. The crafted 12 bytes place a later PDU's offset beyond the declared size.
- Observe the resulting file on the receiving filesystem: 4 GiB.
- Observe the HK counters:
files_recv=+1,file_size_mismatch=+0, transaction closed as successfully retained.
A/B isolation: the identical transfer without the crafted PDU produces a 4-byte file.
PoC, crafted PDUs and captured counter output: https://gist.github.com/iiviel/019284efadec361200a7902416f88108
Expected behavior
An FD PDU whose offset + data length exceeds txn->fsize is rejected and file_size_mismatch is incremented, applying the same bound the sender already uses at cf_cfdp_s.c:302.
Code snips
fsw/src/cf_cfdp_r.c, CF_CFDP_R_ProcessFd(): no comparison of fd->offset against txn->fsize on any path.
Sender-side bound for contrast: fsw/src/cf_cfdp_s.c:302.
System observed on:
- Hardware: x86-64 and 32-bit builds
- OS: Linux
- Versions: CF v7.0.1, v7.0.0, v3.0.0, 2.2.1, reproduced on all four, on every CF branch, under CFDP class 1 and class 2, at both word sizes
Additional context
CF#499 finding 1 is in the same function but concerns a different defect with a different proposed remedy. This report is independent of it.
Reporter Info
Eva Crystal (0xiviel), XSource Security
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in fsw/src/cf_cfdp_r.c at CF_CFDP_R_ProcessFd(), then compare the sender-side bound at fsw/src/cf_cfdp_s.c:302. Reproduce the four-PDU transfer described in the issue and inspect the resulting file and HK counters. Done means an out-of-bounds FD PDU is rejected, file_size_mismatch is incremented, and the transfer is not reported as successfully retained.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- networking, security
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 74/100