[bug report] mm/hugetlb: possible data leak with huge pmd sharing

[bug report] mm/hugetlb: possible data leak with huge pmd sharing

[Miaohe Lin]

Hi all:
    When I investigate the mm/hugetlb code, I found there's a possible data leak issue
with huge pmd sharing. Thank about the below scene:

    1. Process A and process B shares huge pmd page.(vm_flags: VM_MAYSHARE but !VM_SHARED)
    2. Process A write fault a hugetlb page. As vm_flags is !VM_SHARED, a private copy of
hugetlb page will be installed in the pagetable via hugetlb_wp.
    3. Process A writes private data into hugetlb page.
    4. Process B can read process A's private data since hugetlb page is shared through huge
pmd sharing...

I think the above scene is possible. If so, huge pmd sharing for !VM_SHARED should be disabled
to fix this issue? Or am I miss something about hugetlb huge pmd sharing?

Any response would be appreciated.

Thanks! :)

Re: [bug report] mm/hugetlb: possible data leak with huge pmd sharing

[Mike Kravetz]

On 07/25/22 17:07, Miaohe Lin wrote:
> Hi all:
>     When I investigate the mm/hugetlb code, I found there's a possible data leak issue
> with huge pmd sharing. Thank about the below scene:
> 
>     1. Process A and process B shares huge pmd page.(vm_flags: VM_MAYSHARE but !VM_SHARED)

Thanks,

I often get confused about the setting of VM_MAYSHARE and VM_SHARED.  When
you throw in the possibility of shared and anonymous, then I struggle a bit
more.  At one time did an audit to get the meaning clear in my mind, but still
struggle with the meanings.

Is it possible to have VM_MAYSHARE and !VM_SHARED on a hugetlb vma?  I only
took a quick look and could not find a way for this to happen.  But, I
could have easily missed something.

-- 
Mike Kravetz

>     2. Process A write fault a hugetlb page. As vm_flags is !VM_SHARED, a private copy of
> hugetlb page will be installed in the pagetable via hugetlb_wp.
>     3. Process A writes private data into hugetlb page.
>     4. Process B can read process A's private data since hugetlb page is shared through huge
> pmd sharing...
> 
> I think the above scene is possible. If so, huge pmd sharing for !VM_SHARED should be disabled
> to fix this issue? Or am I miss something about hugetlb huge pmd sharing?
> 
> Any response would be appreciated.
> 
> Thanks! :)

Re: [bug report] mm/hugetlb: possible data leak with huge pmd sharing

[Miaohe Lin]

On 2022/7/26 2:35, Mike Kravetz wrote:
> On 07/25/22 17:07, Miaohe Lin wrote:
>> Hi all:
>>     When I investigate the mm/hugetlb code, I found there's a possible data leak issue
>> with huge pmd sharing. Thank about the below scene:
>>
>>     1. Process A and process B shares huge pmd page.(vm_flags: VM_MAYSHARE but !VM_SHARED)
> 
> Thanks,
> 
> I often get confused about the setting of VM_MAYSHARE and VM_SHARED.  When
> you throw in the possibility of shared and anonymous, then I struggle a bit
> more.  At one time did an audit to get the meaning clear in my mind, but still
> struggle with the meanings.
> 
> Is it possible to have VM_MAYSHARE and !VM_SHARED on a hugetlb vma?  I only
> took a quick look and could not find a way for this to happen.  But, I> could have easily missed something.

Thanks for your reply. It's possible to have VM_MAYSHARE and !VM_SHARED on a hugetlb vma
with below code snippet:

...
    fd = open("/root/huge/hugepagefile", O_CREAT | O_RDONLY, 0755);
    if (fd < 0) {
            perror("Open failed");
            exit(1);
    }

    addr = mmap(0, 32UL*1024*1024, PROT_READ, MAP_SHARED, fd, 0);
...

cat /proc/<pid>/smaps:

400000000000-400002000000 r--s 00000000 00:2f 153780886                  /root/huge/hugepagefile
Size:              32768 kB
KernelPageSize:     2048 kB
MMUPageSize:        2048 kB
...
VmFlags: rd mr me ms de ht

/* sh: VM_SHARED, mw: VM_MAYWRITE, ms:VM_MAYSHARE */

So vm_flags is VM_MAYSHARE but !VM_SHARED.

But in this case, it's readonly. So the above scene won't happen. Sorry for make noise.

> 

Thanks for your comment again. :)

Re: [bug report] mm/hugetlb: possible data leak with huge pmd sharing

[Mike Kravetz]

On 07/26/22 15:14, Miaohe Lin wrote:
> On 2022/7/26 2:35, Mike Kravetz wrote:
> > On 07/25/22 17:07, Miaohe Lin wrote:
> >> Hi all:
> >>     When I investigate the mm/hugetlb code, I found there's a possible data leak issue
> >> with huge pmd sharing. Thank about the below scene:
> >>
> >>     1. Process A and process B shares huge pmd page.(vm_flags: VM_MAYSHARE but !VM_SHARED)
> > 
> > Thanks,
> > 
> > I often get confused about the setting of VM_MAYSHARE and VM_SHARED.  When
> > you throw in the possibility of shared and anonymous, then I struggle a bit
> > more.  At one time did an audit to get the meaning clear in my mind, but still
> > struggle with the meanings.
> > 
> > Is it possible to have VM_MAYSHARE and !VM_SHARED on a hugetlb vma?  I only
> > took a quick look and could not find a way for this to happen.  But, I> could have easily missed something.
> 
> Thanks for your reply. It's possible to have VM_MAYSHARE and !VM_SHARED on a hugetlb vma
> with below code snippet:
> 
> ...
>     fd = open("/root/huge/hugepagefile", O_CREAT | O_RDONLY, 0755);
>     if (fd < 0) {
>             perror("Open failed");
>             exit(1);
>     }
> 
>     addr = mmap(0, 32UL*1024*1024, PROT_READ, MAP_SHARED, fd, 0);
> ...
> 
> cat /proc/<pid>/smaps:
> 
> 400000000000-400002000000 r--s 00000000 00:2f 153780886                  /root/huge/hugepagefile
> Size:              32768 kB
> KernelPageSize:     2048 kB
> MMUPageSize:        2048 kB
> ...
> VmFlags: rd mr me ms de ht
> 
> /* sh: VM_SHARED, mw: VM_MAYWRITE, ms:VM_MAYSHARE */
> 
> So vm_flags is VM_MAYSHARE but !VM_SHARED.
> 
> But in this case, it's readonly. So the above scene won't happen. Sorry for make noise.
> 

No worries!  And, thank you for looking at the pmd sharing code.  In concept
the functionality is simple.  However, details and edge cases make things
complicated.

If you are interested in the pmd sharing code, more eyes on this proposal
would be appreciated.

https://lore.kernel.org/linux-mm/20220706202347.95150-1-mike.kravetz@oracle.com/

-- 
Mike Kravetz

Re: [bug report] mm/hugetlb: possible data leak with huge pmd sharing

[Miaohe Lin]

On 2022/7/27 1:18, Mike Kravetz wrote:
> On 07/26/22 15:14, Miaohe Lin wrote:
>> On 2022/7/26 2:35, Mike Kravetz wrote:
>>> On 07/25/22 17:07, Miaohe Lin wrote:
>>>> Hi all:
>>>>     When I investigate the mm/hugetlb code, I found there's a possible data leak issue
>>>> with huge pmd sharing. Thank about the below scene:
>>>>
>>>>     1. Process A and process B shares huge pmd page.(vm_flags: VM_MAYSHARE but !VM_SHARED)
>>>
>>> Thanks,
>>>
>>> I often get confused about the setting of VM_MAYSHARE and VM_SHARED.  When
>>> you throw in the possibility of shared and anonymous, then I struggle a bit
>>> more.  At one time did an audit to get the meaning clear in my mind, but still
>>> struggle with the meanings.
>>>
>>> Is it possible to have VM_MAYSHARE and !VM_SHARED on a hugetlb vma?  I only
>>> took a quick look and could not find a way for this to happen.  But, I> could have easily missed something.
>>
>> Thanks for your reply. It's possible to have VM_MAYSHARE and !VM_SHARED on a hugetlb vma
>> with below code snippet:
>>
>> ...
>>     fd = open("/root/huge/hugepagefile", O_CREAT | O_RDONLY, 0755);
>>     if (fd < 0) {
>>             perror("Open failed");
>>             exit(1);
>>     }
>>
>>     addr = mmap(0, 32UL*1024*1024, PROT_READ, MAP_SHARED, fd, 0);
>> ...
>>
>> cat /proc/<pid>/smaps:
>>
>> 400000000000-400002000000 r--s 00000000 00:2f 153780886                  /root/huge/hugepagefile
>> Size:              32768 kB
>> KernelPageSize:     2048 kB
>> MMUPageSize:        2048 kB
>> ...
>> VmFlags: rd mr me ms de ht
>>
>> /* sh: VM_SHARED, mw: VM_MAYWRITE, ms:VM_MAYSHARE */
>>
>> So vm_flags is VM_MAYSHARE but !VM_SHARED.
>>
>> But in this case, it's readonly. So the above scene won't happen. Sorry for make noise.
>>
> 
> No worries!  And, thank you for looking at the pmd sharing code.  In concept
> the functionality is simple.  However, details and edge cases make things
> complicated.
> 
> If you are interested in the pmd sharing code, more eyes on this proposal
> would be appreciated.

Yes, thanks for your hard work. ;)

> 
> https://lore.kernel.org/linux-mm/20220706202347.95150-1-mike.kravetz@oracle.com/
>