Possible bug/unintended behaviour with bpf_ima_file_hash()

Possible bug/unintended behaviour with bpf_ima_file_hash()

[Matthews, Isaac]

Using bpf_ima_file_hash() from kernel 6.0.

When using bpf_ima_file_hash() with the lsm.s/file_open hook, a hash of the file is only sometimes returned.  This is because the FMODE_CAN_READ flag is set after security_file_open() is already called, and ima_calc_file_hash() only checks for FMODE_READ not FMODE_CAN_READ in order to decide if a new instance needs to be opened. Because of this, if a file passes the FMODE_READ check  it will fail to be hashed as FMODE_CAN_READ has not yet been set.

To demonstrate: if the file is opened for write for example, when ima_calc_file_hash() is called and the file->f_mode is checked against FMODE_READ, a new file instance is opened with the correct flags and a hash is returned. If the file is opened for read, a new file instance is not returned in ima_calc_file_hash() as (!(file->f_mode & FMODE_READ)) is now false. When __kernel_read() is called as part of ima_calc_file_hash_tfm() it will fail on if (!(file->f_mode & FMODE_CAN_READ)) and so no hash will be returned by bpf_ima_file_hash().

If possible could someone please advise me as to whether this is intended behaviour, and is it possible to either modify the flags with eBPF or to open a new instance with the correct flags set as IMA does currently. Alternatively, would a better solution be adding a check for FMODE_CAN_READ to ima_calc_file_hash()?

Thanks for your help.