On 4/10/2026 8:54 PM, Danny Hu wrote:
When IMA appraisal/measurement is enabled for executables, an
AUDIT_INTEGRITY_DATA (type=1800) audit message is emitted from
ima_collect_measurement() if a process receives SIGKILL while reading
a file from a slow-read filesystem.
Configuration:
- IMA policy configured: measure func=BPRM_CHECK mask=MAY_EXEC
- stacked overlayfs with git binary on squashfs (compressed, read-only
filesystem on flash storage)
- Kernel version 6.12.68
Steps to reproduce:
$ echo 3 > /proc/sys/vm/drop_caches; timeout --signal=KILL 0.05s git
Killed
$ dmesg | tail -n 1
audit: type=1800 audit(1775843687.948:10): pid=14049 uid=0
auid=72198551 ses=2 op=collect_data cause=failed comm="timeout"
name="git" dev="overlay" ino=11529215046068473654 res=0 errno=0
The drop_caches evicts both the page cache (forcing squashfs to
re-read and decompress from flash on the next access) and the inode
cache (forcing IMA to re-hash). The timeout command execs git and
sends SIGKILL after 50ms.
During that window, IMA is reading the file page by page in
integrity_kernel_read. Since the page cache is cold, the squashfs read
path must decompress blocks from flash storage. This IO operation
causes the kernel to check for signals and return -EINTR. This
propagates up through integrity_kernel_rea to ima_calc_file_hash and
finally ima_collect_measurement, which logs the collect_data failure.
The log is more commonly observed during boot, when the page cache is
cold and all binaries must be read from flash for the first time. Many
services may start and stop concurrently, and any process that
receives SIGKILL while IMA is reading the file from flash for the
first time will produce this audit message.
I believe this log is spurious because the process is being killed;
therefore, an interrupted file read is the expected outcome. The audit
message in this case does not indicate any integrity violations as the
file has not been tampered with. Lastly, the log's presence can
mislead administrators or monitoring tools into believing a security
event occurred when it was only an expected process kill.
Hi Danny
it still shows an unexpected condition occurred in IMA. I think it is
worth keeping the audit message.
Thanks
Roberto
Questions for the IMA maintainers:
1. Is this the intended behavior? Should ima_collect_measurement still
emit the audit log when the failure is due to a fatal signal?
2. If not, could a potential fix be to skip the generation of the
audit log in ima_collect_measurement (result == -EINTR &&
fatal_signal_pending(current))?
Thanks,
Danny
