Subject: port-i386/412: possible to crash system by setting V86 mode.
To: None <gnats-admin>
From: Bill Sommerfeld <sommerfeld@orchard.medford.ma.us>
List: netbsd-bugs
Date: 08/12/1994 21:05:06
>Number:         412
>Category:       port-i386
>Synopsis:       can crash system by setting V86 mode.
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Aug 12 21:05:04 1994
>Originator:     Bill Sommerfeld
>Organization:
		none.
>Release:        1.0BETA
>Environment:
	
System: NetBSD orchard.medford.ma.us 1.0_BETA NetBSD 1.0_BETA (ORCHARD) #10: Fri Aug 12 20:56:51 EDT 1994 sommerfeld@orchard.medford.ma.us:/u1/nsys/sys/arch/i386/compile/ORCHARD i386


>Description:
	A user process can set Virtual '86 mode in a signal handler
	(by bashing the PSL_VM into scp->sc_efl) and returning from the 
	signal handler.

	Subsequent code executed in V86 mode can then clobber CS to
	a value such that ISPL(cs) != SEL_UPL.
	(defined in <machine/segments.h>)

	If the code then does something to prompt an interrupt or
	syscall, you probably panic because the kernel thinks the trap in
	question came from the kernel rather than user space.

	This was discovered (the hard way) by experimentation with
	setting V86 mode using sigreturn..

	This is marked serious/high because an unpriviledged user
	process can take down the system.
>How-To-Repeat:
>Fix:
	Easy:
	Prevent user space from setting PSL_VM in sc_efl (add
	it to PSL_USRCLR in psl.h) 

	Better:
	Correct the code in trap() and syscall() (and elsewhere in the
	system?) which assumes we're never operating in VM86 mode.
>Audit-Trail:
>Unformatted:


------------------------------------------------------------------------------