Suricata

I am able to reproduce, but not in the context of any filestore configuration. Instead by enabling the body-md5 features of the SMTP parser.

Jason Ish wrote in #note-4:

I am able to reproduce, but not in the context of any filestore configuration. Instead by enabling the body-md5 features of the SMTP parser.

That is correct.

I was trying to say that it's not happening due to MD5 hashing in general, and that this is the only code path we've gotten the crash for.
The comment was from before we had a reproduction PCAP and associated core dump, just the libunwind callstack.

Can this pcap end up in public tests?

So quick analysis.. At util-decode-mime.c:2355, SCMd5Update is being called with a NULL md5 context. SCMd5Update has the expectation that its self object is valid.

So while this is a state-machine type error in the MIME decoding, I'm thinking some assertions on the Rust side are also in order. Suricata will still crash, but it'll be absolutely clear that the contract between the function and the caller wasn't honored.

NULL deference stack trace is

AddressSanitizer:DEADLYSIGNAL
=================================================================
==32122==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000058 (pc 0x000109e933a8 bp 0x70000f4ef9f0 sp 0x70000f4ef9c0 T13)
==32122==The signal is caused by a READ memory access.
==32122==Hint: address points to the zero page.
    #0 0x109e933a8 in SCMd5Update hashing.rs:144
    #1 0x109c5d75a in MimeDecParseLine util-decode-mime.c:2569
    #2 0x1098fe22b in SMTPProcessRequest app-layer-smtp.c:1299
    #3 0x1098fc22f in SMTPPreProcessCommands app-layer-smtp.c:1393
    #4 0x1098fabc0 in SMTPParse app-layer-smtp.c:1465
    #5 0x1098f6d22 in SMTPParseClientRecord app-layer-smtp.c:1506
    #6 0x1098f087c in AppLayerParserParse app-layer-parser.c:1407
    #7 0x10982c039 in AppLayerHandleTCPData app-layer.c:773
    #8 0x109c13d06 in StreamTcpReassembleAppLayer stream-tcp-reassemble.c:1391
    #9 0x109c18804 in StreamTcpReassembleHandleSegment stream-tcp-reassemble.c:1997
    #10 0x109bc65d3 in StreamTcpStateDispatch stream-tcp.c:5236
    #11 0x109bb4eaf in StreamTcpPacket stream-tcp.c:5433
    #12 0x109be7a97 in StreamTcp stream-tcp.c:5745
    #13 0x109b0636e in FlowWorkerStreamTCPUpdate flow-worker.c:391
    #14 0x109b03ff5 in FlowWorker flow-worker.c:607
    #15 0x109c38990 in TmThreadsSlotVar tm-threads.c:469

Jason Ish wrote in #note-6:

Can this pcap end up in public tests?

Sure, that's fine