linux-kernel - Re: [PATCH] mm/mprotect: reduce Committed_AS if memory protection is changed to PROT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1f5966cf-d40f-4a49-c2d0-e2c90eb5a124@huawei.com>
Date:   Wed, 27 Apr 2022 14:34:23 +0800
From:   liusongtang <liusongtang@...wei.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
CC:     <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
        <nixiaoming@...wei.com>, <young.liuyang@...wei.com>,
        <wangkefeng@...wei.com>
Subject: Re: [PATCH] mm/mprotect: reduce Committed_AS if memory protection is
 changed to PROT_NONE

On 2022/4/27 4:34, Andrew Morton wrote:

> On Tue, 26 Apr 2022 19:27:05 +0800 liusongtang <liusongtang@...wei.com> wrote:
>
>> If PROT_WRITE is set, the size of vm area will be added to Committed_AS.
>> However, if memory protection is changed to PROT_NONE,
>> the corresponding physical memory will not be used, but Committed_AS still
>> count the size of the PROT_NONE memory.
>>
>> This patch reduce Committed_AS and free the corresponding memory if
>> memory protection is changed to PROT_NONE.
>>
>> ...
>>
>> --- a/mm/mprotect.c
>> +++ b/mm/mprotect.c
>> @@ -497,6 +497,12 @@ mprotect_fixup(struct vm_area_struct *vma, struct vm_area_struct **pprev,
>>   	}
>>   
>>   success:
>> +	if ((newflags & (VM_READ | VM_WRITE | VM_EXEC | VM_LOCKED | VM_ACCOUNT)) == VM_ACCOUNT) {
>> +		zap_page_range(vma, start, end - start);
>> +		newflags &= ~VM_ACCOUNT;
>> +		vm_unacct_memory((end - start) >> PAGE_SHIFT);
>> +	}
>> +
>>   	/*
>>   	 * vm_flags and vm_page_prot are protected by the mmap_lock
>>   	 * held in write mode.
> Surprised.  If userspace does mprotect(addr, len.  PROT_NONE) then
> mprotect(addr, len.  PROT_READ), what is now at *addr?  Zeroes?
> .

1. In the case mentioned above, I think data in *addr is invalid after
mprotect(addr, len.  PROT_NONE), so clear it will not cause a problem.
2. Another idea is we can check if this vm area is populated before reduce Committed_AS.