[
https://issues.apache.org/jira/browse/PROTON-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18105632#comment-18105632
]
ASF GitHub Bot commented on PROTON-2957:
----------------------------------------
ide-developer commented on code in PR #450:
URL: https://github.com/apache/qpid-proton/pull/450#discussion_r3804913655
##########
c/tests/fuzz/fuzz-message-decode.c:
##########
@@ -20,11 +20,46 @@
*/
#include <stdint.h>
+#include <stdlib.h>
#include "proton/message.h"
#include "libFuzzingEngine.h"
+/*
+ * pn_message_decode() (c/src/core/message.c) only scans the wire-level
+ * section framing (header / properties / delivery-annotations /
+ * message-annotations / application-properties / body) and stashes each
+ * section's *raw*, undecoded bytes on the pn_message_t. It never calls into
+ * the generic AMQP codec (c/src/core/codec.c, decoder.c) on any of those
+ * byte ranges. That only happens lazily
> 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
> Assignee: 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]
