Cloudanix VulnDB

CVE-2026-98953

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A small bookkeeping error in the Linux kernel can cause memory to slowly leak when certain network devices are created and destroyed many times, eventually hurting system stability.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

A reference leak occurs in the Linux kernel devlink subsystem when schedule_delayed_work() returns false because notify work is already pending; the extra reference on devlink_rel is never dropped, leaking the object and its index in devlink_rels. The reschedule path inside the work function has the identical defect.

Why it matters to the business

Repeated registration and unregistration of nested devlink instances can exhaust kernel memory over time, potentially leading to degraded performance or denial of service on systems that frequently create and destroy such instances.

How an attack unfolds

An attacker with the ability to trigger repeated devl_register() and devl_unregister() calls on nested devlink instances (for example via crafted network device configuration) causes the pending-work reference leak to accumulate until memory pressure occurs.

How to fix it

Apply the upstream fix that drops the extra reference when schedule_delayed_work() indicates the work was already queued; rebuild and deploy the patched kernel. Monitor vendor advisories for the next stable release containing the correction.

How to confirm the fix worked

After patching, repeatedly register and unregister a nested devlink instance 100+ times under lock contention and verify that the number of allocated devlink_rel objects remains stable using kernel memory accounting or slabinfo.

Typical attack path

  1. Obtain local execution or privileged network configuration rights on a Linux host
  2. Repeatedly register and unregister nested devlink instances while the parent devlink lock is contended
  3. Trigger the schedule_delayed_work() path that returns false due to already-pending work
  4. Accumulate unreleased devlink_rel references until memory exhaustion

How to detect it

Look in kernel logs for repeated devlink register/unregister activity under lock contention; monitor slabinfo or kmemleak reports for growing counts of devlink_rel objects; correlate with processes performing frequent netlink devlink operations.

What your security team should do

  • Prioritize kernel updates on systems that expose devlink interfaces to untrusted users or scripts
  • Add monitoring for unusual growth in slab objects related to devlink
  • Restrict unprivileged access to netlink devlink commands where feasible

The record

In the Linux kernel, the following vulnerability has been resolved: devlink: fix devlink_rel reference leak when notify work is pending devlink_rel_nested_in_notify_work_schedule() takes a reference on the devlink_rel for the notify work and then queues the work, ignoring the return value of schedule_delayed_work(). If the work is already pending, nothing new is queued, the work runs only once and drops only one reference, so the extra one is leaked together with the devlink_rel and its index in devlink_rels. This is easy to hit. devl_register() of a nested instance queues the work, and if the instance is unregistered before the work has run, devlink_rel_put() queues it again while it is still pending. The work also keeps rescheduling itself for as long as the parent devlink lock cannot be taken, which widens the window. Registering and unregistering a nested devlink instance 100 times while holding the parent lock leaks all 100 devlink_rel objects. The reschedule path in devlink_rel_nested_in_notify_work() has the same problem: if the work was queued again while it was running, the reference it holds is never dropped. Drop the reference in both places when the work was already pending. The pending work holds its own reference, so this can not be the last one.

Affected packages

Ecosystem Package Introduced Fixed