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: Sun, 4 Feb 2024 07:41:41 +0000
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Jiaxun Yang <jiaxun.yang@...goat.com>
Cc: Oleg Nesterov <oleg@...hat.com>, Thomas Bogendoerfer <tsbogend@...ha.franken.de>, 
	Andrew Morton <akpm@...ux-foundation.org>, Ben Hutchings <ben@...adent.org.uk>, 
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-mips@...r.kernel.org, linux-mm@...ck.org, 
	Xi Ruoyao <xry111@...111.site>
Subject: Re: [PATCH v2 0/3] Handle delay slot for extable lookup

On Sat, 3 Feb 2024 at 13:56, Jiaxun Yang <jiaxun.yang@...goat.com> wrote:
>
> Given that exception_ip is guarded by !user_mode(regs), EPC must points
> to a kernel text address. There is no way accessing kernel text will generate such
> exception..

Sadly, that's not actually likely true.

The thing is, the only reason for the code in
get_mmap_lock_carefully() is for kernel bugs. IOW, some kernel bug
with a wild pointer, and we do not want to deadlock on the mm
semaphore, we want to get back to the fault handler and it should
report an oops.

.. and one of the "wild pointers" might in fact be the instruction
pointer, in case we've branched through a NULL function pointer or
similar. IOW, the exception *source* might be the instruction pointer
itself.

So I realy think that MIPS needs to have some kind of "safe kernel
exception pointer" helper. One that is guaranteed not to fault when
evaluating the exception pointer.

Assuming the kernel itself is never built with MIPS16e instructions,
maybe that's a safe assumption thanks to the "get_isa16_mode()" check
of EPC. But all of this makes me nervous.

              Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ