fuzz: connman fuzz target: runtime error: null pointer passed as argument 2, which is declared to never be null #33643

# echo 'XGFkZAAAAGRkZWXuXP/fcGcqb2hlcirYfg9D/uXc5eXcRZJ55eXl5eXl5eXlIiL19QAFABD3XERc
AVxhYQcAAADl5f//5eVhYWHl5eX//+Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl
5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eX/Km8xMTQyMjgxMUMKYWFhYWFhYQAAAAAA
YWFhYWFhYWFhYWFhYWFhe2FhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh8mWkovx0AAAA
AAAAAGFhYWFhYWFhYWFhgKoL//v/Kv/////l5eXl5f//ZGRy5eX//2Ry5eX///9kZHLl5f//ZHLl
5f//5eXl5eXl5eXl5Wfl//9kZHLl5f//ZHLl5f///2RkcuXl//9kcuXl//8=' | base64 --decode > ./crash_cm_1cfcffc33a

# UBSAN_OPTIONS="suppressions=$(pwd)/test/sanitizer_suppressions/ubsan:print_stacktrace=1:halt_on_error=1:report_error_type=1" FUZZ=connman ./bld/bin/fuzz -runs=1  ./crash_cm_1cfcffc33a 
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 2899209193
INFO: Loaded 1 modules   (597578 inline 8-bit counters): 597578 [0x62ee33b00588, 0x62ee33b923d2), 
INFO: Loaded 1 PC tables (597578 PCs): 597578 [0x62ee33b923d8,0x62ee344b0878), 
./bld/bin/fuzz: Running 1 inputs 1 time(s) each.
Running: ./crash_cm_1cfcffc33a
./src/test/fuzz/util/net.cpp:337:43: runtime error: null pointer passed as argument 2, which is declared to never be null

Originally posted by @maflcko in #28584 (review)

cc @vasild

Couldn't reproduce, but is pretty obvious, should be fixed by #33644

Did I base64 decode wrongly in some way (I had to manually remove the newlines from the command above)?

SHA256 (crash_cm_1cfcffc33a) = 4ac50f0fa637d94fa48430e371f51ae97bb34fd99261a11e78daaa283f620a3b

The sha256 looks right. Maybe the newlines are interacting somehow with your terminal or they are not stripped by your base64?

$ echo 'XGFkZAAAAGRkZWXuXP/fcGcqb2hlcirYfg9D/uXc5eXcRZJ55eXl5eXl5eXlIiL19QAFABD3XERc
AVxhYQcAAADl5f//5eVhYWHl5eX//+Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl
5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eX/Km8xMTQyMjgxMUMKYWFhYWFhYQAAAAAA
YWFhYWFhYWFhYWFhYWFhe2FhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh8mWkovx0AAAA
AAAAAGFhYWFhYWFhYWFhgKoL//v/Kv/////l5eXl5f//ZGRy5eX//2Ry5eX///9kZHLl5f//ZHLl
5f//5eXl5eXl5eXl5Wfl//9kZHLl5f//ZHLl5f///2RkcuXl//9kcuXl//8=' | base64 --decode | sha256sum 
4ac50f0fa637d94fa48430e371f51ae97bb34fd99261a11e78daaa283f620a3b  -

If the checksum of the binary, base64 decoded, stuff is the same then I must have done it properly... or at least in the same way as you :)

A possible explanation why this might only be observed in some platforms: #33644 (comment)

Just to copy the background details here, mentioned earlier:

Apart from https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3466.pdf , see also https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3322.pdf , which says:

Modify 7.26.1p3: Where an argument declared as size_t n specifies the length of the array for a function, n can have the value zero on a call to that function. Unless explicitly stated otherwise in the description of a particular function in this subclause, pointer arguments on such a call shall ... may be null pointers.