What is the CVSS score of CVE-2024-26757?

CVE-2024-26757 has a CVSS 3.1 base score of 5.5 (Medium). CVSS vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.2%.

Is there a patch available for CVE-2024-26757?

Yes, a patch is available for CVE-2024-26757. Update the affected software to the latest version immediately.

Linux Kernel CVE-2024-26757

MEDIUM

Improper Resource Shutdown or Release (CWE-404)

2024-04-03 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Information Disclosure Linux Linux Kernel

5.5

CVSS 3.1 · Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

View

Vulnerability Assessment

Weakness	CWE CWE-404 ASVS 5.0 V15 - Secure Coding and Architecture Resource release
Impact	CVSS score of 5.5 (MEDIUM). Attack characteristics: local attack vector, low complexity, low privileges required, no user interaction not required.
Exploit ScenarioDerived	Successful exploitation could compromise the medium-severity affected system.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).

Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAI

In the Linux kernel, the following vulnerability has been resolved: md: Don't ignore read-only array in md_check_recovery() Usually if the array is not read-write, md_check_recovery() won't register. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity.

RemediationAI

A vendor patch is available. Apply the latest security update as soon as possible. Apply vendor patches when available. Implement network segmentation and monitoring as interim mitigations.

Affects your stack

Find out whether the stacks and servers you run are on an affected version.

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

This vulnerability is classified under CWE-404. In the Linux kernel, the following vulnerability has been resolved: md: Don't ignore read-only array in md_check_recovery() Usually if the array is not read-write, md_check_recovery() won't register new sync_thread in the first place. And if the array is read-write and sync_thread is registered, md_set_readonly() will unregister sync_thread before setting the array read-only. md/raid follow this behavior hence there is no problem. After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh: 1) array is read-only. dm-raid update super block: rs_update_sbs ro = mddev->ro mddev->ro = 0 -> set array read-write md_update_sb 2) register new sync thread concurrently. 3) dm-raid set array back to read-only: rs_update_sbs mddev->ro = ro 4) stop the array: raid_dtr md_stop stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 5) sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 6) daemon thread can't unregister sync thread: md_check_recovery if (!md_is_rdwr(mddev) && !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) return; -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang; The root cause is that dm-raid manipulate 'mddev->ro' by itself, however, dm-raid really should stop sync thread before setting the array read-only. Unfortunately, I need to read more code before I can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix the problem the easy way for now to prevent dm-raid regression. Affected products include: Linux Linux Kernel.

Know when Linux Kernel gets its next vulnerability

Watch products and get an email when something new is published
Check this CVE against your own stack and servers
Exploit and PoC references, threat intelligence from 22 sources

Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY 5.5 MEDIUM

AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) · only source for this CVE.

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Attack Vector

Local

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

DescriptionCVE.org

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

md: Don't ignore read-only array in md_check_recovery()

Usually if the array is not read-write, md_check_recovery() won't register new sync_thread in the first place. And if the array is read-write and sync_thread is registered, md_set_readonly() will unregister sync_thread before setting the array read-only. md/raid follow this behavior hence there is no problem.

After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh:

array is read-only. dm-raid update super block:

rs_update_sbs ro = mddev->ro mddev->ro = 0 -> set array read-write md_update_sb

register new sync thread concurrently.
dm-raid set array back to read-only:

rs_update_sbs mddev->ro = ro

stop the array:

raid_dtr md_stop stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))

sync thread done:

md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread);

daemon thread can't unregister sync thread:

md_check_recovery if (!md_is_rdwr(mddev) && !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) return; -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang;

The root cause is that dm-raid manipulate 'mddev->ro' by itself, however, dm-raid really should stop sync thread before setting the array read-only. Unfortunately, I need to read more code before I can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix the problem the easy way for now to prevent dm-raid regression.

Threat Intelligence Overview

EPSS Score

0.2%

Top 89% exploitable

Data Quality

3 sources

Confidence: Low

NVD

CVE.org

EPSS MSRC

VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue

Severity MEDIUM

CISA KEV No

Public POC No

EPSS 0.2%

Patch available Yes

Active threat No

Deciding rule

MEDIUM severity (CVSS 4.0-6.9)

What every action level means

Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.

Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.

This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.

This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.

Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived

Defer

Exploitation· derived

None

System Exposure· derived

Small

Automatable· derived

Human Impact· derived

Medium

Priority Score

Low Medium High Critical

KEV: 0

EPSS: 0

CVSS: +28

PoC: 0

Weaponized: 0

Threat intel: 0

Gov advisory: 0

Attack Technique

Information Disclosure MEDIUM

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.