CVE-2016-9555

What it actually does

Missing length validation on the first SCTP chunk in sctp_sf_ootb allows out-of-bounds slab memory access, enabling denial of service via kernel panic or potential arbitrary code execution.

Why it matters to the business

Unpatched Linux systems accepting SCTP traffic face risk of remote crashes or full host compromise, leading to service outages, data exposure, and unplanned downtime on network-facing servers.

How an attack unfolds

An attacker crafts an SCTP packet containing a malformed first chunk with invalid length, sends it to a vulnerable kernel listening on SCTP ports, and triggers the unchecked access in sctp_sf_ootb to corrupt slab memory and either crash the system or gain code execution.

How to fix it

Upgrade the Linux kernel to version 4.8.8 or later; apply commit bf911e985d6bbaa328c20c3e05f4eb03de11fdd6 if building from source; disable SCTP via modprobe blacklist if immediate upgrade is impossible.

How to confirm the fix worked

Verify running kernel version is 4.8.8 or newer; confirm the fix commit is present in the kernel source tree; test with a benign SCTP packet generator to ensure no crash occurs on malformed input.

Typical attack path

1. Identify hosts exposing SCTP ports over the network
2. Craft a minimal SCTP INIT or DATA packet with an out-of-bounds first chunk length
3. Transmit the packet to the target kernel
4. Trigger slab out-of-bounds read/write leading to panic or payload execution
5. Escalate to persistence or lateral movement if code execution succeeds

How to detect it

Review kernel logs for oops/panic messages referencing sctp_sf_ootb or slab corruption; inspect network captures for anomalous SCTP INIT/DATA packets with unusual chunk lengths; correlate with system uptime resets on exposed hosts.

• sctp_sf_ootb
• slab out of bounds
• kernel: [0-9.]+: Out of bounds slab access in net/sctp

What your security team should do

• Immediately inventory all Linux hosts and containers for kernel versions older than 4.8.8
• Prioritize patching internet-facing or SCTP-enabled systems within 30 days given the high CVSS and public exploitability
• Apply network segmentation or firewall rules to block SCTP where not required
• Monitor EPSS trend and re-evaluate if exploit code appears in public repositories