[Bug 1397250] Re: SIGPIPE not caught in do_atfork_child()

Jon Grimm jon.grimm at canonical.com
Mon Oct 24 17:12:40 UTC 2016


** Description changed:

- Ubuntu version: Ubuntu 14.04.1 LTS
- Package version: libnss-ldap_264-2.2ubuntu4
+ [Impact]
  
- If a process using libnss-ldap calls fork() and SIGPIPE was blocked, the atfork() handler in the child process failed to catch the SIGPIPE as it was supposed to do, that is in the call to  do_close_no_unbind().  So that, the uncaught SIGPIPE will be eventually
- delivered when the child unblocks signals. This usually make the child process die unexpectedly.
+  * If a process using libnss-ldap calls fork() and SIGPIPE was blocked, 
+    the atfork() handler in the child process failed to catch the SIGPIPE 
+    as it was supposed to do, that is in the call to  do_close_no_unbind().
+    So that, the uncaught SIGPIPE will be eventually delivered when the
+    child unblocks signals. This usually make the child process die
+    unexpectedly.
  
- I found a well-known Linux vendor fixed this issue with the following
- patch. This unblocks the SIGPIPE before calling do_close_no_unbind() and
- restores the original sigmask afterwards:
+  * This is only reproducible when ldap is configured for STARTTLS.
  
- diff -up nss_ldap/ldap-nss.c nss_ldap/ldap-nss.c
- --- nss_ldap/ldap-nss.c 2009-12-07 20:57:33.000000000 -0500
- +++ nss_ldap/ldap-nss.c 2009-12-07 20:58:56.000000000 -0500
- @@ -532,8 +532,13 @@
-  static void
-  do_atfork_child (void)
-  {
- +  sigset_t unblock, mask;
-    debug ("==> do_atfork_child");
- +  sigemptyset(&unblock);
- +  sigaddset(&unblock, SIGPIPE);
- +  sigprocmask(SIG_UNBLOCK, &unblock, &mask);
-    do_close_no_unbind ();
- +  sigprocmask(SIG_SETMASK, &mask, NULL);
-    _nss_ldap_leave ();
-    debug ("<== do_atfork_child");
-  }
+  * Upstream fix has been long integrated.
  
- I'd like to see this patch applied.
+ [Test Case]
+ 
+  * See https://bugs.launchpad.net/ubuntu/trusty/+source/libnss-
+ ldap/+bug/1397250/comments/19
+ 
+ 
+ [Regression Potential] 
+ 
+  * Fix has been upstream since 2010, and limited to path of child
+    forking, and SIGPIPE is blocked. No consequent bugs or regressions
+    in the upstream blamed on this change.  
+ 
+ 
+ [Other Info]
+  
+  * I'm currently limiting my SRU to trusty, as I'm unable to 
+    recreate the bug on xenial.  Even so, I have tested the fixed 
+    code on xenial to ensure there was no regression with the testcase.
+ 
+  * Will look at fixing xenial too, IFF someone comes forward able to
+    reproduce the bug/validate the fix.

** Changed in: libnss-ldap (Ubuntu Trusty)
       Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1397250

Title:
  SIGPIPE not caught in do_atfork_child()

Status in nss_ldap:
  Fix Released
Status in libnss-ldap package in Ubuntu:
  Fix Released
Status in libnss-ldap source package in Trusty:
  In Progress
Status in libnss-ldap source package in Xenial:
  Won't Fix
Status in libnss-ldap source package in Yakkety:
  Won't Fix

Bug description:
  [Impact]

   * If a process using libnss-ldap calls fork() and SIGPIPE was blocked, 
     the atfork() handler in the child process failed to catch the SIGPIPE 
     as it was supposed to do, that is in the call to  do_close_no_unbind().
     So that, the uncaught SIGPIPE will be eventually delivered when the
     child unblocks signals. This usually make the child process die
     unexpectedly.

   * This is only reproducible when ldap is configured for STARTTLS.

   * Upstream fix has been long integrated.

  [Test Case]

   * See https://bugs.launchpad.net/ubuntu/trusty/+source/libnss-
  ldap/+bug/1397250/comments/19

  
  [Regression Potential] 

   * Fix has been upstream since 2010, and limited to path of child
     forking, and SIGPIPE is blocked. No consequent bugs or regressions
     in the upstream blamed on this change.  

  
  [Other Info]
   
   * I'm currently limiting my SRU to trusty, as I'm unable to 
     recreate the bug on xenial.  Even so, I have tested the fixed 
     code on xenial to ensure there was no regression with the testcase.

   * Will look at fixing xenial too, IFF someone comes forward able to
     reproduce the bug/validate the fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nss-ldap/+bug/1397250/+subscriptions



More information about the Ubuntu-sponsors mailing list