ghb@locus.com (George Bray) (03/10/90)
Well, I've found another one. (This is after installing the quickie
patch you sent). In fact, this may even be the same race condition,
but it has a very different stack trace, so I'm bugging the world
about it again. As a reminder, this is 7.0.4 (plus change to mail.c)
running under 4.3Tahoe on a Vax.
This time I got a longjmp botch repeatably while reading a
particular mail message. It turned out that the mail message had an
escape sequence in it. I reproduce below the line that caused all the
trouble, except that I've turned the escape into the two characters
'^[' and the backspaces into '^H'.
-- The offending line --
you gave to ^[4~Bryan Freed woi^H^Hork now?).
-- End offending line --
The failure only occurred on my Wyse 60 terminal. The ESC 4 sequence
is 'send unprotected cursor line' which I assume means send the entire
line containing the cursor as input.
When I displayed the message containing this (using the internal
pager), it would eventually die with a longjmp botch. The stack trace
follows:
_longjmp(14) from 17875
_curses_command(0) from 139bf
_do_loop() from 97e
_main(2,40cb0,7fffe8f8) from start+3d
I said above that it would "eventually" die because sometimes the
message would be repeatedly displayed. In other words, it would
display to the point line containing the escape sequence, the line
would become garbage on the screen, mush would display the
"continue" prompt and then re-display the message. I'm fairly certain
that the re-display was caused by the line being sent by the terminal
and ending in a CR, which I have bound to display the current message
in curses mode.
It was fairly entertaining watching mush bang itself over the head
with this message until it finally croaked.
Any ideas? Is this the same race, made worse by machine-speed input?
Thanks,
--
George Bray
Locus Computing Corporation, 9800 La Cienega Blvd, Inglewood, CA 90301-4440
213-337-5171
lcc!ghb@seas.ucla.edu {uunet,ucla-se,elroy!turnkey}!lcc!ghbschaefer@ogicse.ogi.edu (Barton E. Schaefer) (03/11/90)
In article <255@elrond.locus.com> ghb@elrond.locus.com (George Bray) writes: } Well, I've found another one. (This is after installing the quickie } patch you sent). In fact, this may even be the same race condition, } but it has a very different stack trace, so I'm bugging the world } about it again. As a reminder, this is 7.0.4 (plus change to mail.c) } running under 4.3Tahoe on a Vax. It's not the same race condition. } This time I got a longjmp botch repeatably while reading a } particular mail message. It turned out that the mail message had an } escape sequence in it. [....] } The failure only occurred on my Wyse 60 terminal. The ESC 4 sequence } is 'send unprotected cursor line' which I assume means send the entire } line containing the cursor as input. You should definitely disable this "feature" of your terminal as soon as possible. This is a truly classic security hole; what if the line containing the ESC-4 had contained somewhere the string "!rm -f *" ... } When I displayed the message containing this (using the internal } pager), it would eventually die with a longjmp botch. [...] } I said above that it would "eventually" die because sometimes the } message would be repeatedly displayed. [...] } It was fairly entertaining watching mush bang itself over the head } with this message until it finally croaked. Mush was not banging *itself* over the head, your *terminal* was banging it over the head. Send enough random keyboard signals at any interactive program and it will very likely get confused. Nevertheless, it is true that mush's current setjmp/longjmp usage is a little fragile, and there are some "windows" where a signal could cause the wrong jumpbuf to be used. Those "windows" are generally about as wide as the time required to make one function call (i.e., the critical section where signals are blocked ends, and then a function is called which immediately does a setjmp()). } Any ideas? Is this the same race, made worse by machine-speed input? Most likely, you managed to interrupt mush in one of the "windows" noted above, or in the middle of a setjmp(), causing it to longjmp() to either an out-of-date jumpbuf or one that was only partially filled in. I've done all I can without totally revamping the signal mechanism to keep those holes as small as possible, so the situation is not likely to get better in the immediate future. An overhaul of the signal stuff *is* being designed, but I can't guess when anyone will have time to implement such a thing. -- Bart Schaefer "EARTH: Surrender IMMEDIATELY or we PICKLE DAN QUAYLE" "THPPFT!" schaefer@cse.ogi.edu (used to be cse.ogc.edu)