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: <b2030f8c-010e-7088-271e-e2398f7d37db@suse.com>
Date:   Tue, 7 May 2019 11:04:58 +0300
From:   Nikolay Borisov <nborisov@...e.com>
To:     Andreas Schwab <schwab@...e.de>, linux-riscv@...ts.infradead.org
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH] riscv: fix locking violation in page fault handler



On 7.05.19 г. 10:36 ч., Andreas Schwab wrote:
> When a user mode process accesses an address in the vmalloc area
> do_page_fault tries to unlock the mmap semaphore when it isn't locked.
> 
> Signed-off-by: Andreas Schwab <schwab@...e.de>
> ---
>  arch/riscv/mm/fault.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
> index 88401d5125bc..c51878e5a66a 100644
> --- a/arch/riscv/mm/fault.c
> +++ b/arch/riscv/mm/fault.c
> @@ -181,6 +181,7 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
>  	up_read(&mm->mmap_sem);
>  	/* User mode accesses just cause a SIGSEGV */
>  	if (user_mode(regs)) {
> +bad_area_do_trap:
>  		do_trap(regs, SIGSEGV, code, addr, tsk);
>  		return;
>  	}
> @@ -230,7 +231,7 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
>  		int index;
>  
>  		if (user_mode(regs))
> -			goto bad_area;
> +			goto bad_area_do_trap;
>  
>  		/*
>  		 * Synchronize this task's top level page-table
> 

In this case I think it will be a lot cleaner if you just duplicated the
do_trap call. On a slightly different note - is there any reason why
do_page_fault is such a spaghetti mess? At the very least the code under
no_context label could go into it's own function since it just kills the
process and never returns? Furthermore the whole vmalloc_fault just
cries for being factored  out in a function, it's explicitly in it's own
 block.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ