Linux Kernel up to 6.18.23/6.19.13/7.0.0 wireguard wg_netns_pre_exit reference count

Summaryinfo

A vulnerability marked as critical has been reported in Linux Kernel up to 6.18.23/6.19.13/7.0.0. This issue affects the function wg_netns_pre_exit of the component wireguard. The manipulation leads to reference count. This vulnerability is listed as CVE-2026-31579. There is no available exploit. It is suggested to upgrade the affected component.

Detailsinfo

A vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.18.23/6.19.13/7.0.0. This issue affects the function wg_netns_pre_exit of the component wireguard. The manipulation with an unknown input leads to a reference count vulnerability. Using CWE to declare the problem leads to CWE-911. The product uses a reference count to manage a resource, but it does not update or incorrectly updates the reference count. Impacted is availability. The summary by CVE is:

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. ]

It is possible to read the advisory at git.kernel.org. The identification of this vulnerability is CVE-2026-31579 since 03/09/2026. Technical details of the vulnerability are known, but there is no available exploit.

Upgrading to version 6.18.24, 6.19.14 or 7.0.1 eliminates this vulnerability. Applying the patch 9a9e69155b2091b8297afaf1533b8d68a3096841/1c52ef00e391144334f10995985c2f256d4be982/a1d0f6cbb962af29586e3e65a4bced1a5e39221f is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.18.0
• 6.18.1
• 6.18.2
• 6.18.3
• 6.18.4
• 6.18.5
• 6.18.6
• 6.18.7
• 6.18.8
• 6.18.9
• 6.18.10
• 6.18.11
• 6.18.12
• 6.18.13
• 6.18.14
• 6.18.15
• 6.18.16
• 6.18.17
• 6.18.18
• 6.18.19
• 6.18.20
• 6.18.21
• 6.18.22
• 6.18.23
• 6.19.0
• 6.19.1
• 6.19.2
• 6.19.3
• 6.19.4
• 6.19.5
• 6.19.6
• 6.19.7
• 6.19.8
• 6.19.9
• 6.19.10
• 6.19.11
• 6.19.12
• 6.19.13
• 7.0

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion