In early 2025, security researchers and the Linux community discovered and patched a vulnerability, now tracked as CVE-2025-21636, in the Linux kernel's SCTP (Stream Control Transmission Protocol) sysctl code. This bug revolved around mishandling internal Linux kernel data structures when users or the kernel accessed or modified the plpmtud_probe_interval sysctl parameter, potentially leading to a kernel crash (null pointer dereference)—an event often called an "Oops" in kernel terminology.

In this post, we'll break down what went wrong, why it was an issue, and how the Linux kernel team fixed it. We'll show you real code snippets, reference the original commit, and share potential exploitation scenarios, all in simple terms.

What is SCTP and plpmtud_probe_interval?

SCTP is a transport-layer protocol (like TCP or UDP) built into the Linux kernel. It's used in telecom, messaging applications, and some datacenter software for reliable, message-oriented communication.

A sysctl parameter like plpmtud_probe_interval (used for configuring Path MTU Discovery probing intervals for SCTP) is tunable through the /proc/sys filesystem, letting system administrators adjust kernel behavior on the fly.

What Went Wrong?

The vulnerable code accessed the network namespace (netns) structure through current->nsproxy. Here’s the line that caused trouble:

struct net *net = current->nsproxy->net_ns;

This works *most* of the time, but current->nsproxy can be NULL (for example, when a process is exiting). If code tries to access it while it’s NULL, the kernel crashes with a null pointer dereference—very bad in such a critical component.

In security terms:

A local attacker, or even a misbehaving process, could trigger a kernel crash by exploiting a race or calling the sysctl in an unexpected state. This is a *denial-of-service* risk.

An attacker can exploit this by

1. Spawning a process and getting it to change sysctl settings while exiting or after certain privilege-changing syscalls (like acct(2) for process accounting).
2. Racing another process/thread to access the SCTP sysctl interface while the target's current->nsproxy pointer becomes NULL.

Syzkaller, an automated kernel fuzzer, discovered exactly this with the following scenario

- A fuzzed program triggers sysctl access just as it’s exiting or has manipulated its namespaces, resulting in the vulnerable pointer dereference.

The Fix

The maintainers changed the code to not rely on current (the current process’s context) for identifying the right network namespace. Instead, they used the data already present in the sysctl table—*which always points to the right place, safely*.

Before (Vulnerable)

struct net *net = current->nsproxy->net_ns;
int val = net->sctp.probe_interval;

After (Patched)

struct net *net = container_of(table->data, struct net, sctp.probe_interval);
int val = net->sctp.probe_interval;

table->data references the exact probe_interval parameter for the correct network namespace.

- container_of gets the surrounding struct net structure, reliably, even if the current process is in an odd state.

Commit & Patch References

- Linux kernel commit fixing CVE-2025-21636
(replace FIXED_COMMIT_HASH with the actual one when available; at time of this writing, see this lkml thread)
- Syzkaller dashboard bug report

Example Exploit Scenario

While there’s no direct privilege escalation, a local user (or rogue app) can crash the system simply by triggering the right race or sequence:

# Malicious or fuzzed code (pseudo-shell)
(
    while :; do
        echo 100 > /proc/sys/net/sctp/plpmtud_probe_interval
    done
) &
# At the same time, manipulate namespaces or begin process exit quickly.

With precise timing, this leads the kernel to follow a NULL current->nsproxy, causing a crash.

Who’s Affected and What To Do

- All Linux distributions shipping vulnerable kernel versions (check your kernel's SCTP sysctl code—most mainline kernels before the patch are affected).
- Environments running containers, using namespaces, or users tweaking SCTP sysctl values are *at higher risk*.
- Patch immediately. Distributors have already started releasing updates (apt upgrade, yum update, etc).

Conclusion

CVE-2025-21636 is a great example of why kernel code has to be careful with process context and namespaces. Even small dereferences, if made at the wrong time, can lead to a system-wide denial of service. The fix is elegant—using what the kernel already knows, not what it assumes about the running process.

References

- Linux Kernel Patch (lkml mailing list)
- Syzkaller bug tracker
- Linux Kernel SCTP documentation

Stay patched and, if you’re a kernel developer, remember: *Never trust current when you can trust the data you’re given!*


*Written for 2025 by AI. Share and reference with credit.*

Timeline

Published on: 01/19/2025 11:15:09 UTC
Last modified on: 02/27/2025 21:59:09 UTC