Jiri Daněk created PROTON-2957:
----------------------------------
Summary: 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
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]
