[
https://issues.apache.org/jira/browse/PROTON-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Daněk updated PROTON-2957:
-------------------------------
Description:
{{pn_message_decode()}} only scans the wire-level section framing (header,
properties, delivery-annotations, message-annotations, application-properties,
body) and stores each section's raw, undecoded bytes on the {{pn_message_t}}.
It never invokes the generic AMQP codec ({{codec.c}}, {{decoder.c}}) on any of
that content -- that only happens lazily, the first time an application calls
one of the {{pn_message_instructions()}}, {{pn_message_annotations()}},
{{pn_message_properties()}}, or {{pn_message_body()}} accessors.
The fuzz-message-decode harness ({{c/tests/fuzz/fuzz-message-decode.c}}) only
ever calls {{pn_message_decode()}} and discards the result, so none of those
accessors are ever invoked and the fuzzer's input never actually reaches the
codec, despite fuzz-message-decode being one of only two targets with
continuous OSS-Fuzz history.
Proposed fix: call the four accessors above and force a full read-side
traversal of each resulting {{pn_data_t}} via {{pn_data_format()}}, then
round-trip the message back to bytes via {{pn_message_encode2()}} to also
exercise the encoder on the same content. This implements the harness's own
long-standing "FUTURE: do something like encode msg and compare again with
Data" comment.
I'll attach a PR with this change.
was:
{{pn_message_decode()}} only scans the wire-level section framing (header,
properties, delivery-annotations, message-annotations, application-properties,
body) and stores each section's raw, undecoded bytes on the {{pn_message_t}}.
It never invokes the generic AMQP codec ({{codec.c}}, {{decoder.c}}) on any of
that content -- that only happens lazily, the first time an application calls
one of the {{pn_message_{instructions,annotations,properties,body}()}}
accessors.
The fuzz-message-decode harness ({{c/tests/fuzz/fuzz-message-decode.c}}) only
ever calls {{pn_message_decode()}} and discards the result, so none of those
accessors are ever invoked and the fuzzer's input never actually reaches the
codec, despite fuzz-message-decode being one of only two targets with
continuous OSS-Fuzz history.
Proposed fix: call the four accessors and force a full read-side traversal of
each resulting {{pn_data_t}} via {{pn_data_format()}}, then round-trip the
message back to bytes via {{pn_message_encode2()}} to also exercise the encoder
on the same content. This implements the harness's own long-standing "FUTURE:
do something like encode msg and compare again with Data" comment.
I'll attach a PR with this change.
> fuzz-message-decode harness doesn't exercise the codec on decoded message
> content
> ---------------------------------------------------------------------------------
>
> Key: PROTON-2957
> URL: https://issues.apache.org/jira/browse/PROTON-2957
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Reporter: Jiri Daněk
> Priority: Major
>
> {{pn_message_decode()}} only scans the wire-level section framing (header,
> properties, delivery-annotations, message-annotations,
> application-properties, body) and stores each section's raw, undecoded bytes
> on the {{pn_message_t}}. It never invokes the generic AMQP codec
> ({{codec.c}}, {{decoder.c}}) on any of that content -- that only happens
> lazily, the first time an application calls one of the
> {{pn_message_instructions()}}, {{pn_message_annotations()}},
> {{pn_message_properties()}}, or {{pn_message_body()}} accessors.
> The fuzz-message-decode harness ({{c/tests/fuzz/fuzz-message-decode.c}}) only
> ever calls {{pn_message_decode()}} and discards the result, so none of those
> accessors are ever invoked and the fuzzer's input never actually reaches the
> codec, despite fuzz-message-decode being one of only two targets with
> continuous OSS-Fuzz history.
> Proposed fix: call the four accessors above and force a full read-side
> traversal of each resulting {{pn_data_t}} via {{pn_data_format()}}, then
> round-trip the message back to bytes via {{pn_message_encode2()}} to also
> exercise the encoder on the same content. This implements the harness's own
> long-standing "FUTURE: do something like encode msg and compare again with
> Data" comment.
> I'll attach a PR with this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
