Cloudanix VulnDB

CVE-2026-98973

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A recent Linux kernel fix prevents a timing error in display handling code that could cause the system to crash under certain conditions.

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 allowing concurrent list_del_init and list_empty checks on bridge_lingering_list and bridge_list without holding bridge_lock, leading to list corruption in the DRM subsystem.

Why it matters to the business

Kernel instability or crashes on systems handling display bridges, increasing downtime risk for graphics workloads; low immediate urgency given recent publication and negligible exploitation probability.

How an attack unfolds

An attacker with local access triggers repeated bridge add/remove operations in rapid succession from multiple threads or contexts to hit the window where list operations occur outside the lock, corrupting internal lists and causing subsequent kernel panics or memory errors.

How to fix it

Apply the upstream kernel patch that moves the list_empty and list_del_init operations under the bridge_lock; rebuild and deploy updated kernels to affected systems.

How to confirm the fix worked

Inspect the drm_bridge.c source for the bridge_lock held around the list operations in drm_bridge_add; confirm the fix appears in the running kernel version via git log or source inspection.

Typical attack path

  1. Obtain local code execution on a Linux system with DRM bridge support
  2. Load or trigger DRM drivers that perform drm_bridge_add and drm_bridge_remove in parallel
  3. Race the unlocked list_empty test and list_del_init on bridge_lingering_list
  4. Induce list corruption leading to kernel oops or panic during debugfs walks or subsequent operations

How to detect it

Review kernel logs for list corruption warnings, oops traces referencing drm_bridge or bridge_lock, and unexpected panics during display driver activity; no public exploitation artifacts exist yet.

What your security team should do

  • Prioritize kernel updates on systems with active DRM/display workloads within normal patch cycles
  • Monitor upstream stable kernel releases for backports of this fix
  • Limit untrusted local code execution on graphics-enabled hosts until patched

The record

In the Linux kernel, the following vulnerability has been resolved: drm/bridge: Fix unlocked list_del in drm_bridge_add() When re-adding a bridge that was previously removed, drm_bridge_add() drops it from bridge_lingering_list without holding bridge_lock. Both bridge_list and bridge_lingering_list are protected by bridge_lock, as they are concurrently modified by drm_bridge_remove() and __drm_bridge_free(), and walked by the debugfs 'bridges' file. Running the list_empty() test and the list_del_init() outside of the lock may therefore corrupt either list. Perform both under bridge_lock.

Affected packages

Ecosystem Package Introduced Fixed