From owner-cvs-usrsbin  Sun Mar  9 12:04:01 1997
Return-Path: <owner-cvs-usrsbin>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id MAA08014
          for cvs-usrsbin-outgoing; Sun, 9 Mar 1997 12:04:01 -0800 (PST)
Received: (from ache@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id MAA07995;
          Sun, 9 Mar 1997 12:03:57 -0800 (PST)
Date: Sun, 9 Mar 1997 12:03:57 -0800 (PST)
From: "Andrey A. Chernov" <ache>
Message-Id: <199703092003.MAA07995@freefall.freebsd.org>
To: CVS-committers, cvs-all, cvs-usrsbin
Subject: cvs commit:  src/usr.sbin/ppp Makefile chat.c main.c timer.c sig.c sig.h
Sender: owner-cvs-usrsbin@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

ache        97/03/09 12:03:56

  Modified:    usr.sbin/ppp  Makefile chat.c main.c timer.c
  Removed:     usr.sbin/ppp  sig.c sig.h
  Log:
  I remove pending signals completely, they are not useless, they are
  dangerous! Signal handlers themself must be fixed to not call malloc,
  but no pended handlers, it will be correct fix. In finite case each signal
  handler can set some variable which will be analized later, but calling
  handler functions manually is too dangerous (f.e. signals not blocked while
  the handler or handlers switch executed in this case). Of course this
  code can be fixed instead of removing, but it not worth fixing in any case.
  
  Should go into 2.2
  
  In addition sig.c code shows following dangerous fragments (there can be more,
  but I stop after two):
  
  This fragment
  
      if (fn == SIG_DFL || fn == SIG_IGN) {
  	handler[sig-1] = (sig_type)0;
  	<------------- here
          signal(sig,fn);
      } else {
  
  cause NULL pointer reference when signal comes
  "here", but more worse fragment is below:
  
  void handle_signals() {
      int sig;
  
      if (caused)
         for (sig=0; sig<__MAXSIG; sig++, caused>>=1)
             if (caused&1)
                 (*handler[sig])(sig+1);
  }
  
  caused is bitmask which set corresponding bit on each signal coming.
  And now imagine, what happens when some signal comes (bit sets) while loop
  is executed (see caused>>=1 !!!)
  
  In this light carrier drop situation was (as gdb shows)
  1. SIGSEGV in handle_signals because some junk called as *handler reference.
  2. Since SIGSEGV was pended too (== never happens),
  it can cause various range of disasters.
  
  Revision  Changes    Path
  1.15      +2 -2      src/usr.sbin/ppp/Makefile
  1.20      +1 -2      src/usr.sbin/ppp/chat.c
  1.36      +9 -14     src/usr.sbin/ppp/main.c
  1.12      +1 -2      src/usr.sbin/ppp/timer.c