GHSA-hf2g-6j7h-98wg: klever-go: Unbounded goroutine spawn on direct-message ingress enables peer-driven DoS

networkMessenger.directMessageHandler in network/p2p/libp2p/netMessenger.go spawns a fresh goroutine for every incoming direct message before the antiflood layer makes an admission decision. There is no semaphore, throttler, or bound on concurrent in-flight spawns.

A single connected libp2p peer can open a DirectSendID stream and send well-formed TopicMessage envelopes with varying sequence numbers. Each accepted direct message reaches directMessageHandler and triggers a fresh goroutine before processor.ProcessReceivedMessage runs. This allows unbounded goroutine growth and node availability degradation from one peer.

This remains present in the latest release v1.7.17: network/p2p/libp2p/netMessenger.go:1060 still spawns go func(msg p2p.MessageP2P) before processor.ProcessReceivedMessage. I also verified current develop commit 10bcfd50, where the same spawn remains at network/p2p/libp2p/netMessenger.go:1115.

This is distinct from GHSA-74m6-4hjp-7226 and GHSA-87m7-qffr-542v. Those advisories concern MultiDataInterceptor decompression/throttler behavior. This report concerns the libp2p direct-message ingress wrapper spawning an unbounded goroutine before processor-level antiflood/admission logic runs. A patch to Batch.Decompress or MultiDataInterceptor does not bound this direct-message goroutine spawn.