Medium [CVE-2026-72155] Improve locking user experience
This medium-severity Red Hat Linux advisory covers CVE-2026-72155 affecting Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 9, Red Hat package: kernel-rt.
Aggregated and source-linked by VulniPulse. Data sources, validation and limitations.
VulniPulse record published Record updated
Android app · Google Play
Monitor future Red Hat Linux CVEs from your phone.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 34 official vendor sources and 160+ reviewed platform categories.
Summary
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. When a user attempts to unlock specific blocks on a Serial Peripheral Interface (SPI) NOR flash device, particularly those at the beginning of the device, the operation may fail.
This occurs due to an incorrect calculation of the `lock_len` parameter, which prevents the intended blocks from being unlocked.
Affected versions
No affected-version range was extracted from the source record. The vendor advisory is authoritative — check it before change work.
Official advisory · medium-confidence parse· fetched 25 days ago·verify at source
Fixed versions
No fixed release is recorded yet. That does not prove no patch exists — confirm against the vendor advisory.
Official advisory · medium-confidence parse· fetched 25 days ago·verify at source
Mitigation
The source record does not include mitigation steps. That is not a statement that no fix exists — read the vendor advisory below for the authoritative guidance.
Official advisory · medium-confidence parse· fetched 25 days ago·verify at source
Discussion(0)
No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.
Sign in to join the discussion.