diff options
| author | Patrick Callaghan <patrickc@linux.ibm.com> | 2019-11-11 14:23:48 -0500 |
|---|---|---|
| committer | Mimi Zohar <zohar@linux.ibm.com> | 2019-12-12 08:52:05 -0500 |
| commit | 96c9e1de99545ce4be1b5e7dff217a896ba96d06 (patch) | |
| tree | 295e290ddea43c07a7da9806fe65df87adf0269b /security | |
| parent | e42617b825f8073569da76dc4510bfa019b1c35a (diff) | |
| download | talos-op-linux-96c9e1de99545ce4be1b5e7dff217a896ba96d06.tar.gz talos-op-linux-96c9e1de99545ce4be1b5e7dff217a896ba96d06.zip | |
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')
| -rw-r--r-- | security/integrity/ima/ima_crypto.c | 4 |
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); |
