summaryrefslogtreecommitdiff
path: root/Meta/build-root-filesystem.sh
diff options
context:
space:
mode:
authorLiav A <liavalb@gmail.com>2021-10-22 11:59:31 +0300
committerAndreas Kling <kling@serenityos.org>2021-10-22 13:13:00 +0200
commit026687816d65a28bd3a553c7a343d8b3421a9483 (patch)
tree66ee4ad8444a865f6a65a784a6b51f93cdf539be /Meta/build-root-filesystem.sh
parent89afd4d063b79ef2eba81d1bfc7857c388679c5e (diff)
downloadserenity-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