CVE-2026-90333 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
dm-integrity: replace forgeable discard filler with a keyed sector marker
The discard-block check in dm_integrity_rw_tag() treats a stored tag of all 0xf6 bytes (DISCARD_FILLER) as proof a block was discarded and skips HMAC verification. allow_discards is only accepted in dm-integrity's standalone mode. An attacker with raw write access to the backing device, but without the integrity key, can stamp any block with an all-0xf6 tag and have it served as authentic.
Add a new "allow_discards_keyed" target argument that marks discarded blocks with a keyed checksum of (salt || sector) instead, computed by integrity_discard_checksum().
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The dm-integrity subsystem within the Linux kernel previously contained a critical authentication bypass vulnerability related to how it handled discard operations on block devices. This flaw stemmed from the design choice to use a static, forgeable filler value for marking discarded blocks. Specifically, when a block was marked as discarded, the system stored a tag consisting entirely of 0xf6 bytes in the integrity metadata. During read or write verification processes, specifically within the dm_integrity_rw_tag function, the presence of this specific all-zero-f-six pattern was treated as definitive proof that the data had been legitimately discarded by the storage subsystem. Consequently, the kernel would skip HMAC verification for any block bearing this tag, assuming its contents were irrelevant due to prior invalidation. This logic relied heavily on the assumption that only the operating system or trusted components could write these tags, ignoring the threat model where an attacker might have direct raw access to the underlying physical storage device.
The security implications of this design are severe for environments relying on dm-integrity in standalone mode with discard support enabled. An adversary possessing raw write access to the backing block device can exploit this weakness by manually writing a sector filled with 0xf6 bytes into the integrity metadata area without knowing the cryptographic key used for HMAC generation. Because the verification logic accepts this static pattern as valid proof of discarding, the attacker can effectively forge integrity tags for arbitrary data blocks. This allows an unprivileged or external actor to introduce maliciously crafted data that will be accepted by the kernel as authentic and intact, completely bypassing the intended cryptographic protections. The vulnerability essentially nullifies the confidentiality and integrity guarantees provided by dm-integrity in scenarios where physical or low-level access to the storage medium is possible but key material remains secret.
This issue highlights a fundamental flaw in handling state transitions for discarded data within authenticated block devices. By using a constant value rather than a cryptographically secure marker, the system failed to bind the discard status to specific sector identifiers and cryptographic secrets. The lack of uniqueness per sector meant that an attacker could reuse this forged tag across multiple blocks or replay it against different targets. This aligns with CWE-345 Insufficient Verification of Data Authenticity, as the application accepted data based on a superficial pattern match rather than rigorous cryptographic validation. Furthermore, from an ATT&CK perspective, this vulnerability facilitates techniques related to Defense Evasion and potentially Persistence if forged blocks are used to maintain unauthorized access or alter system state undetected by integrity monitoring tools.
To remediate this vulnerability, the Linux kernel developers implemented a structural change that replaces the static discard filler with a keyed sector marker. The solution introduces a new target argument called allow_discards_keyed which modifies the behavior of dm-integrity when handling discarded blocks. Instead of writing a constant 0xf6 pattern, the system now computes a keyed checksum for each discarded block using integrity_discard_checksum. This function generates a unique tag based on a combination of a random salt and the specific sector number being marked as discarded. Because this computation requires knowledge of the secret key associated with the dm-integrity target, an attacker without access to this key cannot generate valid discard tags. Any attempt by an external actor to write forged 0xf6 patterns will be rejected during verification because they do not match the expected keyed checksums derived from the sector metadata and salt.
The adoption of this keyed approach ensures that even if an adversary gains raw write access to the backing device, they cannot manipulate the integrity status of specific blocks without compromising the underlying cryptographic keys. This significantly raises the barrier for attackers attempting to bypass authentication mechanisms in storage subsystems. It reinforces the principle that discard operations must be treated with the same level of scrutiny as data writes, ensuring that metadata changes are cryptographically bound to their context. System administrators and developers utilizing dm-integrity should ensure they are running patched versions of the kernel where this keyed discard mechanism is available and properly configured via the allow_discards_keyed parameter when discarding functionality is required in standalone mode. This update restores confidence in the integrity guarantees provided by device-mapper targets against physical access threats.