CVE-2025-68183

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

Triggering requires local syscalls against a file on the system — `setxattr`/`fsetxattr` on an EVM-protected xattr, `setfacl`, or `fremovexattr` — followed by an open/close of the target file. No network, adjacent-network, or physical path reaches the IMA appraisal hooks.

AC:LAttack complexity, low

The commit ships a deterministic reproducer: setting any EVM-protected xattr or a POSIX ACL unconditionally clears IMA_DIGSIG every time, with no memory-layout or timing luck involved. The enforce-mode variant needs a race against `process_measurement()`'s `MAY_WRITE` check, but `ima_reset_appraise_flags()` takes no `iint->mutex`, and the attacker drives both sides (one thread spinning on `setxattr("system.posix_acl_access")`, another on `open(O_WRONLY)`); the required IMA-appraise + EVM configuration is a shipped, supported Fedora/RHEL setup, not a rare build option.

PR:LPrivileges required, low

`vfs_set_acl()` invokes `security_inode_set_acl()` → `ima_inode_set_acl()` → `ima_reset_appraise_flags(inode, 0)` before `set_posix_acl()` ever reaches its `inode_owner_or_capable()` check, so an unprivileged user with no capabilities and no ownership of the file clears the cached IMA_DIGSIG bit on any signed appraised binary — the syscall fails with -EPERM only after the flag is already gone. No CAP_SYS_ADMIN is needed for this path, unlike the `security.ima` path guarded by `ima_protect_xattr()`.

UI:NUser interaction, none

The attacker performs the xattr/ACL operation and the file open/close entirely from their own process; no victim must mount a filesystem, open a file, or take any other action for the IMA_DIGSIG flag to be cleared and the signature to be replaced.

S:UScope, unchanged

The defeated control (IMA appraisal) and the affected resources (files and their security xattrs) live in the same kernel security authority; no VM, hypervisor, IOMMU, or sandbox boundary is crossed.

C:HConfidentiality impact, high

Clearing IMA_DIGSIG both drops the "signed files cannot be opened for write" enforcement at `ima_main.c:472` and lets `ima_update_xattr()` re-bless the modified content with a fresh hash plus EVM HMAC, so attacker-substituted content in an appraised executable passes appraisal and subsequently runs — typically in a privileged/service context — yielding full disclosure of data reachable by that code. This is the standard treatment of a code-integrity/signature-verification bypass; the bug itself contains no direct memory-read primitive.

I:HIntegrity impact, high

The file's IMA digital signature — the one integrity artifact a local attacker cannot forge, since it is verified against the trusted IMA keyring — is silently destroyed and replaced by a locally computed hash written through `__vfs_setxattr_noperm()`, which bypasses the `CAP_SYS_ADMIN` gate in `ima_protect_xattr()`. Combined with the lost write-block, this converts "signed and immutable" into "mutable and re-blessed on close", a complete integrity bypass of IMA appraisal for the affected file.

A:HAvailability impact, high

Once a signature is replaced by a plain hash, any policy carrying IMA_DIGSIG_REQUIRED (`appraise_type=imasig`) rejects that file in enforce mode, so appraised binaries become permanently unexecutable — applied to system-critical files such as init, sshd, or libc consumers this denies service and can leave the system unbootable, and the corrupted xattr persists on disk until the file is re-signed out of band.