CVE-2026-72155
Received Received - Intake

Improved Locking Logic in Linux Kernel MTD SPI-NOR

Vulnerability report for CVE-2026-72155, including description, CVSS score, EPSS score, affected products, exploitability, helpful resources, and attack-flow context.

Publication date: 2026-08-15

Last updated on: 2026-08-15

Assigner: kernel.org

Description

In the Linux kernel, the following vulnerability has been resolved: mtd: spi-nor: swp: Improve locking user experience In the case of the first block being locked (or the few first blocks), if the user want to fully unlock the device it has two possibilities: - either it asks to unlock the entire device, and this works; - or it asks to unlock just the block(s) that are currently locked, which fails. It fails because the conditions "can_be_top" and "can_be_bottom" are true. Indeed, in this case, we unlock everything, so the TB bit does not matter. However in the current implementation, use_top would be true (as this is the favourite option) and lock_len, which in practice should be reduced down to 0, is set to "nor->params->size - (ofs + len)" which is a positive number. This is wrong. An easy way is to simply add an extra condition. In the unlock() path, if we can achieve the same result from both sides, it means we unlock everything and lock_len must simply be 0. A comment is added to clarify that logic.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-08-15
Last Modified
2026-08-15
Generated
2026-08-15
AI Q&A
2026-08-15
EPSS Evaluated
N/A
NVD
EUVD

Affected Vendors & Products

Currently, no data is known.

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability in the Linux kernel involves incorrect handling of SPI NOR flash memory unlocking. When the first block or few blocks are locked, attempting to unlock the entire device works, but unlocking just the locked blocks fails due to flawed logic in the unlock() function. The issue arises because the code incorrectly calculates the lock length, leading to improper unlocking behavior.

Detection Guidance

This vulnerability is specific to the Linux kernel's MTD SPI-NOR subsystem and does not have a direct network detection method. To detect it, check if your system is running a vulnerable kernel version using commands like 'uname -a' or 'cat /proc/version'. Look for kernel versions affected by the spi-nor locking issue.

Impact Analysis

This vulnerability could allow unauthorized access to locked portions of SPI NOR flash memory, potentially leading to data corruption or security breaches. If exploited, it might enable attackers to bypass intended access restrictions on sensitive data stored in the flash memory.

Mitigation Strategies

Apply the latest kernel update provided by your Linux distribution to patch the spi-nor locking issue. If an update is not available, avoid unlocking SPI-NOR blocks manually and restrict access to kernel-level operations that could trigger the vulnerability.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-72155. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart