VYPR
Unrated severityNVD Advisory· Published Dec 16, 2025· Updated Apr 15, 2026

CVE-2025-68183

CVE-2025-68183

Description

In the Linux kernel, the following vulnerability has been resolved:

ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr

Currently when both IMA and EVM are in fix mode, the IMA signature will be reset to IMA hash if a program first stores IMA signature in security.ima and then writes/removes some other security xattr for the file.

For example, on Fedora, after booting the kernel with "ima_appraise=fix evm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima, installing/reinstalling a package will not make good reference IMA signature generated. Instead IMA hash is generated,

# getfattr -m - -d -e hex /usr/bin/bash # file: usr/bin/bash security.ima=0x0404...

This happens because when setting security.selinux, the IMA_DIGSIG flag that had been set early was cleared. As a result, IMA hash is generated when the file is closed.

Similarly, IMA signature can be cleared on file close after removing security xattr like security.evm or setting/removing ACL.

Prevent replacing the IMA file signature with a file hash, by preventing the IMA_DIGSIG flag from being reset.

Here's a minimal C reproducer which sets security.selinux as the last step which can also replaced by removing security.evm or setting ACL,

#include <stdio.h> #include <sys/xattr.h> #include <fcntl.h> #include <unistd.h> #include <string.h> #include <stdlib.h>

int main() { const char* file_path = "/usr/sbin/test_binary"; const char* hex_string = "030204d33204490066306402304"; int length = strlen(hex_string); char* ima_attr_value; int fd;

fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644); if (fd == -1) { perror("Error opening file"); return 1; }

ima_attr_value = (char*)malloc(length / 2 ); for (int i = 0, j = 0; i < length; i += 2, j++) { sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]); }

if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; }

const char* selinux_value= "system_u:object_r:bin_t:s0"; if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; }

close(fd);

return 0; }

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

A flaw in the Linux kernel's IMA code can corrupt integrity signatures when other security xattrs are modified.

Root

Cause

A bug exists in the Linux kernel's Integrity Measurement Architecture (IMA) where the IMA_DIGSIG flag, which marks that a file has a digital signature in the security.ima extended attribute, is incorrectly cleared when setting or removing a *different* security extended attribute, such as security.selinux or security.evm [1]. This defeats the expectation that IMA signatures should persist across writes to unrelated xattrs.

Exploitation

An attacker (or a legitimate process) can trigger the bug by first writing an IMA signature to a file and then, as a subsequent step, writing or removing another security xattr. The official description includes a minimal C reproducer that sets security.selinux after writing the IMA signature [1]. This scenario can occur automatically on systems booted with IMA and EVM in fix mode, as in the cited example where package installation causes IMA hashes to replace previously stored signatures [1].

Impact

The practical impact is that files that should have an IMA digital signature end up with only an IMA hash instead. This can undermine file integrity guarantees, leading to undetected tampering or broken verification chains. The example given shows that an IMA hash (0x04...) is incorrectly stored instead of the expected IMA signature [1].

Mitigation

A patch fixing the issue has been published in the Linux kernel stable tree, via commit d2993a7e98eb [1]. The fix prevents the IMA_DIGSIG flag from being reset when modifying non-IMA extended attributes, preserving the integrity signature. System administrators should apply the kernel update to maintain correct IMA behavior.

AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

2

Patches

0

No patches discovered yet.

Vulnerability mechanics

AI mechanics synthesis has not run for this CVE yet.

References

4

News mentions

0

No linked articles in our index yet.