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] [day] [month] [year] [list]
Date:   Tue, 20 Jul 2021 16:28:10 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Chen Wandun <chenwandun@...wei.com>
Cc:     <0x7f454c46@...il.com>, <wangkefeng.wang@...wei.com>,
        <weiyongjun1@...wei.com>, <linux-mm@...ck.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm/mremap: fix memory account on do_munmap() failure

On Sat, 17 Jul 2021 18:19:42 +0800 Chen Wandun <chenwandun@...wei.com> wrote:

> mremap will account the delta between new_len and old_len in
> vma_to_resize, and then call move_vma when expanding an existing
> memory mapping. In function move_vma, there are two scenarios when
> calling do_munmap:
> 1. move_page_tables from old_addr to new_addr success
> 2. move_page_tables from old_addr to new_addr fail
> 
> In first scenario, it should account old_len if do_munmap fail,
> because the delta has already been accounted.
> 
> In second scenario, new_addr/new_len will assign to old_addr/old_len
> if move_page_table fail, so do_munmap is try to unmap new_addr actually,
> if do_munmap fail, it should account the new_len, because error code
> will be return from move_vma, and delta will be unaccounted.
> What'more, because of new_len == old_len, so account old_len also is
> OK.
> 
> In summary, account old_len will be correct if do_munmap fail.

Sorry, but I'm having trouble following that description.  Dmitry, could
you please review this change and then assist in clarifying the
changelog text?

Also, could it be argued that we're doing this in the wrong place? 
Should it be the responsibility of do_munmap() to fix up the accounting
if it is going to return an error?  Rather than expecting the
do_munmap() caller to fix up do_munmap()'s mess?

Thirdly, is the comment in there true?  Does this accounting error only
occur due to ENOMEM?  If that is the case then I am inclined not to
backport this fix into -stable kernels, as the error is so unlikely to
be triggered.  Thoughts on this?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ