Hi Roberto, Krsysztof, On Wed, 2020-03-25 at 17:11 +0100, Roberto Sassu wrote: > From: Krzysztof Struczynski <krzysztof.struczynski@xxxxxxxxxx> > > Function hash_long() accepts unsigned long, while currently only one byte > is passed from ima_hash_key(), which calculates a key for ima_htable. Use > more bytes to avoid frequent collisions. > > Length of the buffer is not explicitly passed as a function parameter, > because this function expects a digest whose length is greater than the > size of unsigned long. Somehow I missed the original report of this problem https://lore.kern el.org/patchwork/patch/674684/. This patch is definitely better, but how many unique keys are actually being used? Is it anywhere near IMA_MEASURE_HTABLE_SIZE(512)? Do we need a new securityfs entry to display the number used? Mimi > > Cc: stable@xxxxxxxxxxxxxxx > Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider") > Signed-off-by: Krzysztof Struczynski <krzysztof.struczynski@xxxxxxxxxx> > --- > security/integrity/ima/ima.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h > index 64317d95363e..cf0022c2bc14 100644 > --- a/security/integrity/ima/ima.h > +++ b/security/integrity/ima/ima.h > @@ -177,7 +177,7 @@ extern struct ima_h_table ima_htable; > > static inline unsigned long ima_hash_key(u8 *digest) > { > - return hash_long(*digest, IMA_HASH_BITS); > + return hash_long(*((unsigned long *)digest), IMA_HASH_BITS); > } > > #define __ima_hooks(hook) \
