1. 27 May, 2006 5 commits
  2. 26 May, 2006 15 commits
  3. 25 May, 2006 5 commits
  4. 24 May, 2006 9 commits
  5. 23 May, 2006 6 commits
    • Stephen Hemminger's avatar
      [BRIDGE]: need to ref count the LLC sap · 387e2b04
      Stephen Hemminger authored
      Bridge will OOPS on removal if other application has the SAP open.
      The bridge SAP might be shared with other usages, so need
      to do reference counting on module removal rather than explicit
      Since packet might arrive after or during removal, need to clear
      the receive function handle, so LLC only hands it to user (if any).
      Signed-off-by: default avatarStephen Hemminger <shemminger@osdl.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Chris Wright's avatar
      [NETFILTER]: SNMP NAT: fix memleak in snmp_object_decode · 4a063739
      Chris Wright authored
      If kmalloc fails, error path leaks data allocated from asn1_oid_decode().
      Signed-off-by: default avatarChris Wright <chrisw@sous-sol.org>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Patrick McHardy's avatar
      [NETFILTER]: H.323 helper: fix sequence extension parsing · 4d942d8b
      Patrick McHardy authored
      When parsing unknown sequence extensions the "son"-pointer points behind
      the last known extension for this type, don't try to interpret it.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Patrick McHardy's avatar
      [NETFILTER]: H.323 helper: fix parser error propagation · 7185989d
      Patrick McHardy authored
      The condition "> H323_ERROR_STOP" can never be true since H323_ERROR_STOP
      is positive and is the highest possible return code, while real errors are
      negative, fix the checks. Also only abort on real errors in some spots
      that were just interpreting any return value != 0 as error.
      Fixes crashes caused by use of stale data after a parsing error occured:
      BUG: unable to handle kernel paging request at virtual address bfffffff
       printing eip:
      *pde = 1a801067
      *pte = 00000000
      Oops: 0000 [#1]
      Modules linked in: ip_nat_h323 ip_conntrack_h323 nfsd exportfs sch_sfq sch_red cls_fw sch_hfsc  xt_length ipt_owner xt_MARK iptable_mangle nfs lockd sunrpc pppoe pppoxx
      CPU:    0
      EIP:    0060:[<c01aa0f8>]    Not tainted VLI
      EFLAGS: 00210646   (2.6.17-rc4 #8)
      EIP is at memmove+0x19/0x22
      eax: d77264e9   ebx: d77264e9   ecx: e88d9b17   edx: d77264e9
      esi: bfffffff   edi: bfffffff   ebp: de6a7680   esp: c0349db8
      ds: 007b   es: 007b   ss: 0068
      Process asterisk (pid: 3765, threadinfo=c0349000 task=da068540)
      Stack: <0>00000006 c0349e5e d77264e3 e09a2b4e e09a38a0 d7726052 d7726124 00000491
             00000006 00000006 00000006 00000491 de6a7680 d772601e d7726032 c0349f74
             e09a2dc2 00000006 c0349e5e 00000006 00000000 d76dda28 00000491 c0349f74
      Call Trace:
       [<e09a2b4e>] mangle_contents+0x62/0xfe [ip_nat]
       [<e09a2dc2>] ip_nat_mangle_tcp_packet+0xa1/0x191 [ip_nat]
       [<e0a2712d>] set_addr+0x74/0x14c [ip_nat_h323]
       [<e0ad531e>] process_setup+0x11b/0x29e [ip_conntrack_h323]
       [<e0ad534f>] process_setup+0x14c/0x29e [ip_conntrack_h323]
       [<e0ad57bd>] process_q931+0x3c/0x142 [ip_conntrack_h323]
       [<e0ad5dff>] q931_help+0xe0/0x144 [ip_conntrack_h323]
      Found by the PROTOS c07-h2250v4 testsuite.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Bryan O'Sullivan's avatar
      IB/ipath: deref correct pointer when using kernel SMA · 09b74de9
      Bryan O'Sullivan authored
      At this point, the core QP structure hasn't been initialized, so what's
      in there isn't valid.  Get the same information elsewhere.
      Signed-off-by: default avatarBryan O'Sullivan <bos@pathscale.com>
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
    • Bryan O'Sullivan's avatar
      IB/ipath: fix null deref during rdma ops · 39770264
      Bryan O'Sullivan authored
      The problem was that node A's sending thread, which handles sending RDMA
      read response data, would write the trigger word, the last packet would
      be sent, node B would send a new RDMA read request, node A's interrupt
      handler would initialize s_rdma_sge, then node A's sending thread would
      update s_rdma_sge.  This didn't happen very often naturally but was more
      frequent with 1 byte RDMA reads.  Rather than adding more locking or
      increasing the QP structure size and copying sge data, I modified the
      copy routine to update the pointers before writing the trigger word to
      avoid the update race.
      Signed-off-by: default avatarRalph Campbell <ralphc@pathscale.com>
      Signed-off-by: default avatarBryan O'Sullivan <bos@pathscale.com>
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>