1. 12 11月, 2018 3 次提交
    • G
      ipcp: fix uninitialised memory access when negociating *-NBNS-Address · c3710b6b
      Guillaume Nault 提交于
      When handling the EV_WINS event, IPCP assumes that the ->wins1 and
      ->wins2 fields of the event structure are properly set. But that may
      not be the case.
      If only one of the MS-Primary-NBNS-Server or MS-Secondary-NBNS-Server
      RADIUS attributes was received, then only ->wins1 or ->wins2 is set,
      while the other keeps a non initialised value. This uninitialised value
      is then copied by ev_wins() and proposed to the peer when negociating
      the Primary-NBNS-Address or Secondary-NBNS-Address IPCP options.
      That leaks four bytes of the stack to the network and prevents using
      the values found in the [wins] section of accel-ppp.conf as fallback.
      
      Fix this by initialising the whole event structure in rad_proc_attrs().
      Then, in ev_wins(), we can check if ->wins1 or ->wins2 is properly set
      before copying them. That allows to propery fallback to accel-ppp.conf
      values when one of the values was not provided by RADIUS.
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      c3710b6b
    • G
      ipcp: reject *-DNS-Address if we have no value to propose · 1c40018e
      Guillaume Nault 提交于
      If dns_opt->addr is NULL, then we have no address to propose (none
      defined in accel-ppp.conf and none provided by RADIUS). Currently,
      in that case, accel-ppp accepts and acks the address found in the peer's
      configuration request. But the peer would normally use the undefined IP
      address, so if we ack it, we explicitely tell the peer that 0.0.0.0 is
      the primary/secondary DNS server.
      If the peer already knows a DNS server IP address, it doesn't have to
      negociate it with accel-ppp. It can just use it directly, after it
      retrieved its own IP address. Therefore there is no need for accel-ppp
      to blindly accept addresses proposed by the peer.
      
      This patch rejects *-DNS-Address if accel-ppp has no DNS server to
      propose, making it explicit to the peer that its request can't be
      satisfied.
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      1c40018e
    • G
      ipcp: fix uninitialised memory access when negociating *-DNS-Address · 29b90105
      Guillaume Nault 提交于
      When handling the EV_DNS event, IPCP assumes that the ->dns1 and ->dns2
      fields of the event structure are properly set. But that may not be the
      case.
      If only one of the MS-Primary-DNS-Server or MS-Secondary-DNS-Server
      RADIUS attributes was received, then only ->dns1 or ->dns2 is set,
      while the other keeps a non initialised value. This uninitialised value
      is then copied by ev_dns() and proposed to the peer when negociating
      the Primary-DNS-Address or Secondary-DNS-Address IPCP options.
      That leaks four bytes of the stack to the network and prevents using
      the values found in the [dns] section of accel-ppp.conf as fallback.
      
      Fix this by initialising the whole event structure in rad_proc_attrs().
      Then, in ev_dns(), we can check if ->dns1 or ->dns2 is properly set
      before copying them. That allows to propery fallback to accel-ppp.conf
      values when one of the values was not provided by RADIUS.
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      29b90105
  2. 03 11月, 2018 2 次提交
    • G
      pppd_compat: fix handling of fork() failures · 142c9437
      Guillaume Nault 提交于
      When accel-ppp is under stress (for example because of massive
      disconnections) it may enter a state where no session could be
      created or destroyed anymore.
      
      This happens when at least one of the pppd_compat fork() fail. In this
      case, the error code path doesn't unlock the sigchld handler, which
      prevents it from running the completion callbacks of running scripts.
      If the "fork-limit" option is used, failure to call the completion
      callback will prevent other scripts from running. This will block
      setting up and tearing down sessions, as those will wait indefinitely
      for their pppd_compat scripts to run.
      
      Therefore, we have to unlock the sigchld handler when fork() fails.
      We also need to call fork_queue_wakeup(), because the previous
      check_fork_limit() call already took one reference in the fork limit.
      
      Finally, ev_ses_pre_up() is a bit special because it has to tear the
      session down if the ip-pre-up script failed. Therefore it also has to
      call ap_session_terminate() upon fork() failures.
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      142c9437
    • G
      triton: fix context schedule/wakeup race · c709a126
      Guillaume Nault 提交于
      Allow triton_context_wakeup() to run before triton_context_schedule().
      When that happens, triton_context_schedule() now lets the context
      running instead of putting it in sleep mode.
      
      Note that, even though triton now allows triton_context_wakeup() to
      happen before triton_context_schedule(), these two functions still need
      to be paired and not nested. That is, in a sequence like the following,
      
      triton_context_wakeup()
      triton_context_wakeup()
      triton_context_schedule()
      triton_context_schedule()
      
      the second triton_context_schedule() would put the context in sleep
      mode. No matter how many triton_context_wakeup() have been called, the
      first triton_context_schedule() "consumes" them all.
      
      Being immune to schedule/wakeup inversion allows to fix the pppd_compat
      module. This module needs to fork() to execute external programs. The
      parent then waits for completion of its child using
      triton_context_schedule(). When child terminates, the sigchld module
      runs a callback that has to call triton_context_wakeup() to resume
      execution of the parent.
      
      The problem is that there is no synchronisation between the parent and
      its child. When under stress, the child may execute faster than its
      parent and the sigchld callback might run triton_context_wakeup()
      before the parent had time to call triton_context_schedule().
      
      Then accel-ppp might crash because the triton thread might have reset
      ctx->thread to NULL, making triton_context_wakeup() write to invalid
      memory when trying to insert the context in ctx->thread->wakeup_list[].
      
      Synchronising the parent and its child completion's callback would
      require cooperation from triton_context_schedule(). Otherwise we would
      still have a time frame between the moment we let the callback waking
      up the context and the moment we put the context in sleep mode.
      Allowing schedule/wakeup call inversion in triton looks simpler since
      it avoids modifying the current API.
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      c709a126
  3. 29 10月, 2018 1 次提交
  4. 26 10月, 2018 21 次提交
  5. 25 10月, 2018 3 次提交
  6. 23 10月, 2018 2 次提交
  7. 24 8月, 2018 1 次提交
  8. 31 7月, 2018 2 次提交
  9. 25 6月, 2018 3 次提交
  10. 08 6月, 2018 2 次提交