Skip to main content

Linux CVE-2026-23393

| EUVDEUVD-2026-15394 HIGH
Race Condition (CWE-362)
2026-03-25 Linux GHSA-27jv-r6jg-f5fr
Linux Information Disclosure Race Condition
High
Disputed · 7.8 NVD
Share

Severity by source

Sources disagree (Low–High)
NVD PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
SUSE
3.1 LOW
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Red Hat
MEDIUM
qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Re-analysis Queued
Apr 24, 2026 - 18:52 vuln.today
cvss_changed
Patch released
Mar 31, 2026 - 21:13 nvd
Patch available
EUVD ID Assigned
Mar 25, 2026 - 10:45 euvd
EUVD-2026-15394
Analysis Generated
Mar 25, 2026 - 10:45 vuln.today
CVE Published
Mar 25, 2026 - 10:33 nvd
HIGH 7.8

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

bridge: cfm: Fix race condition in peer_mep deletion

When a peer MEP is being deleted, cancel_delayed_work_sync() is called on ccm_rx_dwork before freeing. However, br_cfm_frame_rx() runs in softirq context under rcu_read_lock (without RTNL) and can re-schedule ccm_rx_dwork via ccm_rx_timer_start() between cancel_delayed_work_sync() returning and kfree_rcu() being called.

The following is a simple race scenario:

cpu0 cpu1

mep_delete_implementation() cancel_delayed_work_sync(ccm_rx_dwork); br_cfm_frame_rx() // peer_mep still in hlist if (peer_mep->ccm_defect) ccm_rx_timer_start() queue_delayed_work(ccm_rx_dwork) hlist_del_rcu(&peer_mep->head); kfree_rcu(peer_mep, rcu); ccm_rx_work_expired() // on freed peer_mep

To prevent this, cancel_delayed_work_sync() is replaced with disable_delayed_work_sync() in both peer MEP deletion paths, so that subsequent queue_delayed_work() calls from br_cfm_frame_rx() are silently rejected.

The cc_peer_disable() helper retains cancel_delayed_work_sync() because it is also used for the CC enable/disable toggle path where the work must remain re-schedulable.

AnalysisAI

A race condition exists in the Linux kernel's bridge CFM (Connectivity Fault Management) peer MEP (Maintenance End Point) deletion code where a delayed work queue can be rescheduled between the cancellation check and memory freeing, leading to use-after-free on freed memory. This affects all Linux kernel versions with the vulnerable bridge CFM implementation. An attacker with local access to trigger peer MEP deletion while CFM frame reception occurs could cause a kernel use-after-free condition potentially leading to information disclosure or denial of service.

Technical ContextAI

The vulnerability exists in the Linux kernel's bridge CFM subsystem (net/bridge/br_cfm.c), specifically in the Connectivity Fault Management implementation for Ethernet OAM (Operations, Administration, and Maintenance). The affected CPE is cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:*. The root cause is a classic Time-of-Check-Time-of-Use (TOCTOU) race condition where cancel_delayed_work_sync() returns before the work queue is actually disabled, allowing concurrent code paths running in softirq context under RCU read-side critical sections to reschedule the work. The br_cfm_frame_rx() function operates in softirq context protected only by rcu_read_lock() (not the RTNL mutex) and can invoke ccm_rx_timer_start() to reschedule ccm_rx_dwork, which occurs after the work cancellation but before the peer_mep structure is freed via kfree_rcu(). This results in a use-after-free vulnerability when the rescheduled work executes on freed memory.

RemediationAI

Update the Linux kernel to a patched version that includes the disable_delayed_work_sync() fix for peer MEP deletion paths. Consult the stable kernel commits at https://git.kernel.org/stable/c/e89dbd2736a45f0507949af4748cbbf3ff793146 and related backport commits to identify the minimal kernel version that includes the fix for your kernel series. For systems actively using bridge CFM features, prioritize kernel patching. As an interim mitigation, disable CFM functionality if not required by your deployment, or restrict network access to management interfaces that could trigger peer MEP operations. Ensure you are running a maintained kernel version, as the Linux kernel project actively backports security fixes to supported stable branches.

Same weakness CWE-362 – Race Condition

View all
CVE-2016-5195 HIGH POC
7.0
CVE-2017-1000112 HIGH POC
7.0
CVE-2014-0196 MEDIUM POC
5.5
CVE-2014-0226 MEDIUM POC
6.8
CVE-2016-1757 HIGH POC
7.0
CVE-2016-8655 HIGH POC
7.8
CVE-2015-5754 CRITICAL POC
9.3
CVE-2015-8556 CRITICAL POC
10.0

Same technique Information Disclosure

View all
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8
CVE-2023-7028 CRITICAL POC
10.0
CVE-2017-0213 HIGH POC
7.3

Vendor StatusVendor

Debian

linux
Release Status Fixed Version Urgency
bullseye not-affected - -
bullseye (security) fixed 5.10.251-1 -
bookworm vulnerable 6.1.159-1 -
bookworm (security) vulnerable 6.1.164-1 -
trixie vulnerable 6.12.73-1 -
trixie (security) vulnerable 6.12.74-2 -
forky, sid vulnerable 6.19.8-1 -
(unstable) fixed (unfixed) -

SUSE

Severity: Low
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

CVE-2026-23393 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy