ERROR runtime/panic.go:44 ParseMemcache(UDP) exception. Recovering, but please report this

[sstover (sam stover)]

Version 7.2.0 Packetbeat on an Ubuntu 14.0.4 host monitoring traffic on a dedicated SPAN port. Crashed on this error:

2019-08-29T18:37:54.446Z ERROR runtime/panic.go:44 ParseMemcache(UDP) exception. Recovering, but please report this. {"panic": "runtime error: index out of range", "stack": "github.com/elastic/beats/libbeat/logp.Recover\n\t/go/src/github.com/elastic/beats/libbeat/logp/global.go:105\nruntime.gopanic\n\t/usr/local/go/src/runtime/panic.go:522\nruntime.panicindex\n\t/usr/local/go/src/runtime/panic.go:44\ngithub.com/elastic/beats/packetbeat/protos/memcache.(*udpMessage).addDatagram\n\t/go/src/github.com/elastic/beats/packetbeat/protos/memcache/plugin_udp.go:316\ngithub.com/elastic/beats/packetbeat/protos/memcache.(*memcache).ParseUDP\n\t/go/src/github.com/elastic/beats/packetbeat/protos/memcache/plugin_udp.go:127\ngithub.com/elastic/beats/packetbeat/protos/udp.(*UDP).Process\n\t/go/src/github.com/elastic/beats/packetbeat/protos/udp/udp.go:76\ngithub.com/elastic/beats/packetbeat/decoder.(*Decoder).onUDP\n\t/go/src/github.com/elastic/beats/packetbeat/decoder/decoder.go:335\ngithub.com/elastic/beats/packetbeat/decoder.(*Decoder).process\n\t/go/src/github.com/elastic/beats/packetbeat/decoder/decoder.go:283\ngithub.com/elastic/beats/packetbeat/decoder.(*Decoder).OnPacket\n\t/go/src/github.com/elastic/beats/packetbeat/decoder/decoder.go:194\ngithub.com/elastic/beats/packetbeat/sniffer.(*Sniffer).Run\n\t/go/src/github.com/elastic/beats/packetbeat/sniffer/sniffer.go:210\ngithub.com/elastic/beats/packetbeat/beater.(*packetbeat).Run.func2\n\t/go/src/github.com/elastic/beats/packetbeat/beater/packetbeat.go:227"}

I have not been able to reproduce, but have tcpdump running in case it does.

[Michael_Madden]

Hello, thanks for reaching out about this packetbeat issue. Have you experienced this crash again?

Thanks.

[sstover (sam stover)]

Hi Michael - thanks for the response.

Have not reproduced yet, but we are working on a test case in our lab that we are hoping will repeatably reproduce.

Cheers.

[sstover (sam stover)]

We have reproduced the issue and determined the cause. Our vulnerability scanner sends a significant amount of memcached traffic to all IPs in our (small office subnet). The crash occurs reliably during the spike. I do have individual pcaps of the traffic (will upload a moloch screen capture), but aggregating all of them would take some time...

I believe we can close this issue, we'll simply set up a bpf filter for the vuln scanner IP, but if you need/want pcaps we can provide. I believe packetbeat should be able to handle this, but do understand if it can't.

Cheers.

[sstover (sam stover)]