Re: ima: audit log emitted from ima_collect_measurement when SIGKILL interrupts reads from slow-read filesystems

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