fuzz: don't connman.ReceiveMsgFrom oversized msg #35880

pull instagibbs wants to merge 1 commits into bitcoin:master from instagibbs:2026-08-no_over_msg_tx changing 1 files +5 −0

instagibbs commented at 1:36 PM on August 4, 2026: member

Got a report that tripped it. As this will never happen in p2p, avoid it.

INFO: Running with entropic power schedule (0xFF, 100).
	INFO: Seed: 4207564465
	INFO: Loaded 1 modules   (531453 inline 8-bit counters): 531453 [0x5ae1af7ab4c0, 0x5ae1af82d0bd),
	INFO: Loaded 1 PC tables (531453 PCs): 531453 [0x5ae1af82d0c0,0x5ae1b0049090),
	/mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_bitcoin-core_fcaf00df4dbc83b967efedfb94c0da52db5f507f/revisions/p2p_private_broadcast: Running 1 inputs 100 time(s) each.
	Running: /mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-7374a74f5b473b761282ebac8029bef22b32b1cd
	p2p_private_broadcast: test/util/net.cpp:93: void ConnmanTestMsg::NodeReceiveMsgBytes(CNode &, std::span<const uint8_t>, bool &) const: Assertion `node.ReceiveMsgBytes(msg_bytes, complete)' failed.
	==251== ERROR: libFuzzer: deadly signal
	    [#0](/bitcoin-bitcoin/0/) 0x5ae1adc5adf4 in __sanitizer_print_stack_trace /src/llvm-project/compiler-rt/lib/ubsan/ubsan_diag_standalone.cpp:31:3
	    [#1](/bitcoin-bitcoin/1/) 0x5ae1adbceff8 in fuzzer::PrintStackTrace() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5
	    [#2](/bitcoin-bitcoin/2/) 0x5ae1adbb1b45 in fuzzer::Fuzzer::CrashCallback() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:231:3
	    [#3](/bitcoin-bitcoin/3/) 0x7e8bc7ef741f in libpthread.so.0
	    [#4](/bitcoin-bitcoin/4/) 0x7e8bc7ceb00a in __libc_signal_restore_set /build/glibc-B3wQXB/glibc-2.31/sysdeps/unix/sysv/linux/internal-signals.h:86:3
	    [#5](/bitcoin-bitcoin/5/) 0x7e8bc7ceb00a in raise /build/glibc-B3wQXB/glibc-2.31/sysdeps/unix/sysv/linux/raise.c:48:3
	    [#6](/bitcoin-bitcoin/6/) 0x7e8bc7cca858 in abort /build/glibc-B3wQXB/glibc-2.31/stdlib/abort.c:79:7
	    [#7](/bitcoin-bitcoin/7/) 0x7e8bc7cca728 in __assert_fail_base /build/glibc-B3wQXB/glibc-2.31/assert/assert.c:94:3
	    [#8](/bitcoin-bitcoin/8/) 0x7e8bc7cdbfd5 in __assert_fail /build/glibc-B3wQXB/glibc-2.31/assert/assert.c:103:3
	    [#9](/bitcoin-bitcoin/9/) 0x5ae1ae9bd015 in NodeReceiveMsgBytes bitcoin-core/src/test/util/net.cpp:93:5
	    [#10](/bitcoin-bitcoin/10/) 0x5ae1ae9bd015 in ConnmanTestMsg::ReceiveMsgFrom(CNode&, CSerializedNetMsg&&) const bitcoin-core/src/test/util/net.cpp:119:9
	    [#11](/bitcoin-bitcoin/11/) 0x5ae1adfff8f7 in p2p_private_broadcast_fuzz_target(std::__1::span<unsigned char const, 18446744073709551615ul>) bitcoin-core/src/test/fuzz/p2p_private_broadcast.cpp:235:27
	    [#12](/bitcoin-bitcoin/12/) 0x5ae1ae263e23 in operator() /usr/local/include/c++/v1/__functional/function.h:274:12
	    [#13](/bitcoin-bitcoin/13/) 0x5ae1ae263e23 in operator() /usr/local/include/c++/v1/__functional/function.h:772:10
	    [#14](/bitcoin-bitcoin/14/) 0x5ae1ae263e23 in test_one_input bitcoin-core/src/test/fuzz/fuzz.cpp:86:5
	    [#15](/bitcoin-bitcoin/15/) 0x5ae1ae263e23 in LLVMFuzzerTestOneInput bitcoin-core/src/test/fuzz/fuzz.cpp:214:5
	    [#16](/bitcoin-bitcoin/16/) 0x5ae1adbb322d in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:619:13
	    [#17](/bitcoin-bitcoin/17/) 0x5ae1adb9cf42 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:329:6
	    [#18](/bitcoin-bitcoin/18/) 0x5ae1adba2e10 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:865:9
	    [#19](/bitcoin-bitcoin/19/) 0x5ae1adbcf9a2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
	    [#20](/bitcoin-bitcoin/20/) 0x7e8bc7ccc082 in __libc_start_main /build/glibc-B3wQXB/glibc-2.31/csu/libc-start.c:308:16
	    [#21](/bitcoin-bitcoin/21/) 0x5ae1adb9602d in _start

fuzz: don't connman.ReceiveMsgFrom oversized msg bb19f1da19
DrahtBot added the label Fuzzing on Aug 4, 2026
DrahtBot commented at 1:36 PM on August 4, 2026: contributor



The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.



Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35880.



Reviews

See the guideline and AI policy for information on the review process.

Type Reviewers

ACK maflcko, sedited, w0xlt

Approach NACK l0rinc

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.
fanquake requested review from marcofleon on Aug 4, 2026
sedited commented at 1:54 PM on August 4, 2026: contributor

Do you know which one of the consumers are producing the oversized message here?
maflcko commented at 1:55 PM on August 4, 2026: member
https://issues.oss-fuzz.com/issues/542252217

clusterfuzz-testcase-minimized-p2p_private_broadcast-5719097678299136.bin.not.txt

cmd: FUZZ=p2p_private_broadcast ./bld-cmake/bin/fuzz -runs=1 ./clusterfuzz-testcase-minimized-p2p_private_broadcast-5719097678299136.bin.not.txt

regression: https://github.com/bitcoin/bitcoin/compare/18c05d93016b28a9afd4c716dfe00b6e0accb30b...d1d85263f8ebb47ad4d6126ff992d4915dda026b

review ACK bb19f1da19c1141787bf24363938c0d15f0550b5 🔱

<details><summary>Show signature</summary>

Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: review ACK bb19f1da19c1141787bf24363938c0d15f0550b5 🔱
2Fu26OG1HhTpDZQZjHKF3yo+AGHh9YArnF/e2uqqG5V8HQ+2nkUOGqQhMBWvIU93pvXxDbQpth7hlNqFhRd4Dw==
```
</details>
maflcko added this to the milestone 32.0 on Aug 4, 2026
fanquake added the label Private Broadcast on Aug 4, 2026
fanquake commented at 1:57 PM on August 4, 2026: member

cc @vasild @andrewtoth
instagibbs commented at 2:04 PM on August 4, 2026: member

@sedited its in the comment: ConsumeTransaction
sedited approved
sedited commented at 2:06 PM on August 4, 2026: contributor

ACK bb19f1da19c1141787bf24363938c0d15f0550b5
w0xlt commented at 7:27 PM on August 4, 2026: contributor

ACK bb19f1da19c1141787bf24363938c0d15f0550b5
l0rinc changes_requested
l0rinc commented at 7:29 PM on August 4, 2026: contributor

I ran into the same missing outbound transport checks a while ago and have been preparing a production fix. I haven't proposed it upstream yet because I keep finding corner cases I don't fully understand.

As this will never happen in p2p, avoid it

This seems to be true for the specific oversized inbound transaction generated by this harness, but too broad for the send path. We even have a functional test to send a max + 1 byte payload through sendmsgtopeer and expects the remote peer to disconnect: https://github.com/bitcoin/bitcoin/blob/90ce21e21d09e27c9a02b187e795e03052e12dd3/test/functional/rpc_net.py#L449-L452

I don't think we should silence the fuzzer (I keep finding valid bugs by expanding constrained ranges). The send path should enforce the same wire limits, with unit and functional coverage if possible (working on it, will ping here when I'm confident about the fix).

So it's an Approach NACK, I'll push the follow-up as soon as I understand the remaining edge cases.
l0rinc referenced this in commit d849c8e97c on Aug 4, 2026
l0rinc commented at 10:37 PM on August 4, 2026: contributor

Fixed in https://github.com/bitcoin/bitcoin/pull/35888
ajtowns commented at 12:04 AM on August 5, 2026: contributor

The approach in #35888 doesn't make sense to me -- I would have expected something more along the lines of if (!Assume(IsMessageWithinLimits(msg))) return false; because it's always a bug if we're passing bad messages to those functions in production code. Such a check would presumably require this PR or something similar, though.

(I keep finding valid bugs by expanding constrained ranges)

I don't see how your proposal helps with that particularly -- the sending side will still refuse to send oversized messages in 35888, so this shouldn't help explore behaviour on the receiving side via round trips; and fuzzers "should" just be able to give oversized raw data streams anyway.