CVE-2026-72155: Linux Vulnerability

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.

Metrics

EPSS Probability

0.21%

11.0th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

Vendor	Product	Versions
Linux	Linux	>= 3dd8012a8eeb3702fa17450ec1a16a3f38af138d, < 9a0d8dec3d11ca95d67537ea8fa6ee2730a5038a; >= 3dd8012a8eeb3702fa17450ec1a16a3f38af138d, < dc341272cf8e15a2c511db3c4df5dab8adf70ad0; >= 3dd8012a8eeb3702fa17450ec1a16a3f38af138d, < 6110ab5ffd84e8daa654652446a03ce2f77580a7; >= 3dd8012a8eeb3702fa17450ec1a16a3f38af138d, < c0806df5cf806545160f3fdac3c888926ceac557; >= 3dd8012a8eeb3702fa17450ec1a16a3f38af138d, < 12d4d69221159e6d0e72400ec81195d691169b53; >= 3dd8012a8eeb3702fa17450ec1a16a3f38af138d, < e1d456b26bf23e30db305a6184e8abd9ab68bbf2
Linux	Linux	4.6

References

Timeline

Published: Aug 15, 2026
Last Modified: Aug 17, 2026
Status: Received

Frequently Asked Questions

What is CVE-2026-72155?

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.

How severe is CVE-2026-72155?

Severity scoring for CVE-2026-72155 is pending analysis. The EPSS model estimates a 0.21% probability of exploitation in the next 30 days.

How do I fix CVE-2026-72155?

Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →