Cloudanix VulnDB

CVE-2026-98849

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A mistake in Linux kernel error handling can crash the whole system when creating certain network devices under unusual failure conditions.

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

What it actually does

Double release of a UDP socket created in pfcp_newlink() when register_netdevice() fails after pfcp_dev_init() succeeds, resulting in a NULL pointer dereference inside udp_tunnel_sock_release() on the error path.

Why it matters to the business

Kernel crash or denial of service on systems that attempt to create PFCP network devices under resource-constrained or fault-injection conditions; low public exploitability but still requires prompt patching on exposed Linux kernels.

How an attack unfolds

An attacker with sufficient privileges to trigger PFCP netdevice creation (for example via crafted netlink messages) can combine it with conditions that cause register_netdevice() to fail after the socket is allocated, hitting the buggy error path that releases an already-cleared socket pointer.

How to fix it

Update to a Linux kernel containing the fix that returns early from pfcp_del_sock() when pfcp->sk is NULL; apply the patch or a later stable release that resolves the double-release condition in pfcp_newlink().

How to confirm the fix worked

Confirm the kernel source contains the early return guard in pfcp_del_sock(), or test that register_netdevice() failures no longer produce KASAN reports or NULL dereferences in the PFCP error path.

Typical attack path

  1. Obtain privileges to send RTM_NEWLINK netlink messages for PFCP devices
  2. Trigger register_netdevice() failure after pfcp_dev_init() succeeds (resource exhaustion or fault injection)
  3. Cause the newlink error handler to call udp_tunnel_sock_release() on a NULL sk pointer
  4. Trigger kernel panic via the resulting NULL dereference

How to detect it

Search kernel logs and crash dumps for KASAN reports referencing udp_tunnel_sock_release and pfcp_newlink; look for netlink activity creating PFCP devices immediately preceding the fault.

What your security team should do

  • Prioritize kernel updates on any system exposing PFCP or custom netdevice registration paths
  • Monitor for crash reports containing udp_tunnel_sock_release and pfcp_newlink symbols
  • Apply defense-in-depth by restricting unprivileged netlink access where possible

The record

In the Linux kernel, the following vulnerability has been resolved: pfcp: fix socket lifetime on netdevice registration failure pfcp_newlink() creates the UDP socket before register_netdevice(). If registration fails after pfcp_dev_init() succeeds, the core calls pfcp_dev_uninit(), which releases the socket and clears pfcp->sk. The newlink error path then releases it again, causing a NULL pointer dereference. This was observed with failslab fault injection: FAULT_INJECTION: forcing a failure. kobject: kobject_add_internal failed for pfcp0 (error: -12 parent: net) BUG: KASAN: null-ptr-deref in udp_tunnel_sock_release+0x1c/0x50 Read of size 8 at addr 0000000000000120 by task ip/1037 Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x468/0x5cc kasan_report+0xa4/0xf0 __asan_load8+0x7c/0xd0 udp_tunnel_sock_release+0x1c/0x50 pfcp_newlink+0x128/0x184 rtnl_newlink+0x848/0xe44 rtnetlink_rcv_msg+0x468/0x514 netlink_rcv_skb+0xc0/0x1f0 rtnetlink_rcv+0x18/0x24 netlink_unicast+0x4b8/0x558 netlink_sendmsg+0x2b8/0x584 ... Return from pfcp_del_sock() if pfcp->sk is NULL.

Affected packages

Ecosystem Package Introduced Fixed