Hello, Has anyone seen a crash triggered by an incoming telnet connection? It seems that that's what we are experiencing on a certain system. It happens randomly, hard to reproduce. Attached is the crash screen shot. Thanks, Dirce
drichards@globalcerts.net wrote:
Hello, Has anyone seen a crash triggered by an incoming telnet connection? It seems that that's what we are experiencing on a certain system. It happens randomly, hard to reproduce. Attached is the crash screen shot.
Sorry, this is a text-only mailing list - attachments are deleted.
Incoming telnet connection: *why* is there an incoming telnet connection? The only thing I know anyone using telnet for *anywhere* in the last six or eight years is to check a mail or other port, to see if it responds. It should NOT BE USED for anything anymore. If you've got users using it, break them of that habit, yesterday, because you are incredibly vulnerable to anyone who cares. Move them to ssh.
mark
Thanks for the comment. It was not a user, but a monitoring tool that was using telnet. We will be re-writing that tool. Dirce
drichards@globalcerts.net wrote:
Hello, Has anyone seen a crash triggered by an incoming telnet connection? It seems that that's what we are experiencing on a certain system. It happens randomly, hard to reproduce. Attached is the crash screen shot.
Sorry, this is a text-only mailing list - attachments are deleted.
Incoming telnet connection: *why* is there an incoming telnet connection? The only thing I know anyone using telnet for *anywhere* in the last six or eight years is to check a mail or other port, to see if it responds. It should NOT BE USED for anything anymore. If you've got users using it, break them of that habit, yesterday, because you are incredibly vulnerable to anyone who cares. Move them to ssh.
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
drichards@globalcerts.net wrote:
drichards@globalcerts.net wrote:
Has anyone seen a crash triggered by an incoming telnet connection? It seems that that's what we are experiencing on a certain system. It happens randomly, hard to reproduce. Attached is the crash screen shot.
Sorry, this is a text-only mailing list - attachments are deleted.
Incoming telnet connection: *why* is there an incoming telnet connection? The only thing I know anyone using telnet for *anywhere* in the last six or eight years is to check a mail or other port, to see if it responds. It should NOT BE USED for anything anymore. If you've got users using it, break them of that habit, yesterday, because you are incredibly vulnerable to anyone who cares. Move them to ssh.
Thanks for the comment. It was not a user, but a monitoring tool that was using telnet. We will be re-writing that tool.
Ok... then I'd suggest watching with tcpdump, or strace, on the receiving box, to watch what it's doing, and manually run it, and see if you can get any clues.
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Actually I just looked at the tool, and all it was doing was using telnet to check if a couple daemons were up. And the crash happens only in one out of hundreds of these calls, so it's hard to reproduce.
Since I have the screen shot, how/where can I report this as a known problem? I looked at the bug fixes, but couldn't tell if this has been fixed on 6.4 (-248 version).
Thanks,
Dirce
drichards@globalcerts.net wrote:
drichards@globalcerts.net wrote:
Has anyone seen a crash triggered by an incoming telnet connection? It seems that that's what we are experiencing on a certain system. It happens randomly, hard to reproduce. Attached is the crash screen shot.
Sorry, this is a text-only mailing list - attachments are deleted.
Incoming telnet connection: *why* is there an incoming telnet connection? The only thing I know anyone using telnet for *anywhere* in the last six or eight years is to check a mail or other port, to see if it responds. It should NOT BE USED for anything anymore. If you've got users using it, break them of that habit, yesterday, because you are incredibly vulnerable to anyone who cares. Move them to ssh.
Thanks for the comment. It was not a user, but a monitoring tool that was using telnet. We will be re-writing that tool.
Ok... then I'd suggest watching with tcpdump, or strace, on the receiving box, to watch what it's doing, and manually run it, and see if you can get any clues.
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 06/14/2013 04:57 PM, drichards@globalcerts.net wrote:
Since I have the screen shot, how/where can I report this as a known problem? I looked at the bug fixes, but couldn't tell if this has been fixed on 6.4 (-248 version).
If you reply to my email with the details requested, we can try to start figuring out where your setup is broken and how.
Hi,
My colleague found this:
Red Hat BZ#765665
A possible race between the n_tty_read() and reset_buffer_flags() functions could result in a NULL pointer dereference in the n_tty_read() function under certain circumstances. As a consequence, a kernel panic could have been triggered when interrupting a current task on a serial console. This update modifies the tty driver to use a spin lock to prevent functions from a parallel access to variables. A NULL pointer dereference causing a kernel panic can no longer occur in this scenario. (231 kernel)
On 06/14/2013 04:57 PM, drichards@globalcerts.net wrote:
Since I have the screen shot, how/where can I report this as a known problem? I looked at the bug fixes, but couldn't tell if this has been fixed on 6.4 (-248 version).
If you reply to my email with the details requested, we can try to start figuring out where your setup is broken and how.
The processes in use are: httpd, MySQL, and sendmail, which are used by our SecureMail Gateway application. The crash seems to be triggered by a 'telnet localhost ' command checking if ports 443 and 25 are up. The screen at the crash included the words 'telnet' and 'n_tty_read() ' If you send me another email where I can send the image of the screen shot, I can send it to you.
Thanks, Dirce
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 06/14/2013 01:48 PM, drichards@globalcerts.net wrote:
Hello, Has anyone seen a crash triggered by an incoming telnet connection? It seems that that's what we are experiencing on a certain system. It happens randomly, hard to reproduce. Attached is the crash screen shot.
Can you post some info on what server, client, network setup, firewall setup and any MAC policies you might have on there ?
there are some pretty straight forward sock.connect style tests in the functional test suite, so at a base layer it should just work
-
drichards＠globalcerts.net -
Karanbir Singh -
m.roth＠5-cent.us