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]
Date:	Thu, 14 Nov 2013 15:33:41 +0800
From:	Chen Gang <gang.chen@...anux.com>
To:	Hugh Dickins <hughd@...gle.com>
CC:	Jeff Dike <jdike@...toit.com>, Richard Weinberger <richard@....at>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	uml-devel <user-mode-linux-devel@...ts.sourceforge.net>,
	uml-user <user-mode-linux-user@...ts.sourceforge.net>
Subject: Re: [PATCH] arch: um: kernel: skas: mmu: remove pmd_free() and pud_free()
 for failure processing in init_stub_pte()

On 11/14/2013 02:48 PM, Chen Gang wrote:
>> >From the look of it, if an error did occur in init_stub_pte(),
>> > then the special mapping of STUB_CODE and STUB_DATA would not
>> > be installed, so this area would be invisible to munmap and exit,
>> > and with your patch then the pages allocated likely to be leaked.
>> > 
> It sounds reasonable to me: "although 'pgd' related with 'mm', but they
> are not installed". But just like you said originally: "better get ACK
> from some mm guys".
> 
> 
> Hmm... is it another issue: "after STUB_CODE succeeds, but STUB_DATA
> fails, the STUB_CODE will be leaked".
> 
> 
>> > Which is not to say that the existing code is actually correct:
>> > you're probably right that it's technically wrong.  But it would
>> > be very hard to get init_stub_pte() to fail, and has anyone
>> > reported a problem with it?  My guess is not, and my own
>> > inclination to dabble here is zero.
>> > 
> Yeah.
> 

If we can not get ACK from any mm guys, and we have no enough time
resource to read related source code, for me, I still recommend to
remove p?d_free() in failure processing.

In the worst cases, we will leak a little memory, and no any other
negative effect, it is an executable way which is no any risks.

For current mm implementation, it seems we can not assume any thing,
although they sounds (or should be) reasonable (include what you said
about mm).


Thanks.
-- 
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists