Bug 84344 - sigpip handler drops siginfo and ucontext (causes java 1.4.x ssl to fail)
sigpip handler drops siginfo and ucontext (causes java 1.4.x ssl to fail)
Status: CLOSED CANTFIX
Product: Red Hat Linux
Classification: Retired
Component: nss_ldap (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-14 13:12 EST by Need Real Name
Modified: 2015-01-07 19:03 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-18 10:31:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2003-02-14 13:12:34 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2)
Gecko/20021120 Netscape/7.01

Description of problem:
During testing of a homegrown VNC ssl enabled proxy - we determined that a java
application handling ssl network communication would die when portscanned. 

We submitted our bug-reports against 1.4.x to Sun for analysis.

Included below is their analysis of the problem, which points to a problem in
nss_ldap (in source versions < 200) with how it handles the SIGPIPE handler.  

------------from sun below--------------

Subject:	Re: (Review ID: 179108) JVM crashes
(JVM_handle_linux_signal+0x93) 		) 	 				OutputStream



Hello

Thank you for reporting this issue.

This bug is being tracked under the following Bug-ID: 4630104
Synopsis: REGRESSION: JVM crash on unexpected EOF/SIGPIPE

The problem is in libnss_ldap.so.

_nss_ldap_enter tries to block SIGPIPE by changing the SIGPIPE handler to
SIG_IGN, and in _nss_ldap_leave, the original signal handler (in this case,
the JVM signalHandler) is restored by using sigset() or signal().

We set up our SIGPIPE handler first by sigaction() and with the SA_SIGINFO
flag set, so we get both siginfo and ucontext in the signal handler; but
sigset() and/or signal() used by nss_ldap can only restore signal
handlers without siginfo/ucontext.

As the result, when a SIGPIPE is delivered after nss_ldap has changed and
"restored" the SIGPIPE handler, our signal handler is invoked with only
one argument (i.e. signal number), but we expect three arguments (signal
number, siginfo and ucontext). We will crash when we try to figure out
the PC from ucontext (JVM_handle_linux_signal+0x93 is
"pc = (address) uc->uc_mcontext.gregs[REG_EIP];"). nss_ldap should use
sigaction() to change and restore signal handlers.

libjsig.so is designed to work around this type of problems. libjsig.so
works by interposing signal(), sigset() and sigaction() functions to
make sure JVM can still function correctly when any of the functions
is used to change a signal that is also being used by JVM.

Note from the ChangeLog, nss_ldap from version 200 started to use
sigprocmask() to block SIGPIPE. This should fix the problem.

If you don't have the latest nss_ldap (Redhat 8.1 beta has nss_ldap-202,
therefore does not have this problem), you can preload libjsig.so to work
around the problem.


 Best Regards-
 Tim Bell    tim.bell@sun.com         Core Java Engineering
  Sun Microsystems Java Software

    "JavaSoft(TM), Java(TM), and Java(TM) Development Kit
    are all trademarks of Sun Microsystems, Inc."
    "JavaSoft(TM), Java(TM), et Java(TM) Development Kit
    sont des marques d?pos?es ou enregistr?es de Sun
    Microsystems, Inc. aux Etats-Unis et dans d'autres pays."

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Run a java program accepting SSL connections w/ 1.4.x on RH 7.3
2. Use nmap/tool of choice to portscan the listening port
3. Watch the program die immediate death
    

Actual Results:  Process dies

Expected Results:  No effect

Additional info:

original debugging information sent to sun is available upon request.

I could not post hit here - do to length
Comment 1 Need Real Name 2003-02-14 13:37:29 EST
Upon a second search of existing bugs, bug 14656 might be caused by a bug 
similar to this.   

Comment 2 Bill Nottingham 2006-08-04 23:49:29 EDT
Red Hat apologizes that these issues have not been resolved yet. We do want to
make sure that no important bugs slip through the cracks.

Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc.
They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/)
for security updates only. If this is a security issue, please reassign to the
'Fedora Legacy' product in bugzilla. Please note that Legacy security update
support for these products will stop on December 31st, 2006.

If this is not a security issue, please check if this issue is still present
in a current Fedora Core release. If so, please change the product and version
to match, and check the box indicating that the requested information has been
provided.

If you are currently still running Red Hat Linux 7.3 or 9, please note that
Fedora Legacy security update support for these products will stop on December
31st, 2006. You are strongly advised to upgrade to a current Fedora Core release
or Red Hat Enterprise Linux or comparable. Some information on which option may
be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/.

Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be
closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a
security issue, please change the product as necessary. We thank you for your
help, and apologize again that we haven't handled these issues to this point.
Comment 3 Bill Nottingham 2006-10-18 10:31:55 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Closing as CANTFIX.

Note You need to log in before you can comment on or make changes to this bug.