CVE-2015-8767

What it actually does

Improper lock management between socket state and SCTP side-effect processing allows a local process to trigger a deadlock via a specially crafted sctp_accept sequence.

Why it matters to the business

Local users can render the affected system unresponsive, causing denial of service that disrupts all workloads until manual intervention or reboot occurs; the issue affects widely deployed Linux distributions but carries low remote exploitation risk.

How an attack unfolds

An attacker with local shell access invokes sctp_accept on a specially prepared SCTP socket in a timing-dependent manner that violates the expected lock ordering, resulting in a permanent deadlock of kernel threads handling SCTP.

How to fix it

Upgrade the Linux kernel to version 4.3 or later on all affected distributions; apply vendor backports for supported long-term releases of Debian and Ubuntu where available; disable SCTP kernel module if the protocol is not required.

How to confirm the fix worked

Confirm running kernel version is at least 4.3; attempt reproduction of the deadlock condition in a test environment using the original sctp_accept reproducer; review kernel changelog entries referencing sm_sideeffect.c lock ordering fixes.

Typical attack path

1. Obtain local unprivileged shell on target system
2. Create or bind an SCTP socket
3. Issue crafted sctp_accept call that races with internal state changes
4. Trigger kernel deadlock and system-wide unresponsiveness

How to detect it

Review system and kernel logs for repeated SCTP socket operations immediately preceding a hang; correlate with process listings showing sctp_accept callers; examine crash dumps or hung-task traces referencing sm_sideeffect.c for evidence of prior exploitation attempts.

What your security team should do

• Prioritize kernel upgrades on all internet-facing or multi-tenant systems within the next maintenance window
• Disable the SCTP module (modprobe.blacklist=sctp) on systems where the protocol is unused
• Monitor for local privilege-escalation chains that could combine with this availability issue
• Include kernel version checks in routine vulnerability scanning and asset inventory processes