CVE-2025-21637

What it actually does

Null pointer dereference in SCTP sysctl udp_port handler when current->nsproxy is NULL during task exit, instead of safely obtaining net structure via table->data and container_of().

Why it matters to the business

Kernel oops and potential system crash on affected Linux systems when SCTP sysctls are accessed under specific process exit conditions, causing denial of service and operational disruption; older Red Hat kernels in long-term support require urgent patching due to ecosystem prevalence.

How an attack unfolds

An attacker or automated tool triggers SCTP udp_port sysctl read/write (for example via acct(2) or similar) while the current task is exiting, causing current->nsproxy to be NULL and resulting in a null-ptr-deref oops; listed threat actors reference generic Linux kernel out-of-bounds access patterns that could be adapted for reliability.

How to fix it

Upgrade affected Red Hat kernels to 2.6.32-358.72.1.el6 or later; for GIT sources apply commit 0a0966312ac3eedd7f5f2a766ed4702df39a9a65; rebuild and reboot systems after applying fixed packages for kernel, kernel-devel, perf and related components.

How to confirm the fix worked

Verify installed kernel version matches or exceeds the listed fixed versions; confirm sysctl handler uses table->data with container_of() instead of current->nsproxy; test sysctl access under process exit conditions for absence of oops.

Typical attack path

1. Identify or create condition where a process is exiting while SCTP sysctl is accessed
2. Trigger sysctl operation on net.sctp.udp_port via /proc/sys or related interface
3. Force current->nsproxy to NULL during the handler execution
4. Cause kernel null pointer dereference and oops

How to detect it

Search kernel logs for oops or null-ptr-deref entries mentioning sctp, sysctl, udp_port or nsproxy; review audit logs for acct(2) or sysctl calls around crash timestamps; inspect /proc/sys/net/sctp paths for unexpected access.

• sctp.*udp_port.*null-ptr-deref
• current->nsproxy
• container_of.*net.*sctp
• Oops.*sctp_sysctl

What your security team should do

• Prioritize patching all listed Red Hat rhel_aus 6.4 kernel packages to 2.6.32-358.72.1.el6 within maintenance windows
• Monitor for kernel oops logs involving sctp and nsproxy
• Restrict untrusted access to SCTP sysctls until patched
• Update detection rules for null-ptr-deref patterns in SCTP code paths