Cloudanix VulnDB

CVE-2026-98624

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in the Linux kernel's network handling code can let an ordinary user crash the entire system by performing certain network socket operations at the same time.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in nfnetlink_queue allows concurrent release notifier and nfqnl_recv_config paths to reach __instance_destroy without proper serialization, resulting in a general protection fault and kernel oops.

Why it matters to the business

Unprivileged local users can trigger kernel crashes on affected Linux systems, causing denial of service, unplanned reboots, and potential loss of network connectivity or queued packets.

How an attack unfolds

An attacker opens a netfilter queue socket, issues an UNBIND request while another thread performs a close that invokes the release notifier, racing against nfnetlink config processing for the same portid and triggering the unprotected instance destruction path.

How to fix it

Apply the upstream fix that acquires the nfnl mutex inside the event notifier; rebuild and deploy updated kernel packages as they become available from distribution vendors.

How to confirm the fix worked

Confirm the patch is present by inspecting the nfnetlink_queue source for the added nfnl_lock/nfnl_unlock calls around the release notifier; test by reproducing the original concurrent close/UNBIND sequence and verifying absence of oops.

Typical attack path

  1. Create nfnetlink_queue socket and bind to a portid
  2. Trigger parallel close() on one thread and UNBIND netlink message on another
  3. Race window allows nfqnl_recv_config to call __instance_destroy concurrently with release path
  4. Kernel dereferences freed or inconsistent instance data leading to GPF

How to detect it

Search kernel logs for general protection faults with RIP pointing to __instance_destroy in the nfnetlink_queue module and call traces containing nfqnl_recv_config; correlate with processes performing netlink UNBIND operations on queue sockets.

What your security team should do

  • Monitor kernel vendor advisories and schedule urgent kernel updates once fixed packages are released
  • Restrict unprivileged access to netfilter netlink sockets via LSM or seccomp where feasible
  • Enable kernel panic-on-oops and watchdog mechanisms to limit blast radius of crashes

The record

In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_queue: hold nfnl mutex in event notifier We must serialize the release notifier and the config netlink function. A concurrent thread can issue close() which can call the release function while unrelated socket processes UNBIND request for same portid: Oops: general protection fault, [..] RIP: 0010:__instance_destroy+0x60/0x210 [nfnetlink_queue] Call Trace: nfqnl_recv_config+0x9b0/0xdc0 [nfnetlink_queue] nfnetlink_rcv_msg+0x7c2/0xeb0 ? __pfx_nfnetlink_rcv_msg+0x10/0x10 After this, parallel UNBIND and URELEASE events are impossible. This change isn't nice, but its the shortest fix given instances are not refcounted and the nfnetlink config callback drops the rcu read lock early due to need for sleeping allocations.

Affected packages

Ecosystem Package Introduced Fixed