It seems that the login_audit.c doesn't check that pwd is non-NULL before dereferencing it. Below is a patch with a possible solution. How-To-Repeat: At the console, press Enter a few times, or run login(1) from a shell. If you do not successfuly login, the application exits and syslog notes something like: Oct 1 10:08:51 thinkpad kernel: pid 62854 (login), uid 0: exited on signal 11
Responsible Changed From-To: freebsd-bugs->csjp Christian did the MFC so he eats all the bugs now. :-) The fix proposed in the PR should be replaced by simply MFCing rev. 1.101 to login.c: : date: 2006/03/28 15:30:42; author: cognet; state: Exp; lines: +5 -2 : Don't call audit_logout() if pwd is NULL, as audit_logout() attempts to : dereference it. : This will happen if we ^D at the Login: prompt without having provided a : valid login before. : Set pwd to NULL on bad login attempts to prevent audit_logout() from being : called for a user which didn't actually log on. : : Reported by: Jerome Magnin jethro at docisland dot org
delphij 2006-10-06 14:58:17 UTC FreeBSD src repository Modified files: (Branch: RELENG_6) usr.bin/login login.c Log: MFC revision 1.101 (cognet@): A temporary fix that in case of pwd == NULL, do not call audit_logout() which attempts to deference it. This is not quite correct, as we should audit the event even it is not attributable to a specific user. For now, just put the temporary fix in, so login(1) would not get signal 11 upon the case that for instance, ^D at the Login: prompt without providing a valid login before.i Approved by: re (rwatson) PR: bin/103873 Discussed with: rwatson, csjp Revision Changes Path 1.99.2.2 +4 -1 src/usr.bin/login/login.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
State Changed From-To: open->analyzed To follow up with the current situation: a MFC is done as a "stop gap" in order to make sure that login(1) does not crash on unsuccessful logins, but proper audit mechanism has to be added in order to provide correct audit information. I think this PR can be closed as the problem described in the report has been "fix"ed. However, bump the state to analyzed for now, so we get a reminder to really fix the underlying issue.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.