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.
Published: 2026-08-15
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel’s mtd:spi‑nor driver contains a logic error that makes it impossible to unlock only those flash blocks that are currently locked. The unlock path erroneously checks top‑bottom lock flags and miscalculates lock length, causing a failure when the user requests to unlock a subset of locked blocks. This flaw prevents legitimate unblocking of flash sectors while leaving higher‑level system functionality intact. The impact is limited to a device‑level denial of service because the failure affects only the flash locking mechanism. The vulnerability is a direct result of improper input validation and calculation errors.

Affected Systems

All Linux kernels that incorporate the mtd:spi‑nor driver and were compiled before the fixed commit 12d4d69221 are affected. This includes the default kernels in any distribution that has not applied the update, as the driver is part of the generic MTD subsystem and its sysfs interface is used by many user‑space utilities.

Risk and Exploitability

The CVSS score of 5.5 indicates moderate severity. The EPSS figure of less than 1 % suggests a very low probability of widespread exploitation. The vulnerability is not listed in CISA’s KEV catalog, and there is no known remote code execution path. Exploitation would require local or privileged access to the device’s sysfs interface to issue unlock commands, which limits the threat to environments where such access is granted. Consequently, overall risk is moderate for sensitive deployments and low for general use.

Generated by OpenCVE AI on August 18, 2026 at 04:16 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the kernel patch that introduces commit 12d4d69221 to correct the unlock logic
  • If upgrading is not immediately possible, perform a full‑device unlock via the sysfs interface to clear all locks as a temporary workaround
  • Backport the lock‑length calculation fix to kernel releases that cannot receive the official patch

Generated by OpenCVE AI on August 18, 2026 at 04:16 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sun, 23 Aug 2026 13:15:00 +0000


Tue, 18 Aug 2026 03:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-20
CWE-479

Tue, 18 Aug 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-130
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Low


Sat, 15 Aug 2026 20:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-20
CWE-479

Sat, 15 Aug 2026 06:00:00 +0000

Type Values Removed Values Added
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.
Title mtd: spi-nor: swp: Improve locking user experience
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-23T12:46:54.916Z

Reserved: 2026-08-09T03:40:39.909Z

Link: CVE-2026-72155

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-15T06:21:33.250

Modified: 2026-08-23T13:16:40.843

Link: CVE-2026-72155

cve-icon Redhat

Severity : Low

Publid Date: 2026-08-15T00:00:00Z

Links: CVE-2026-72155 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-18T04:30:06Z

Weaknesses
  • CWE-130

    Improper Handling of Length Parameter Inconsistency