fuzz-tests: add a test for handle_peer_error_or_warning()

[Chand-ra]

handle_peer_error_or_warning() in common/read_peer_message is responsible for parsing any incoming error or warning messages as defined in BOLT #1. Add a test for it.

Checklist

Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked:

• The changelog has been updated in the relevant commit(s) according to the guidelines.
• Tests have been added or modified to reflect the changes.
• Documentation has been reviewed and updated as needed.
• Related issues have been listed and linked, including any that this PR closes.

[Chand-ra]

@morehouse , I think this test has exposed a bug, although I'm not 100% confident.

We're injecting the fuzzer input as msg to handle_peer_error_or_warning(struct per_peer_state *pps, const u8 *msg). I've looked into this function's callers and I'm pretty sure msg is derived from the wire in most of them. I set up a similar test for the ping-pong message handler:

void run(const uint8_t *data, size_t size)
{
    u8 *pong;
    u8 *buf = tal_dup_arr(tmpctx, u8, data, size, 0);
    check_ping_make_pong(tmpctx, buf, &pong);

    clean_tmpctx();
}

and that works without any breakage.

[Chand-ra]

Hey @morehouse, like we discussed earlier, I investigated the breakage caused by this test:

common/daemon_conn.c:161:18: runtime error: member access within null pointer of type 'struct daemon_conn'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior common/daemon_conn.c:161:18 
MS: 0 ; base unit: 0000000000000000000000000000000000000000

And it looks like the breakage occurs due to common/status.c::status_send(const u8 *msg) passing an uninitialized struct daemon_conn to daemon_conn_send(struct daemon_conn *dc, u8 *msg) which then tries accessing within this pointer and causing the break.

I've faced this issue in a couple of other targets that I'm working on as well, and it doesn't take a lot of fuzzing time to pop up so I'm not sure if this is an actual bug or if I'm missing something in the target setup. I'd appreciate it if you could take a look.

[morehouse]

And it looks like the breakage occurs due to common/status.c::status_send(const u8 *msg) passing an uninitialized struct daemon_conn to daemon_conn_send(struct daemon_conn *dc, u8 *msg) which then tries accessing within this pointer and causing the break.

I ran the fuzz target with UBSAN_OPTIONS=print_stacktrace=1 to get a stack trace:

common/daemon_conn.c:161:18: runtime error: member access within null pointer of  type 'struct daemon_conn'
    #0 in daemon_conn_send common/daemon_conn.c:161:18
    #1 in status_vfmt common/status.c:154:2                                                                            
    #2 in status_fmt common/status.c:165:2                                                                             
    #3 in handle_peer_error_or_warning common/read_peer_msg.c:29:3                                                     
    #4 in run tests/fuzz/fuzz-error-warning.c:14:5                                                                     

From this it's clear the initialized global is status_conn. This is a big hint that the fuzz target isn't initializing everything it needs to.

I think probably you need to add the following lines to the target's init:

lightning/tests/fuzz/connectd_handshake.h

Lines 73 to 75 in ad2dc97

	int devnull = open("/dev/null", O_WRONLY);
	assert(devnull >= 0);
	status_setup_sync(devnull);

[Chand-ra]

This test is now ready to review.