ASM bd daemon crash while processing request body (SIGSEGV) – anyone seen similar behavior?

Hi, 

First of all Is F5_Design_Engineer an AI companion or real person ? Responses look AI generated

Anyway. thanks for reply

I think tcpdump -i 0.0:nnn -s0 -w /var/tmp/asm_issue.pcap will not help me. It just capture all packets. But how should I find request crashing my ASM bd in that pcap file? I see no way.

I investigete log files and core dump files ( I hav a lot in /shared/core/ )

What i found in core files 

1) Heap content at crash site (x/32xg 0x5690e50)

The first 8 bytes of the object at 0x5690e50 (which is also RDX) contain HTTP request data:

0x5690e50:  0x72616863203b6e69  ("in; char")

0x5690eb0:  "VIOL_PAR"

0x5690ec0:  "AMETER_V"

0x5690ed0:  "ALUE_MET"  (VIOL_PARAMETER_VALUE_METACHAR)

0x5690ee0:  "00-0..."   "Type":"mobi..."  (JSON fragment)

Conclusion: HTTP/JSON request data has overwritten internal ASM object structures (heap corruption). The ASM engine subsequently attempted to dereference an ASCII string as a C++ object pointer.

2) Crash instruction

=> 0x7f28583bfc83:   mov (%rsp),%rdi

Conclusion: Stack corruption — request data overwrote the stack frame. Two threads (LWP 13307 and LWP 13462) crashed at the same address, confirming a systematic trigger.

I found CVE-2026-22548 https://my.f5.com/manage/s/article/K000158072 It marked as fixed in 17.1.3 But what if it is just partially fixed ?

Also I see not fixed bugs https://cdn.f5.com/product/bugtracker/ID1782057.html  and https://cdn.f5.com/product/bugtracker/ID1755113.html

Do you know when F5 fix that two bugs? 

Maybe you know existing EHF for 17.1.3.1 fixing bd SIGSEGV ? Can you Advise on interim mitigation (request size limits, specific db variables) for 17.1.3.1 ?