On Tue, 2026-10-13 at 16:46 +0200, Enrico Bravi wrote: > When recovering the IMA measurement list after kexec(), currently, the counter > of violations is not restored. This causes a mismatch between the real number > of violations and the value reported by the <securityfs>/ima/violations file. > > Restore the violations counter during the IMA measurement list recovery. This > mechanism does not take into account false positives. A legit all-zeros hash > is treated as a violation. > > Reported-by: Roberto Sassu <[email protected]> > Closes: https://github.com/linux-integrity/linux/issues/13 > Signed-off-by: Enrico Bravi <[email protected]>
Thanks Enrico! Reviewed-by: Roberto Sassu <[email protected]> Tested-by: Roberto Sassu <[email protected]> Roberto > --- > > Changes in v3: > - Reworked patch title and description. > - Reworked violations number recovery mechanism to not check for false > positive case. > > Changes in v2: > - Reworked patch description as suggested by Roberto. > - Added descriptive comment as suggested by Roberto. > - Moved from ima_algo_array[i].digest_size to ARRAY_SIZE() as suggested > by Roberto. > > --- > security/integrity/ima/ima_template.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/security/integrity/ima/ima_template.c > b/security/integrity/ima/ima_template.c > index 7034573fb41e..daa897ccaf58 100644 > --- a/security/integrity/ima/ima_template.c > +++ b/security/integrity/ima/ima_template.c > @@ -524,6 +524,13 @@ int ima_restore_measurement_list(loff_t size, void *buf) > ret = -EINVAL; > break; > } > + } else { > + /* > + * If the template hash found in the kexec buffer is all > + * zeros, record it as a violation. Note that this can > + * be a false positive. > + */ > + atomic_long_inc(&ima_num_violations); > } > > entry->pcr = !ima_canonical_fmt ? *(u32 *)(hdr[HDR_PCR].data) : > > base-commit: 1dc317438308c79cf90a6f14d3e4116347ea3716
