CVE-2021-47055

What it actually does

The flaw permits processes holding only read access to MTD device nodes to invoke MEMLOCK, MEMUNLOCK, OTPLOCK and MEMSETBADBLOCK ioctls, bypassing the intended requirement for write permission when altering protection bits or the bad-block table.

Why it matters to the business

Attackers or compromised low-privilege processes can tamper with flash protection settings or bad-block metadata on embedded and storage devices, risking data corruption, loss of write-once guarantees, or circumvention of hardware write-protect mechanisms.

How an attack unfolds

An attacker obtains a file descriptor to an MTD character device opened with O_RDONLY, then directly issues the four affected ioctls; because the kernel did not enforce write permission checks, the operations succeed and modify protection bits or the bad-block table without requiring elevated file access rights.

How to fix it

Upgrade the Linux kernel to a version containing the fix that adds the required write-permission checks before allowing the four ioctls; rebuild and deploy the updated kernel on all affected systems; verify that MTD device nodes are not world-readable when write operations must remain restricted.

How to confirm the fix worked

Confirm the running kernel contains the permission checks by inspecting the mtd_ioctl function or by attempting the ioctls from a read-only file descriptor and verifying EACCES is returned; review device-node permissions and audit logs after the update.

Typical attack path

1. Locate accessible /dev/mtd* or /dev/mtdblock* nodes
2. Open the node with O_RDONLY
3. Issue MEMLOCK/MEMUNLOCK/OTPLOCK/MEMSETBADBLOCK ioctl
4. Observe or abuse altered protection state or bad-block table

How to detect it

Search kernel audit logs, strace output, or eBPF traces for MEMLOCK, MEMUNLOCK, OTPLOCK or MEMSETBADBLOCK ioctls originating from processes that opened MTD devices read-only; correlate with unexpected changes to flash protection registers or bad-block tables.

• ioctl.*MEMLOCK
• ioctl.*MEMUNLOCK
• ioctl.*OTPLOCK
• ioctl.*MEMSETBADBLOCK

What your security team should do

• Prioritize kernel updates on systems exposing MTD devices
• Harden permissions on /dev/mtd* nodes to least privilege
• Add monitoring for unexpected MTD ioctl usage from non-root processes
• Re-test embedded firmware builds that rely on MTD write-once semantics