CVE-2017-5986

What it actually does

Race condition in sctp_wait_for_sndbuf allows a local multithreaded process to trigger an assertion failure and kernel panic by peeling off an SCTP association while the send buffer is in a specific full state.

Why it matters to the business

Local denial-of-service crashes on Linux systems that use SCTP sockets, causing unplanned downtime and loss of availability for any service relying on those systems; the issue has been public for nearly a decade with no active exploitation campaigns observed.

How an attack unfolds

An attacker with local access runs a multithreaded program that creates an SCTP association, drives the send buffer into a full state, and then concurrently peels the association in a timing window that hits the race, forcing the kernel assertion and panic.

How to fix it

Upgrade the Linux kernel to a version containing commit 2dcab598484185dea7ec22219c76dcdd59e3cb90 (equivalent to 4.9.11 or later mainline). Reboot after installation and verify the running kernel version. Where immediate patching is not possible, restrict untrusted local code execution and consider disabling SCTP if unused.

How to confirm the fix worked

Confirm the installed kernel is 4.9.11 or newer and contains commit 2dcab598484185dea7ec22219c76dcdd59e3cb90. Reproduce a controlled SCTP peel-off test in a non-production environment to ensure the panic no longer occurs. Monitor kernel logs for absence of the prior assertion failure after upgrade.

Typical attack path

1. Obtain local shell or code execution on the target Linux host
2. Load or compile a multithreaded SCTP client that can control association state and buffer occupancy
3. Create an SCTP association and fill the send buffer to the vulnerable condition
4. Trigger concurrent peel-off operations from multiple threads to win the race
5. Observe kernel panic and system reboot or hang

How to detect it

Review kernel panic logs and crash dumps for SCTP-related assertion failures around the sctp_wait_for_sndbuf function; correlate with process execution of multithreaded applications that open SCTP sockets shortly before the crash.

What your security team should do

• Prioritize kernel updates on any remaining systems still running kernels before 4.9.11
• Inventory hosts that expose or use SCTP sockets and schedule maintenance windows
• Remove unnecessary SCTP kernel modules or capabilities from hardened images
• Add kernel version checks to vulnerability scanning and asset management processes