Skip to main content

Linux Kernel CVE-2026-31579

| EUVDEUVD-2026-25472 MEDIUM
NULL Pointer Dereference (CWE-476)
2026-04-24 Linux GHSA-h53c-6597-vmfw
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
4.7 MEDIUM

Race condition against concurrent rtnl_mutex holder warrants AC:H over NVD's AC:L; all other metrics align with the local, low-privilege, availability-only impact described.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
MEDIUM
qualitative
Red Hat
5.5 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

6
Analysis Generated
Jul 24, 2026 - 03:04 vuln.today
CVSS changed
Apr 27, 2026 - 20:52 NVD
5.5 (MEDIUM)
Patch released
Apr 27, 2026 - 20:43 nvd
Patch available
Patch available
Apr 24, 2026 - 16:16 EUVD
EUVD ID Assigned
Apr 24, 2026 - 15:00 euvd
EUVD-2026-25472
CVE Published
Apr 24, 2026 - 14:42 nvd
MEDIUM 5.5

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

wireguard: device: use exit_rtnl callback instead of manual rtnl_lock in pre_exit

wg_netns_pre_exit() manually acquires rtnl_lock() inside the pernet .pre_exit callback. This causes a hung task when another thread holds rtnl_mutex - the cleanup_net workqueue (or the setup_net failure rollback path) blocks indefinitely in wg_netns_pre_exit() waiting to acquire the lock.

Convert to .exit_rtnl, introduced in commit 7a60d91c690b ("net: Add ->exit_rtnl() hook to struct pernet_operations."), where the framework already holds RTNL and batches all callbacks under a single rtnl_lock()/rtnl_unlock() pair, eliminating the contention window.

The rcu_assign_pointer(wg->creating_net, NULL) is safe to move from .pre_exit to .exit_rtnl (which runs after synchronize_rcu()) because all RCU readers of creating_net either use maybe_get_net()

  • which returns NULL for a dying namespace with zero refcount - or

access net->user_ns which remains valid throughout the entire ops_undo_list sequence.

[ Jason: added __net_exit and __read_mostly annotations that were missing. ]

AnalysisAI

Deadlock in the Linux kernel WireGuard subsystem can cause a hung task and system-level denial of service for authenticated local users. The wg_netns_pre_exit() pernet callback manually acquires rtnl_lock(), blocking indefinitely if rtnl_mutex is concurrently held by the cleanup_net workqueue or setup_net failure rollback path. No public exploit exists and EPSS is extremely low (0.02%, 4th percentile); however, the issue spans a broad range of kernel versions and has been patched in stable releases 6.18.24, 6.19.14, and 7.0.1.

Technical ContextAI

The vulnerability resides in the WireGuard kernel driver (net/wireguard/device.c) within the pernet .pre_exit callback wg_netns_pre_exit(). This callback explicitly calls rtnl_lock() to serialize access while cleaning up WireGuard state during network namespace teardown. The problem is that the cleanup_net workqueue and setup_net failure rollback path may already hold rtnl_mutex, creating a lock-ordering deadlock that causes the kernel thread to hang indefinitely. The fix converts the callback to use the .exit_rtnl hook (introduced in kernel commit 7a60d91c690b), where the framework itself holds RTNL for all callbacks under a single rtnl_lock()/rtnl_unlock() pair, eliminating the contention window. The rcu_assign_pointer(wg->creating_net, NULL) call is safely relocated to .exit_rtnl because it runs after synchronize_rcu(), and all RCU readers either use maybe_get_net() (which returns NULL for a dying namespace) or access net->user_ns which remains valid throughout the operation. Although CWE-476 (Null Pointer Dereference) is tagged in metadata, the primary mechanism is lock contention producing a hung task; the CWE tag is likely secondary. CPE cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:* confirms the issue spans the entire upstream Linux kernel product line.

RemediationAI

The primary fix is to upgrade to Linux kernel 6.18.24, 6.19.14, or 7.0.1, which incorporate the .exit_rtnl conversion. Upstream stable-tree patches are available at https://git.kernel.org/stable/c/9a9e69155b2091b8297afaf1533b8d68a3096841, https://git.kernel.org/stable/c/1c52ef00e391144334f10995985c2f256d4be982, and https://git.kernel.org/stable/c/a1d0f6cbb962af29586e3e65a4bced1a5e39221f. Ubuntu users should apply the packages referenced in USN-8488-1; Red Hat and SUSE security channels are expected to carry equivalent fixes. As a compensating control where patching is not immediately possible, unloading the WireGuard kernel module (modprobe -r wireguard) eliminates the vulnerable code path entirely, with the trade-off of disabling all WireGuard VPN tunnels on that host. Restricting local user access to network namespace creation (via sysctl -w user.max_user_namespaces=0 or equivalent AppArmor/SELinux policy) reduces the attack surface without requiring a kernel update, though this may break container workloads that depend on user namespaces.

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

CVE-2026-31579 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy