Cloudanix VulnDB

CVE-2026-99037

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A configuration mistake in the Linux encryption layer lets a fully privileged administrator accidentally crash the computer when setting up certain encrypted disks.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

A misallocation in dm-crypt when an AEAD cipher is paired with the lmk IV generator causes crypt_setkey to index beyond the single allocated tfms_aead entry and invoke crypto_aead_setkey on uninitialized memory, producing an oops.

Why it matters to the business

A local root user can crash the system during device-mapper table load, resulting in denial of service and potential loss of availability for encrypted volumes until the system is restarted.

How an attack unfolds

An attacker with root privileges constructs a dm-crypt table entry that specifies an AEAD cipher together with the lmk IV mode and the integrity:28:aead flag, loads the table, and triggers the out-of-bounds read and subsequent key-setting call that panics the kernel.

How to fix it

Upgrade to a kernel containing the upstream fix that rejects lmk IV mode when an AEAD cipher is requested; rebuild and reboot with the corrected dm-crypt module.

How to confirm the fix worked

Attempt to load a capi:gcm(aes)-lmk table line with integrity:28:aead; the operation must now fail with an explicit error instead of oopsing. Verify the presence of the rejection logic in the running crypt_iv_lmk module.

Typical attack path

  1. Obtain root privileges on the target system
  2. Craft a dm-crypt table line containing an AEAD cipher and lmk IV generator
  3. Load the table via dmsetup or equivalent
  4. Observe kernel oops and system crash

How to detect it

Review kernel logs for oopses containing dm-crypt, crypt_alloc_tfms_aead, or lmk references around the time of volume activation; inspect audit logs for dmsetup or cryptsetup invocations that include lmk and AEAD strings.

What your security team should do

  • Apply the dm-crypt fix in the next kernel update window
  • Audit local scripts and configuration that generate dm-crypt tables for lmk+AEAD combinations
  • Monitor for unexpected kernel crashes during encrypted volume activation

The record

In the Linux kernel, the following vulnerability has been resolved: dm-crypt: reject the lmk IV mode with AEAD ciphers A "capi:" table line that pairs an AEAD cipher with the lmk IV mode, for example "capi:gcm(aes)-lmk" with the integrity:28:aead option, causes an oops when it is loaded. lmk sets tfms_count to 64, but crypt_alloc_tfms_aead only allocates one transform, so crypt_setkey reads past the end of the tfms_aead array and calls crypto_aead_setkey on the values it finds there. lmk exists for compatibility with Loop-AES, which uses CBC, so refuse it with an AEAD cipher rather than allocate 64 AEAD transforms. The check cannot go in crypt_iv_lmk_ctr with the other lmk checks, because the IV constructor runs after crypt_set_key. Note that this is not a security bug because the memory corruption can only be triggered by root.

Affected packages

Ecosystem Package Introduced Fixed