Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site nyit.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!linus!philabs!nyit!rick
From: rick@nyit.UUCP (Rick Ace)
Newsgroups: net.bugs.4bsd
Subject: VAX 4.2bsd /dev/kmem panic
Message-ID: <222@nyit.UUCP>
Date: Thu, 13-Mar-86 18:54:26 EST
Article-I.D.: nyit.222
Posted: Thu Mar 13 18:54:26 1986
Date-Received: Sat, 15-Mar-86 20:50:58 EST
Distribution: net
Organization: NYIT Computer Graphics Lab., Old Westbury, N.Y.
Lines: 43

[]
Description:
	It's rather easy for anyone with read access to /dev/kmem to
	crash a 4.2bsd VAX with a trap-9 (protection fault) panic.

	Apparently, kernacc() (in vax/locore.s) gets confused when
	called to verify access to a region of memory that straddles
	P1 and S0 space, ultimately making a wild reference.

	Even well-intentioned utilities such as "ps" and "uptime" can
	conceivably trip over this bug because they are taking
	snapshots of data that is changing out from underneath them.

Repeat-By:
	char buf[168];
	main()
	{
		int fd;

		fd = open("/dev/kmem", 0);
		if (fd < 0) {
			perror("/dev/kmem");
			exit(1);
		}
		lseek(fd, 0x7fffffff, 0); /* begin near the end of P1 space */
		read(fd, buf, sizeof buf); /* crosses from P1 into S0 space */
	}

Fix:
	One possible fix to kernacc() would check for a region
	that began in one quadrant of virtual memory and ended
	in a different quadrant.  If so, the existing kernacc
	logic could be invoked twice, to verify each quadrant's
	portion independently.  I haven't tried this yet.

-----
Rick Ace
Computer Graphics Laboratory
New York Institute of Technology
Old Westbury, NY  11568
(516) 686-7644

{decvax,seismo}!philabs!nyit!rick