Live › vulnerability › CVE-2026-98973
Go to dashboardIn the Linux kernel's DRM bridge code, re-adding a removed bridge drops it from a shared list without holding the lock that protects the list. A race with concurrent bridge removal or the debugfs listing can corrupt the kernel's internal lists.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with the DRM bridge subsystem, typically machines with display hardware that uses bridge chips. The sources do not say which kernel versions are affected or whether a default configuration reaches the code path.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-98973")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.