summaryrefslogtreecommitdiffstats
path: root/fs/verity/measure.c
diff options
context:
space:
mode:
authorEric Biggers <ebiggers@google.com>2021-09-16 22:34:24 +0200
committerEric Biggers <ebiggers@google.com>2021-09-22 19:56:34 +0200
commit80f6e3080bfcf865062a926817b3ca6c4a137a57 (patch)
tree0e1b571d69cfc6874266e5f513ab0d12686cb47e /fs/verity/measure.c
parentLinux 5.15-rc2 (diff)
downloadlinux-80f6e3080bfcf865062a926817b3ca6c4a137a57.tar.xz
linux-80f6e3080bfcf865062a926817b3ca6c4a137a57.zip
fs-verity: fix signed integer overflow with i_size near S64_MAX
If the file size is almost S64_MAX, the calculated number of Merkle tree levels exceeds FS_VERITY_MAX_LEVELS, causing FS_IOC_ENABLE_VERITY to fail. This is unintentional, since as the comment above the definition of FS_VERITY_MAX_LEVELS states, it is enough for over U64_MAX bytes of data using SHA-256 and 4K blocks. (Specifically, 4096*128**8 >= 2**64.) The bug is actually that when the number of blocks in the first level is calculated from i_size, there is a signed integer overflow due to i_size being signed. Fix this by treating i_size as unsigned. This was found by the new test "generic: test fs-verity EFBIG scenarios" (https://lkml.kernel.org/r/b1d116cd4d0ea74b9cd86f349c672021e005a75c.1631558495.git.boris@bur.io). This didn't affect ext4 or f2fs since those have a smaller maximum file size, but it did affect btrfs which allows files up to S64_MAX bytes. Reported-by: Boris Burkov <boris@bur.io> Fixes: 3fda4c617e84 ("fs-verity: implement FS_IOC_ENABLE_VERITY ioctl") Fixes: fd2d1acfcadf ("fs-verity: add the hook for file ->open()") Cc: <stable@vger.kernel.org> # v5.4+ Reviewed-by: Boris Burkov <boris@bur.io> Link: https://lore.kernel.org/r/20210916203424.113376-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com>
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions