Created attachment 366055 [details] Don't dereference null variable 'emacs' when starting under ssh from emacs Description of problem: If you ssh to an account that has bash 4.0 as its shell, and your TERM variable is set to 'eterm' or 'eterm-color', bash will segfault during its startup. This happens, for example, if you ssh from an emacs ansi-term (which will set your TERM to 'eterm-color'). The reason for this is that bash is trying to use strstr() on a variable that points to the value of the EMACS environment variable, without checking if it's null. Since EMACS isn't a variable that ssh allows to pass through (while TERM is), it will be null in an ssh session, and bash will crash. This appears to date back to this entry from July 10, 2008 in the CWRU/changelog: shell.c - make changes to how bash sets no_line_editing and running_under_emacs to deal with various emacs terminal emulators; use better check for `eterm', since bash sends $PWD to eterm with control sequences that confuse other programs. Problem reported by Micah Cowan <micah> Version-Release number of selected component (if applicable): 4.0-8.fc11.x86_64 (though applies to any release of 4.0, I believe) How reproducible: 100% Steps to Reproduce: 1. Start emacs on some machine. 2. M-x ansi-term 3. 'echo $TERM' to verify that it's eterm-color or eterm 4. 'ssh F11HOST' (where F11HOST is a machine with bash 4.0 installed and set as your shell) 5. Observe the connection being closed instead of receiving a prompt. (It's not actually necessary to use emacs; if you simply run the following from any machine, the same failure will happen: env TERM=eterm-color ssh F11HOST ) Additional info: The patch to correct this is a trivial one-liner. The problem exists in upstream bash, and has been confirmed to happen on Ubuntu 9.10 (Ubuntu 9.04 didn't have bash 4.0). It would be great if you could consider applying the attached patch and sending it upstream to the GNU bash maintainers.
Hi Mitchell, We thank for reporting this issue and provide a fix. So let's consider this ticket as triaged so it can be taken care by our maintainers. Just one thing: as you stated, there is no need to launch a session via SSH to trigger this crasher. [hidou@localhost ~]$ env TERM=xterm bash [hidou@localhost ~]$ exit [hidou@localhost ~]$ env TERM=eterm bash Segmentation fault [hidou@localhost ~]$ env TERM=eterm-dsfdfsdf bash Segmentation fault So I ll just change a bit the title of this ticket. Again many thanks to you, and feel free to report any bug that you may find in the future. Regards. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
It's not the case that bash will always segfault when TERM=eterm*. The segfault only occurs when EMACS is also not set to anything in the environment. If you run bash from an emacs ansi-term where TERM is set to eterm-color, everything will be fine since EMACS is set to the version of emacs that you're running. In general, you wouldn't have your TERM set to eterm* unless you were running in emacs, so the only common case where this bug would be triggered is if you were in emacs and began a shell where the TERM variable was passed along to it, but the EMACS variable was not - except in contrived testing examples, this only occurs when you ssh from an emacs ansi-term to a machine with bash 4.0, and that's why the summary of the bug was set as I originally had it. The subject "bash segfaults on startup when TERM=eterm*" is inaccurate, so I've adjusted it to clarify the requirements for triggering this bug.
Hi Mitchell, You are 100% right. Title is just perfect now ;-) Thanks again. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Thanks for report. I will apply your suggested patch. This will be also fixed in next bash release.
Changed in bash-4.0-9.fc11
bash-4.0-9.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/bash-4.0-9.fc11
bash-4.0.35-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/bash-4.0.35-2.fc12
bash-4.0-9.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
bash-4.0.35-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.