A regular user can lock up a system by executing ksu(suid root) with an argv[0] replaced with alot of data. I tried it with 100k and you can see in the example below what happened. (FYI ksu as in the kerberos su, to avoid any confusion) For example: (for the example I will abbreviate the 100000 A's in the output as <CHUNK>) bash-2.04$ doexec ksu `perl -e'print "A" x 100000;'` WARNING: Your password may be exposed if you enter it here and are logged in remotely using an unsecure (non-encrypted) channel. Kerberos password for root: <hit Ctrl-C> <CHUNK>: Password read interrupted while reading password for 'root' Authentication failed. <CHUNK>[1124]: '<CHUNK> root' authentication failed for www on /dev/pts/2 <system is now locked up completely> Nothing can be done. The system is completely locked up after about 10-15 seconds and after that period of time the system will not respond to anything. I've been trying to track it down and I think this is where it is freezing as far as program execution goes: main.c: if (auth_val ==FALSE){ fprintf(stderr, "Authentication failed.\n"); syslog(LOG_WARNING, "'%s %s' authentication failed for %s%s", prog_name,target_user,source_user,ontty()); sweep_up(ksu_context, use_source_cache, cc_target); exit(1); } Since fprintf and syslog are being executed and exit(1) never seems to happen the problem must be somewhere in sweep_up function, unless syslog never exits which is unlikely. The part of the sweep_up function below is as far as I can guess is triggering the problem, though I'm not sure where exactly. The thing that stands out to me is the fact the com_err never gets displayed. main.c: if (! use_source_cache){ cc_name = krb5_cc_get_name(context, cc); if ( ! stat(cc_name, &st_temp)){ if ((retval = krb5_cc_destroy(context, cc))){ com_err(prog_name, retval, "while destroying cache"); } } } } This was done using latest kerberos packages from rawhide and 2.3.99-pre5 kernel. -Stan Bubrouski
I was just looking at my logs and there is no log of when this occured, nothing was logged when it happened...not even ksu's syslog call got logged even thought it was displayed which may suggest the problem is triggered in syslog, however I still think it is a kernel problem.
Ok the redhat version of kerberos 5 isn't the only one to trigger this, as I downloaded beta's for kerberos 1.2 beta 1 and tried it again using ksu and got this: kmalloc: Size (140084) too large kmalloc: Size (140084) too large kmalloc: Size (140084) too large ...continues FOREVER!!! no keybaord intervention like ctrl-c or z or anything would interrupt it and console switching is not functional either, the only thing that can be done (AND THANK GOD) is using Sys Rq key combos to sync drives, unmount em, and reboot. Is this a kernel problem? -Stan Bubrouski
Yes its a kernel issue but report it to linux-kernel.edu as its a mainstream kernel issue not a Red Hat one