Open grandnew opened 10 months ago
Dear maintainers, what's the possible reason for this bug? @fragmede @rubenk
You use two GoBGP daemons?
You use two GoBGP daemons?
No, only the under-test node uses the GoBGP daemon.
What BGP daemon other side?
What BGP daemon other side?
The other side is a fuzzer that continuously generates BGP packets and sends them to the under-test node for testing. @fujita
CVE-2023-46565 was assigned to this issue.
Hello together,
I looked into the code and found a possible reason for the segv message (unfortunate I do not have time to test the pcap stream against a fixed version to confirm my assumptions), anyway here are my thoughts:
The function (h *fsmHandler) recvMessageWithError() calls hd.DecodeFromBytes
which parses the bytes into BGPHeader, but does not check the type. Later the function recvMessageWithError() calls ParseBGPBody, which actually calls parseBody which checks the header type and if it is unknown, it returns nil and an error.
Thus the check for an error is true and it calls handlingError with m being a nil BGPMessage and the function deferences a nil pointer.
What do you think about it, does this make sense? Could this be the reason for the segv?
I triggered a SEGV bug when fuzzing gobgp.
The config of the under-test node is as follows, and its IP is
10.0.255.6
The fuzzing node is deployed on
10.0.255.5
.The log snippet around the crash point:
The full logs and network capture are as attached.
SEGV_debugMode.log SEGV_network_capture.pcap.zip