crash possible by confusing interface

Damon Permezel dap at teklds.UUCP
Fri Nov 9 09:53:19 AEST 1984


Index:	/usr/src/etc/ifconfig.c 4.2BSD

Description:
	If , at boot time, one does a "ifconfig il1 host up ...." and "host"
	is not found in /etc/hosts, the ioctl(SIOCSIFADDR) results in ilinit()
	being called with a zero address. Ilinit() just returns, without
	allocating any unibus resources.
	Next, the ioctl(SIOCIFFLAGS) marks the interface as up.  This
	means that routes can be allocated through this interface. This
	means that packets can be sent out on the interface.
	The first time a packet tries to make it out, ilstart() calls
	if_wubaput(), which seems to assume that since the interface is up,
	it has some unibus resources.  Unfortunately, the trap code
	is unable to handle the ensuing protection fault.

Repeat-By:
	Get yourself an interlan board
	(should work for other network devices also)
	and gen a kernel appropriately.  Add the line

	/etc/ifconfig il0 KGBvax up

	to /etc/rc, and remove the entry for KGBvax from /etc/hosts.
	Add some entries to the gateways file to cause routes to
	allocated through the il0 interface.
	Reboot, and try to rlogin to a host reachable through that
	network interface.

Fix:
	Well, as far as I can tell, IFF_RUNNING implies that the interface
	has allocated all the neccessary resources.
	So the easiest thing to do is change ifconfig so that it
	will not mark an interface up unless IFF_RUNNING is set also.

	Whatever you do, you should probably remove the 'up' options to
	ifconfig in /etc/rc.  Most interfaces that I have looked at set
	themsleves to be up if they initialise properly, so the 'up' in /etc/rc
	is dangerous.
	Check your interface driver code first, though. Some don't set IFF_UP.

	To change ifconfig, in the setifflags() routine, where it says
		} else
			ifr.ifr_flags |= value;
	change it to
		} else
			ifr.ifr_flags |= value & ~(ifr.ifr_flags&IFF_RUNNING ?
							0 : IFF_UP);

	I just looked at a few of the interface drivers.
	They seem really confused about the meanings of the flags.
	If you have a css (imp?), it uses neither, just ui_alive.
	Once you mark that sucker down, you can't mark it up again.

	Other drivers use both IFF_RUNNING and IFF_UP.  Some set
	RUNNING when they allocate resources successfully, but fail
	to make sure that it is not set when going through their interface
	init routine at other times.  A quick look at the code seems to indicate
	that rmalloc() will be called for each time an ioctl(SIOCSIFADDR)
	is done on the interface, and one will eventually run out of
	unibus resources.

	Some of these interface drivers also, if they are denied unibus
	resources, just set the interface flags to flags &= ~IFF_UP.
	They should set them to flags &= ~(IFF_UP|IFF_RUNNING), so
	that the fix mentioned above can prevent system crashes.

	All the interface drivers (except il and hy) in vaxif need to have
	these slight changes made. Then they will treat these flags
	consistantly, and this consistant usage can be used by
	ifconfig to prevent premature system death.

	As far as the fix to ifconfig goes, it would be preferable to
	have this done in the kernel.  Those mods are left as an excercise
	for the reader.



More information about the Comp.bugs.4bsd.ucb-fixes mailing list