Date: Fri, 27 Oct 95 04:16 CDT From: gordon@sneaky.lerctr.org To: FreeBSD-gnats-submit@freebsd.org Subject: kern/795: sysctl lets ordinary users lock up system Message-ID: <m0t8ktz-0000FzC@hammy.lerctr.org> Resent-Message-ID: <199510280150.SAA04103@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 795
>Category: kern
>Synopsis: sysctl lets ordinary users lock up system
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Oct 27 18:50:00 PDT 1995
>Last-Modified:
>Originator: Gordon Burditt
>Organization:
>Release: FreeBSD 2.0-BUILT-19950603 i386
>Environment:
FreeBSD 2.0.5R
syscons console driver
486DX/33 CPU
>Description:
Attempting to retrieve the sysctl() information from
kern.vnode locks up the system some of the time.
The lock is probably on the vnode table (ps won't run), and
you cannot log in on another terminal/virtual console,
execute ps on any terminal/virtual console already logged
in, ^C or ^Z out of the program, or much of anything else.
Some UUCP conversations continue, but they may not last past
the point of needing to switch files.
>How-To-Repeat:
Run the following program several times as an unprivileged user.
I always had it lock up the system within 3 tries, usually 1 or 2.
If it makes a difference, I always ran it from a syscons virtual
console. When it's locked up, you cannot interrupt the program
with ^C or ^Z, you cannot log in on another virtual terminal or
serial port (You never get the password: prompt), ps never
finishes, and to get anything useful done, you have to reboot.
Don't run this program unless you are prepared to reboot.
/* sysctlcrash.c */
# include <stdio.h>
# include <errno.h>
# include <sys/param.h>
# include <sys/sysctl.h>
int main(int argc, char **argv)
{
int ret;
int mib[6];
int len;
char buffer[8192];
mib[0] = CTL_KERN;
mib[1] = KERN_VNODE;
len = 8192;
ret = sysctl(mib, 2, buffer, &len, NULL, 0);
exit(0);
}
>Fix:
This code section was derived from a piece of code intended
to treewalk the MIB, uh, "filesystem", and find all the stuff
sysctl -A misses, so I set it up to avoid this particular combination,
but I don't have a fix. I also find it interesting that both EISDIR
and ENOTDIR indicate that the name I have chosen is not terminal and
I should lengthen it.
Gordon L. Burditt
sneaky.lerctr.org!gordon
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0t8ktz-0000FzC>