aboutsummaryrefslogtreecommitdiff
path: root/security/integrity/ima/ima_crypto.c
diff options
context:
space:
mode:
authorPatrick Callaghan <patrickc@linux.ibm.com>2019-11-11 14:23:48 -0500
committerMimi Zohar <zohar@linux.ibm.com>2019-12-12 08:52:05 -0500
commit96c9e1de99545ce4be1b5e7dff217a896ba96d06 (patch)
tree295e290ddea43c07a7da9806fe65df87adf0269b /security/integrity/ima/ima_crypto.c
parente42617b825f8073569da76dc4510bfa019b1c35a (diff)
downloadlinux-96c9e1de99545ce4be1b5e7dff217a896ba96d06.tar.gz
ima: avoid appraise error for hash calc interrupt
The integrity_kernel_read() call in ima_calc_file_hash_tfm() can return a value of 0 before all bytes of the file are read. A value of 0 would normally indicate an EOF. This has been observed if a user process is causing a file appraisal and is terminated with a SIGTERM signal. The most common occurrence of seeing the problem is if a shutdown or systemd reload is initiated while files are being appraised. The problem is similar to commit <f5e1040196db> (ima: always return negative code for error) that fixed the problem in ima_calc_file_hash_atfm(). Suggested-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Patrick Callaghan <patrickc@linux.ibm.com> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Diffstat (limited to 'security/integrity/ima/ima_crypto.c')
-rw-r--r--security/integrity/ima/ima_crypto.c4
1 files changed, 3 insertions, 1 deletions
diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
index 73044fc6a952..7967a6904851 100644
--- a/security/integrity/ima/ima_crypto.c
+++ b/security/integrity/ima/ima_crypto.c
@@ -362,8 +362,10 @@ static int ima_calc_file_hash_tfm(struct file *file,
rc = rbuf_len;
break;
}
- if (rbuf_len == 0)
+ if (rbuf_len == 0) { /* unexpected EOF */
+ rc = -EINVAL;
break;
+ }
offset += rbuf_len;
rc = crypto_shash_update(shash, rbuf, rbuf_len);