diff options
author | Liav A <liavalb@gmail.com> | 2021-10-22 11:59:31 +0300 |
---|---|---|
committer | Andreas Kling <kling@serenityos.org> | 2021-10-22 13:13:00 +0200 |
commit | 026687816d65a28bd3a553c7a343d8b3421a9483 (patch) | |
tree | 66ee4ad8444a865f6a65a784a6b51f93cdf539be /Meta/build-root-filesystem.sh | |
parent | 89afd4d063b79ef2eba81d1bfc7857c388679c5e (diff) | |
download | serenity-026687816d65a28bd3a553c7a343d8b3421a9483.zip |
Kernel: Fix restrictions in is_allowed_to_mmap_to_userspace function
This small change simplifies the function a bit but also fixes a problem
with it.
Let's take an example to see this:
Let's say we have a reserved range between 0xe0000 to 0xfffff (EBDA),
then we want to map from the memory device (/dev/mem) the entire
EBDA to a program. If a program tries to map more than 131072 bytes,
the current logic will work - the start address is 0xe0000, and ofcourse
it's below the limit, hence it passes the first two restrictions.
Then, the third if statement will fail if we try to mmap more than
the said allowed bytes.
However, let's take another scenario, where we try to mmap from
0xf0000 - but we try to mmap less than 131072 - but more than 65536.
In such case, we again pass the first two if statements, but the third
one is passed two, because it doesn't take into account the offseted
address from the start of the reserved range (0xe0000). In such case,
a user can easily mmap 65535 bytes above 0x100000. This might
seem negligible. However, it's still a severe bug that can theoretically
be exploited into a info leak or tampering with important kernel
structures.
Diffstat (limited to 'Meta/build-root-filesystem.sh')
0 files changed, 0 insertions, 0 deletions