A vma with vm_pgoff large enough to overflow a loff_t type when
converted to a byte offset can be passed via the remap_file_pages
system call. The hugetlbfs mmap routine uses the byte offset to
calculate reservations and file size.
A sequence such as:
mmap(0x20a00000, 0x600000, 0, 0x66033, -1, 0);
remap_file_pages(0x20a00000, 0x600000, 0, 0x20000000000000, 0);
will result in the following when task exits/file closed,
kernel BUG at mm/hugetlb.c:749!
Call Trace:
hugetlbfs_evict_inode+0x2f/0x40
evict+0xcb/0x190
__dentry_kill+0xcb/0x150
__fput+0x164/0x1e0
task_work_run+0x84/0xa0
exit_to_usermode_loop+0x7d/0x80
do_syscall_64+0x18b/0x190
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
The overflowed pgoff value causes hugetlbfs to try to set up a
mapping with a negative range (end < start) that leaves invalid
state which causes the BUG.
Reported-by: Nic Losby <[email protected]>
Signed-off-by: Mike Kravetz <[email protected]>
---
fs/hugetlbfs/inode.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 8fe1b0aa2896..cb288dec5564 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -127,12 +127,13 @@ static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma)
vma->vm_ops = &hugetlb_vm_ops;
/*
- * Offset passed to mmap (before page shift) could have been
- * negative when represented as a (l)off_t.
+ * page based offset in vm_pgoff could be sufficiently large to
+ * overflow a (l)off_t when converted to byte offset.
*/
- if (((loff_t)vma->vm_pgoff << PAGE_SHIFT) < 0)
+ if (vma->vm_pgoff && ((loff_t)vma->vm_pgoff << PAGE_SHIFT) <= 0)
return -EINVAL;
+ /* must be huge page aligned */
if (vma->vm_pgoff & (~huge_page_mask(h) >> PAGE_SHIFT))
return -EINVAL;
--
2.13.6
Hi Mike,
On 2018/3/8 7:59, Mike Kravetz wrote:
> A vma with vm_pgoff large enough to overflow a loff_t type when
> converted to a byte offset can be passed via the remap_file_pages
> system call. The hugetlbfs mmap routine uses the byte offset to
> calculate reservations and file size.
>
> A sequence such as:
> mmap(0x20a00000, 0x600000, 0, 0x66033, -1, 0);
> remap_file_pages(0x20a00000, 0x600000, 0, 0x20000000000000, 0);
> will result in the following when task exits/file closed,
> kernel BUG at mm/hugetlb.c:749!
> Call Trace:
> hugetlbfs_evict_inode+0x2f/0x40
> evict+0xcb/0x190
> __dentry_kill+0xcb/0x150
> __fput+0x164/0x1e0
> task_work_run+0x84/0xa0
> exit_to_usermode_loop+0x7d/0x80
> do_syscall_64+0x18b/0x190
> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>
> The overflowed pgoff value causes hugetlbfs to try to set up a
> mapping with a negative range (end < start) that leaves invalid
> state which causes the BUG.
>
> Reported-by: Nic Losby <[email protected]>
> Signed-off-by: Mike Kravetz <[email protected]>
> ---
> fs/hugetlbfs/inode.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index 8fe1b0aa2896..cb288dec5564 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -127,12 +127,13 @@ static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma)
> vma->vm_ops = &hugetlb_vm_ops;
>
> /*
> - * Offset passed to mmap (before page shift) could have been
> - * negative when represented as a (l)off_t.
> + * page based offset in vm_pgoff could be sufficiently large to
> + * overflow a (l)off_t when converted to byte offset.
> */
> - if (((loff_t)vma->vm_pgoff << PAGE_SHIFT) < 0)
> + if (vma->vm_pgoff && ((loff_t)vma->vm_pgoff << PAGE_SHIFT) <= 0)
> return -EINVAL;
This seems still no the right fix, taking the following case as an example:
mmap(0x20a00000, 0x600000, 0, 0x66033, -1, 0);
remap_file_pages(0x20a00000, 0x600000, 0, 0x0020001000000000, 0);
You should just check the highest PAGE_SHIFT+1 bits of pgoff in you want check
at this point, right?
However, region_chg makes me a litter puzzle that when its return value < 0, sometime
adds_in_progress is added like this case, while sometime it is not. so why not just
change at the beginning of region_chg ?
if (f > t)
return -EINVAL;
Thanks
Yisheng
>
> + /* must be huge page aligned */
> if (vma->vm_pgoff & (~huge_page_mask(h) >> PAGE_SHIFT))
> return -EINVAL;
>
>
On 03/07/2018 05:35 PM, Yisheng Xie wrote:
> Hi Mike,
>
> On 2018/3/8 7:59, Mike Kravetz wrote:
>> A vma with vm_pgoff large enough to overflow a loff_t type when
>> converted to a byte offset can be passed via the remap_file_pages
>> system call. The hugetlbfs mmap routine uses the byte offset to
>> calculate reservations and file size.
>>
>> A sequence such as:
>> mmap(0x20a00000, 0x600000, 0, 0x66033, -1, 0);
>> remap_file_pages(0x20a00000, 0x600000, 0, 0x20000000000000, 0);
>> will result in the following when task exits/file closed,
>> kernel BUG at mm/hugetlb.c:749!
>> Call Trace:
>> hugetlbfs_evict_inode+0x2f/0x40
>> evict+0xcb/0x190
>> __dentry_kill+0xcb/0x150
>> __fput+0x164/0x1e0
>> task_work_run+0x84/0xa0
>> exit_to_usermode_loop+0x7d/0x80
>> do_syscall_64+0x18b/0x190
>> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>>
>> The overflowed pgoff value causes hugetlbfs to try to set up a
>> mapping with a negative range (end < start) that leaves invalid
>> state which causes the BUG.
>>
>> Reported-by: Nic Losby <[email protected]>
>> Signed-off-by: Mike Kravetz <[email protected]>
>> ---
>> fs/hugetlbfs/inode.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
>> index 8fe1b0aa2896..cb288dec5564 100644
>> --- a/fs/hugetlbfs/inode.c
>> +++ b/fs/hugetlbfs/inode.c
>> @@ -127,12 +127,13 @@ static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma)
>> vma->vm_ops = &hugetlb_vm_ops;
>>
>> /*
>> - * Offset passed to mmap (before page shift) could have been
>> - * negative when represented as a (l)off_t.
>> + * page based offset in vm_pgoff could be sufficiently large to
>> + * overflow a (l)off_t when converted to byte offset.
>> */
>> - if (((loff_t)vma->vm_pgoff << PAGE_SHIFT) < 0)
>> + if (vma->vm_pgoff && ((loff_t)vma->vm_pgoff << PAGE_SHIFT) <= 0)
>> return -EINVAL;
>
> This seems still no the right fix, taking the following case as an example:
> mmap(0x20a00000, 0x600000, 0, 0x66033, -1, 0);
> remap_file_pages(0x20a00000, 0x600000, 0, 0x0020001000000000, 0);
>
> You should just check the highest PAGE_SHIFT+1 bits of pgoff in you want check
> at this point, right?
Yes, thank you!
That would be the correct check and also much simpler. Something like,
unsigned long ovfl_mask;
ovfl_mask = (1UL << (PAGE_SHIFT + 1)) - 1;
ovfl_mask <<= ((sizeof(unsigned long) * BITS_PER_BYTE) -
(PAGE_SHIFT + 1));
if (vma->vm_pgoff & ovfl_mask)
return -EINVAL;
> However, region_chg makes me a litter puzzle that when its return value < 0, sometime
> adds_in_progress is added like this case, while sometime it is not. so why not just
> change at the beginning of region_chg ?
> if (f > t)
> return -EINVAL;
If region_chg returns a value < 0, this indicates an error and adds_in_progress
should not be incremented. In the case of this bug, region_chg was passed
values where f > t. Of course, this should never happen. But, because it
assumed f <= t, it returned a negative count needed huge page reservations.
The calling code interpreted the negative value as an error and a subsequent
region_add or region_abort.
I am not opposed to adding the suggested "if (f > t)". However, the
region tracking routines are simple helpers only used by the hugetlbfs
code and the assumption is that they are being called correctly. As
such, I would prefer to leave off the check. But, this is the second
time they have been called incorrectly due to insufficient argument
checking. If we do add this to region_chg, I would also add the check
to all region_* routines for consistency.
I will send out a V2 of this patch tomorrow with the corrected overflow
checking and possibly checks added to the region_* routines.
--
Mike Kravetz
On 03/07/2018 08:25 PM, Mike Kravetz wrote:
> On 03/07/2018 05:35 PM, Yisheng Xie wrote:
>> However, region_chg makes me a litter puzzle that when its return value < 0, sometime
>> adds_in_progress is added like this case, while sometime it is not. so why not just
>> change at the beginning of region_chg ?
>> if (f > t)
>> return -EINVAL;
>
> If region_chg returns a value < 0, this indicates an error and adds_in_progress
> should not be incremented. In the case of this bug, region_chg was passed
> values where f > t. Of course, this should never happen. But, because it
> assumed f <= t, it returned a negative count needed huge page reservations.
> The calling code interpreted the negative value as an error and a subsequent
> region_add or region_abort.
>
> I am not opposed to adding the suggested "if (f > t)". However, the
> region tracking routines are simple helpers only used by the hugetlbfs
> code and the assumption is that they are being called correctly. As
> such, I would prefer to leave off the check. But, this is the second
> time they have been called incorrectly due to insufficient argument
> checking. If we do add this to region_chg, I would also add the check
> to all region_* routines for consistency.
I really did not want to add the (f > t) check to the region_* routines.
As mentioned we should never encounter this condition. Adding the check
here says that we missed discovering an error at higher levels. Therefore,
I went back and examined the callers of region_chg. There are only 2:
hugetlb_reserve_pages and __vma_reservation_common. hugetlb_reserve_pages
is called to set up a reservation for a mapping. __vma_reservation_common
is called to check on an existing reservation, and only operates on a
single huge page. With this in mind, a check in hugetlb_reserve_pages
would be sufficient. Therefore, I added an explicit check to that routine
and printed a warning if ever encountered.
> I will send out a V2 of this patch tomorrow with the corrected overflow
> checking and possibly checks added to the region_* routines.
v2 will be sent shortly. In v2 I Cc stable as this is an issue for
stable branches as well.
--
Mike Kravetz