1. 29 Aug, 2005 2 commits
  2. 26 Jul, 2005 1 commit
  3. 11 Jul, 2005 1 commit
    • Sam Ravnborg's avatar
      [NET]: move config options out to individual protocols · 6a2e9b73
      Sam Ravnborg authored
      Move the protocol specific config options out to the specific protocols.
      With this change net/Kconfig now starts to become readable and serve as a
      good basis for further re-structuring.
      The menu structure is left almost intact, except that indention is
      fixed in most cases. Most visible are the INET changes where several
      "depends on INET" are replaced with a single ifdef INET / endif pair.
      Several new files were created to accomplish this change - they are
      small but serve the purpose that config options are now distributed
      out where they belongs.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  4. 20 Jun, 2005 2 commits
  5. 18 Jun, 2005 8 commits
  6. 26 May, 2005 1 commit
  7. 19 May, 2005 2 commits
  8. 18 May, 2005 1 commit
  9. 03 May, 2005 5 commits
    • Herbert Xu's avatar
      [IPSEC]: Store idev entries · aabc9761
      Herbert Xu authored
      I found a bug that stopped IPsec/IPv6 from working.  About
      a month ago IPv6 started using rt6i_idev->dev on the cached socket dst
      entries.  If the cached socket dst entry is IPsec, then rt6i_idev will
      be NULL.
      Since we want to look at the rt6i_idev of the original route in this
      case, the easiest fix is to store rt6i_idev in the IPsec dst entry just
      as we do for a number of other IPv6 route attributes.  Unfortunately
      this means that we need some new code to handle the references to
      rt6i_idev.  That's why this patch is bigger than it would otherwise be.
      I've also done the same thing for IPv4 since it is conceivable that
      once these idev attributes start getting used for accounting, we
      probably need to dereference them for IPv4 IPsec entries too.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • David S. Miller's avatar
      [XFRM/RTNETLINK]: Decrement qlen properly in {xfrm_,rt}netlink_rcv(). · 0f4821e7
      David S. Miller authored
      If we free up a partially processed packet because it's
      skb->len dropped to zero, we need to decrement qlen because
      we are dropping out of the top-level loop so it will do
      the decrement for us.
      Spotted by Herbert Xu.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • David S. Miller's avatar
      [NETLINK]: Fix infinite loops in synchronous netlink changes. · 09e14305
      David S. Miller authored
      The qlen should continue to decrement, even if we
      pop partially processed SKBs back onto the receive queue.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Herbert Xu's avatar
      [NETLINK]: Synchronous message processing. · 2a0a6ebe
      Herbert Xu authored
      Let's recap the problem.  The current asynchronous netlink kernel
      message processing is vulnerable to these attacks:
      1) Hit and run: Attacker sends one or more messages and then exits
      before they're processed.  This may confuse/disable the next netlink
      user that gets the netlink address of the attacker since it may
      receive the responses to the attacker's messages.
      Proposed solutions:
      a) Synchronous processing.
      b) Stream mode socket.
      c) Restrict/prohibit binding.
      2) Starvation: Because various netlink rcv functions were written
      to not return until all messages have been processed on a socket,
      it is possible for these functions to execute for an arbitrarily
      long period of time.  If this is successfully exploited it could
      also be used to hold rtnl forever.
      Proposed solutions:
      a) Synchronous processing.
      b) Stream mode socket.
      Firstly let's cross off solution c).  It only solves the first
      problem and it has user-visible impacts.  In particular, it'll
      break user space applications that expect to bind or communicate
      with specific netlink addresses (pid's).
      So we're left with a choice of synchronous processing versus
      SOCK_STREAM for netlink.
      For the moment I'm sticking with the synchronous approach as
      suggested by Alexey since it's simpler and I'd rather spend
      my time working on other things.
      However, it does have a number of deficiencies compared to the
      stream mode solution:
      1) User-space to user-space netlink communication is still vulnerable.
      2) Inefficient use of resources.  This is especially true for rtnetlink
      since the lock is shared with other users such as networking drivers.
      The latter could hold the rtnl while communicating with hardware which
      causes the rtnetlink user to wait when it could be doing other things.
      3) It is still possible to DoS all netlink users by flooding the kernel
      netlink receive queue.  The attacker simply fills the receive socket
      with a single netlink message that fills up the entire queue.  The
      attacker then continues to call sendmsg with the same message in a loop.
      Point 3) can be countered by retransmissions in user-space code, however
      it is pretty messy.
      In light of these problems (in particular, point 3), we should implement
      stream mode netlink at some point.  In the mean time, here is a patch
      that implements synchronous processing.  
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Thomas Graf's avatar
      [XFRM]: Cleanup xfrm_msg_min and xfrm_dispatch · 492b558b
      Thomas Graf authored
      Converts xfrm_msg_min and xfrm_dispatch to use c99 designated
      initializers to make greping a little bit easier. Also replaces
      two hardcoded message type with meaningful names.
      Signed-off-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  10. 21 Apr, 2005 1 commit
  11. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      Let it rip!