[
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,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.
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,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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
