Mar 27, 2026 - For details about updated CVE-2025-53521 (BIG-IP APM vulnerability), refer to K000156741.

Forum Discussion

Zaulis's avatar
Zaulis
Icon for Altostratus rankAltostratus
Mar 05, 2026

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

Hello folks

I am currently investigating a recurring ASM bd daemon crash (SIGSEGV) on a BIG-IP system and would like to ask if anyone has seen something similar.

It looks like the crash occurs during dynamic parameter inspection or metacharacter validation in request body parameters.

Environment:

• BIG-IP version: started 16.1.6.1 I tried update to 17.1.3 -> now 17.1.3.1 b.006

• Traffic type: mobile application API traffic

• Requests contain JSON payloads in POST body

• Content-Type: application/json

• Some requests are also gzip encoded

 

Symptoms:

The bd process crashes intermittently under normal production traffic.

After the crash, the system generates a core dump for bd.

 

From initial analysis of the core file we can see that the crash happens while ASM is processing request parameters inside the request body.

 

Relevant strings found in the core dump include:

 

handle_dynamic_param_name_checks

VIOL_PARAMETER_VALUE_METACHAR

check_user_input_value

ALPHA_NUMERIC checks len

 

We also see that ASM is constructing a request logging record at the moment of the crash (internal #S... formatted record used by ASM logging).

 

Example snippet from memory:

 

#Sprotocol=HTTP

#Sresponse=Only illegal requests are logged

#Sroute_domain=0

#Ssession_id=...

#SHeaders=POST ...

 

This suggests the crash occurs while ASM is processing a request and preparing a security event/log record.

 

security

4 Replies

  • F5_Design_Engineer's avatar
    F5_Design_Engineer
    Icon for MVP rankMVP
    Mar 11, 2026

    Hi Zaulis​ ,

     

    Most likely the root cause could be the bd process crash appears to happen during request body inspection when ASM processes JSON payloads in POST requests.

     

    Investigate dynamic parameter inspection + JSON parsing + gzip requests, as these are the most common causes of bd crashes in ASM.

     

     

    You can try

     

    Check bd crashes == > in BASH Mode

     

    tmsh show sys service bd

    grep bd /var/log/ltm

    grep bd /var/log/asm

     

     

    Check core files == > in BASH Mode

     

    ls -lh /shared/core/

     

    Capture problematic requests == > in BASH Mode

    tcpdump -i 0.0:nnn -s0 -w /var/tmp/asm_issue.pcap

     

     

    Temporary Mitigations

     

    To reduce crashes while investigating:

     

    1 Disable dynamic parameter learning

     

    2️ Relax metacharacter checks for JSON parameters

     

    3️ Temporarily disable gzip request inspection

     

    4️ Limit maximum JSON request body size

     

    In most cases like this, the crash is caused by ASM parsing edge cases in JSON request bodies, not by normal LTM traffic processing.

     

    Let me know for further help as i dont have much visibility to the logs or other configuration hence cannot say much without other information.

    If you want, paste one of the following and I can analyze it further:

     

    the stack trace from the bd core dump

     

    a sample JSON request body

     

    the ASM policy parameter settings

     

    With those, I can likely identify the any root cause pattern.

     

    HTH

    F5 Design Engineer

    • Zaulis's avatar
      Zaulis
      Icon for Altostratus rankAltostratus
      Mar 12, 2026

      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 ?