CVE-2026-89720
nicheOut-of-Bounds Read in Linux Kernel UBIFS Superblock Signature Verification
The Linux kernel's UBIFS flash filesystem mis-validates the signature length declared in a mounted UBIFS image's superblock: ubifs_sb_verify_signature() adds the 64-byte signature-node header size instead of subtracting it, so a declared length up to 128 bytes larger than the node actually holds is accepted. When a crafted, signature-bearing UBIFS image is mounted, the inflated length is handed to the PKCS#7/DER parser, which reads past the end of the vmalloc'd scan buffer (c->sbuf) while walking the DER structure — before any cryptographic check happens. An attacker who can get a system to mount such an image triggers an out-of-bounds kernel memory read, which can crash the kernel (denial of service) and potentially disclose kernel heap contents. Realistically affected systems are those with UBIFS-enabled kernels that mount untrusted images — mainly raw-NAND embedded devices (routers, IoT, industrial controllers, dev boards) and firmware-analysis/test hosts; correctly built, legitimately signed images are unaffected. No public proof-of-concept exists, the issue is not in the CISA KEV catalog, and no exploitation in the wild is known.
What to do: Upgrade to a kernel release containing the ubifs signature-length fix as soon as your distribution or device vendor ships it. Until patched, do not mount UBIFS images from untrusted sources, and restrict mount capability (CAP_SYS_ADMIN) and auto-mounting of flash images on embedded and test systems. Prioritize monitoring any infrastructure that routinely mounts third-party or user-supplied UBIFS images for kernel crashes or oopses in ubifs_read_superblock paths.
| Linux kernel (UBIFS driver, ubifs_sb_verify_signature) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: ubifs: fix out-of-bounds read in signature length check ubifs_sb_verify_signature() bounds the on-disk ubifs_sig_node->len field before handing the signature payload to verify_pkcs7_signature(), but the check has the wrong sign: if (le32_to_cpu(signode->len) > snod->len + sizeof(struct ubifs_sig_node)) The signature bytes start sizeof(struct ubifs_sig_node) (UBIFS_SIG_NODE_SZ, 64 bytes) into the node, so the payload is at most snod->len - sizeof(struct ubifs_sig_node) bytes long. Adding the header size instead of subtracting it accepts a declared length up to 2 * UBIFS_SIG_NODE_SZ larger than the node actually holds -- past the end of c->sbuf, which is vmalloc(c->leb_size). verify_pkcs7_signature() -> pkcs7_parse_message() -> asn1_ber_decoder() is then handed that inflated length and reads beyond the allocation while walking the DER headers. The node length comes straight from the mounted image, so a crafted signed UBIFS image reaches this via ubifs_read_superblock() before the signature is cryptographically checked. snod->len is guaranteed to be >= UBIFS_SIG_NODE_SZ by the node scanner (c->ranges[UBIFS_SIG_NODE].min_len == UBIFS_SIG_NODE_SZ), so the corrected subtraction cannot underflow. Legitimately signed images are unaffected: a correct superblock never declares a signature longer than the node it is embedded in.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
In the news0 stories
No ingested article mentions this CVE yet.