Ferritaas Incident Intelligence
Defect Intelligence Report Bug 0849201 Severity: Critical (P1)

WAD HTTP/2 Context Double-Free Crash under High Concurrency

FortiOS proxy worker process /bin/wad panics with signal 11 at http2_ctx_free+0x48 when client browsers rapidly close multiplexed HTTP/2 streams during high-throughput SSL inspection, causing silent session drops and worker crash loops.

Technical Root Cause Analysis

Under FortiOS proxy inspection mode with HTTP/2 enabled, the wad worker process maintains reference counts for every active multiplexed stream context. When high concurrency client sessions terminate abruptly (such as RST packets or TCP FIN bursts during web page asset fetching), the teardown routine invokes http2_stream_close concurrently with connection pool cleanup.

Due to a missing mutex guard in the stream deallocation callback, memory addresses are returned to the user-space slab cache twice. The second free call triggers an invalid pointer dereference inside the glibc memory manager, generating a Linux SIGSEGV (signal 11).

[wad 24190] crash: signal 11 (SIGSEGV) at 0x00007f9c82b4a048 backtrace: #0 0x00007f9c83a12104 in http2_ctx_free+0x48 () from /bin/wad #1 0x00007f9c83a12519 in wad_http2_session_destroy+0x82 () from /bin/wad #2 0x00007f9c839f8842 in wad_ssl_stream_event_cb+0x13c () from /bin/wad #3 0x00007f9c838e1091 in event_base_loop+0x3a5 () from /lib64/libevent.so daemon /bin/wad child 24190 exited with code 11 (restarting worker 1/8)

Affected Firmware & Blast Radius Matrix

FortiOS Branch Vulnerable Builds Confirmed Clean Build Status & Workaround
FortiOS 7.2 7.2.0 – 7.2.4 7.2.5+ Disable HTTP/2 in proxy profile
FortiOS 7.4 7.4.0 7.4.1+ Upgrade recommended or switch to flow mode
FortiOS 7.0 Not Affected 7.0.x Branch Clean HTTP/2 multiplexing refactor absent in 7.0

Platform Impact: Affects all FortiGate models (FG-60F up to FG-3000F) running deep SSL proxy inspection with HTTP/2 enabled in high-concurrency enterprise web environments.

Step 01: Free Verification CLI (Safe Read-Only)

Execute these commands to confirm whether your FortiGate has experienced WAD worker crashes and verify active crash timestamps:

Diagnostic Commands

# 1. Read the kernel crashlog to detect WAD signal 11 crashes
diagnose debug crashlog read | grep -A 5 -B 2 "wad"

# 2. Check current WAD worker process IDs and running memory
diagnose test application wad 1000
diagnose sys process pidof wad

# 3. Verify top memory-consuming processes
diagnose sys top-mem 15

Remediation & Workaround Steps (Teaser Preview)

Follow the complete step-by-step remediation guide in the Ferrite interactive platform:

Step 02: Identify Affected Proxy Inspection Policies & Profiles

Scan configuration for policies utilizing HTTP/2 negotiation within profile-protocol-options.

🔒 Interactive CLI Available in Ferrite Runbook #05

Step 03: Non-Disruptive CLI Workaround (Zero Downtime)

Disable HTTP/2 inside the active protocol options profile to force clean HTTP/1.1 ALPN fallback.

🔒 Interactive CLI Available in Ferrite Runbook #05

Step 04: Surgical Worker Recycling without Affecting ASICs

Safely restart crashed WAD workers without dropping hardware-accelerated NP7 traffic.

🔒 Interactive CLI Available in Ferrite Runbook #05
⚡ Ferrite Platform Superpowers

Execute the Complete Runbook with Live Browser Automation

Connect your FortiGate via browser console (Web Serial) or local SSH bridge, verify each command in real-time, generate ready-to-run Tera Term scripts, and export sanitized TAC dossiers.

Live Browser Automation Direct terminal connection with live step checkoff.
📟
1-Click Tera Term (.ttl) Generate scripts for air-gapped jumpboxes.
🛡️
Zero-Trust Scrubber Scrub serials and credentials in local browser RAM.
📄
TAC P1 Escalation Dossier Standardized evidence export with SHA-256 seal.

Frequently Asked Questions

What causes FortiOS Bug 0849201?

Under proxy mode with HTTP/2, rapid client session termination triggers concurrent stream cleanup, causing the memory manager to double-free context pointers resulting in SIGSEGV signal 11.

Is there a non-disruptive production workaround?

Yes. Disabling HTTP/2 inside the protocol options profile forces negotiation of standard HTTP/1.1 via ALPN, bypassing the vulnerable code path without dropping user traffic.

Which FortiOS release provides the permanent fix?

Permanent code fixes were integrated into FortiOS 7.2.5, 7.4.1, and all subsequent firmware releases.