linux-kernel - Did the kernel cause this weird bash coredump?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <9d95d80e0805291345t6123fe83sde5f1e1a85f9ec43@mail.gmail.com>
Date:	Thu, 29 May 2008 16:45:20 -0400
From:	"Carlo Nyto" <carlonyto@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Did the kernel cause this weird bash coredump?

I got a weird coredump from bash on a system running 2.6.25.3. Stack
trace is below.

Someone was tail -f'ing a log file that was being written to at a very
high rate, and hit ctrl-c many times until the flood stopped (not tens
of thousands of times however).

This resulted in their login bash shell coredumping, when the stack
filled up due to some kind of signal (or handler) misbehavior.
Obviously this could be a bug in bash. But out of hundreds of
identical 64-bit CentOS 4.4 systems running Redhat's 2.6.9-67 kernel,
none have ever exhibited this behavior.

Is it plausible that this could be caused by a kernel bug, or a change
in signal behavior that could be surprising to bash or other
applications?

# rpm -q bash
bash-3.0-19.3.x86_64
# uname -r
2.6.25.3

Core was generated by `-bash'.
Program terminated with signal 11, Segmentation fault.
[...]
#0  0x0000003fd4a76200 in mbrtowc
    () from /lib64/tls/libc.so.6
(gdb) bt
#0  0x0000003fd4a76200 in mbrtowc () from /lib64/tls/libc.so.6
#1  0x0000000000473888 in rl_redisplay ()
#2  0x0000000000471968 in rl_clear_message ()
#3  0x0000000000474505 in rl_free_line_state ()
#4  0x00000000004745c1 in rl_free_line_state ()
#5  <signal handler called>
#6  0x0000003fd4a2e743 in sigprocmask () from /lib64/tls/libc.so.6
#7  0x0000000000474582 in rl_free_line_state ()
#8  <signal handler called>
#9  0x0000003fd4a2e743 in sigprocmask () from /lib64/tls/libc.so.6
#10 0x0000000000474582 in rl_free_line_state ()
#11 <signal handler called>
#12 0x0000003fd4a2e743 in sigprocmask () from /lib64/tls/libc.so.6
#13 0x0000000000474582 in rl_free_line_state ()
[...repeat many times...]
#33417 0x0000003fd4a2e743 in sigprocmask () from /lib64/tls/libc.so.6
#33418 0x0000000000474582 in rl_free_line_state ()
#33419 <signal handler called>
#33420 0x0000003fd4a2e743 in sigprocmask () from /lib64/tls/libc.so.6
#33421 0x0000000000474582 in rl_free_line_state ()
#33422 <signal handler called>
#33423 0x0000003fd4a2e5ed in sigaction () from /lib64/tls/libc.so.6
#33424 0x000000000047417d in _rl_current_display_line ()
#33425 0x000000000047421c in _rl_current_display_line ()
#33426 0x00000000004742dc in rl_set_signals ()
#33427 0x0000000000466e75 in readline ()
#33428 0x000000000041a3ea in yy_input_name ()
#33429 0x000000000041c1c5 in execute_prompt_command ()
#33430 0x000000000041d291 in execute_prompt_command ()
#33431 0x000000000041fd0d in yyparse ()
#33432 0x0000000000419e42 in parse_command ()
#33433 0x0000000000419ee8 in read_command ()
#33434 0x000000000041a05d in reader_loop ()
#33435 0x00000000004192a0 in main ()


Also seen in syslog:
kernel: bash[9443]: segfault at 7ffff65ddff8 ip 3fd4a76200 sp
7ffff65ddfe0 error 6 in libc-2.3.4.so[3fd4a00000+12b000]
kernel: bash used greatest stack depth: 3096 bytes left
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/