Bugzilla – Bug 65372
VUL-0: CVE-2005-0178: kernel: tty/setsid race
Last modified: 2021-10-27 11:51:49 UTC
20050110 tty/setsid race Alan Cox committed a patch to 2.6 to "Use the existing "tty_sem" to protect against the process tty changes too.", this was included in 2.6.10-ac4. Patch available at: +http://linux.bkbits.net:8080/linux-2.6/cset@41ddda70CWJb5nNL71T4MOlG2sMG8A CAN-2005-0178
<!-- SBZ_reproduce --> n/a
Created attachment 28091 [details] setsid-tty-locking
Pavel, can you please review this patch to see whether it breaks anything, and if this is indeed what is in mainline ATM? If the patch is good, please commit it to all kernel branches for the next security update. That would be kernel-source-26: SLES9_SP1, SLES9_SP2, SL92, HEAD kernel-source: SLEC8, SL82, HEAD The vulnerability this is supposed to fix is CAN-2005-0178; see http://cve.mitre.org.
Security problem with priority=Minor... "Interesting". I'm by no means tty expert (and I fear that my try to commit to 7 different branches would result with at least 5 of them broken).
I did a small investigation, and it seems to be the same solution as in current linus's bk.
I'm sorry, I will not be able to do this one. I'm on quite a slow link, and for some strange reason, getting SLES9_SP2_BRANCH\ takes >4hours (it is not yet done). It is not even saturating GPRS link. Just \getting those 6 repositories (I already have HEAD) would take few days :-(. [I did cp -a of HEAD, then update -r SLES9_SP2_BRANCH. Perhaps I should have do\ne update from empty tree?]
back to okir to find some other developer...
Not so quick, please :) I think Pavel is working on improving his connectivity right now. Correct me if I'm wrong.
Handing over to Karsten who was just volunteered.
Created attachment 34500 [details] correct patch The patch was incomplete, for sys.c the tty.h was missing.
Hmm, do you really want to back it to SLES9, this will be a major change, in SLES9 kernel no tty_sem exist, so we have to backport the complete tty stuff, not only this extention of using the semaphore. I didn't look at 2.4 based kernel yet, but I think that these need a big backport too. For 9.2 the patches are ready now, but need some testing, mbuilds are done.
i would appreciate an evaluation by you on how critical security or bugwise this is for our customers. if this is just a rare race condition and/or not exploitable secuzrity wise i have now problems to leave this as a "fix in stable" problem
I simple do not know enough about the tty stuff to do such a evaluation, this is also my issue to fix it for the old releases, tty code is spread all over the kernel, not only in driver/char/tty, so it is difficult to find a correct patchset without breaking something. I still evaluate the changes in the tty stuff from SLES9 -->9.3 and try to isolate a patch. I also do not have any idea, how security relevant this is.
OK, it seems that a backport for SLES9 is not too intrusive. I already have a patch, but it would be the best if someone else can review it.
Created attachment 34570 [details] patch for SLES9 SP1
I have tested the patch with SP2 beta1 and see no problems related to tty, I also have a backport for 2.4 ready. But I still do not understand enough about tty to make real tests, e.g. test the securety issue or stress test the locking, I only test if I can still login and logout. So anybody else should decide how we are going further.
Seems we got stuck again. What does this patch protect against? What kind of nasty thing is possible if this patch is missing?
This is my problem too, I have no idea how to test the patches and I also do not know, how to trigger the problem which should be fixed by this stuff. The URL from comment #3 was also not helpful in this matter (or I'm to stupid to find the correct place).
since we are not comfortable with this fix and it has only minor implications (if any at all) I think we can have this fixed via upstream in later kernel versions. So my decision: fixed in STABLE.
CVE-2005-0178: CVSS v2 Base Score: 6.2 (AV:L/AC:H/Au:N/C:C/I:C/A:C)