libclamav: recover HWP3 attachments after paragraph errors - #1796
libclamav: recover HWP3 attachments after paragraph errors#1796jhumlick wants to merge 1 commit into
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 082d426cc0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (infolen < HWP3_IMAGE_INFO_SIZE) { | ||
| cli_errmsg("HWP3.x: Information Block[%llu]: Image Data block is too short: %u\n", infoloc, infolen); | ||
| return CL_EFORMAT; |
There was a problem hiding this comment.
When a document has a valid paragraph section but an undersized image block before a later attachment, returning CL_EFORMAT here immediately stops the information-block loop. Because paragraph_parse_failed remains false, the fallback at the end of hwp3_cb is also skipped, so the later attachment is never scanned as a nested file and attachment-level signatures can be bypassed. The equivalent background-image check has the same problem; these malformed blocks should be skipped safely or trigger the full recovery path rather than aborting attachment scanning.
Useful? React with 👍 / 👎.
| next = payload + infolen; | ||
| /* Requiring a valid following header further avoids treating paragraph data as a block. */ | ||
| if (!hwp3_infoblk_1_header_is_plausible(map, next)) | ||
| continue; |
There was a problem hiding this comment.
If a malformed HWP3 paragraph is followed by a complete attachment whose payload reaches EOF, next == map->len and this mandatory following-header check rejects it. This is readily produced by omitting the information-block terminator from an already malformed document; the fallback then scans only the complete HWP stream, so exact-hash and format-aware signatures for the embedded attachment do not run against the attachment layer. Treating exact EOF as a plausible end would preserve recovery for this case.
Useful? React with 👍 / 👎.
1 participant
Resynchronize with additional information blocks when malformed paragraph
metadata interrupts HWP3 parsing. Fall back to scanning the complete content
stream and validate fixed image metadata lengths to avoid underflow.
Add a regression test confirming later embedded content remains detectable.
CLAM-2953