1. 12 6月, 2006 1 次提交
  2. 06 6月, 2006 4 次提交
  3. 03 6月, 2006 1 次提交
  4. 29 5月, 2006 3 次提交
  5. 27 5月, 2006 2 次提交
  6. 24 5月, 2006 5 次提交
    • S
      [BRIDGE]: need to ref count the LLC sap · 387e2b04
      Stephen Hemminger 提交于
      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
      close/delete.
      
      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: NStephen Hemminger <shemminger@osdl.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      387e2b04
    • C
      [NETFILTER]: SNMP NAT: fix memleak in snmp_object_decode · 4a063739
      Chris Wright 提交于
      If kmalloc fails, error path leaks data allocated from asn1_oid_decode().
      Signed-off-by: NChris Wright <chrisw@sous-sol.org>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a063739
    • P
      [NETFILTER]: H.323 helper: fix sequence extension parsing · 4d942d8b
      Patrick McHardy 提交于
      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: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4d942d8b
    • P
      [NETFILTER]: H.323 helper: fix parser error propagation · 7185989d
      Patrick McHardy 提交于
      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:
      c01aa0f8
      *pde = 1a801067
      *pte = 00000000
      Oops: 0000 [#1]
      PREEMPT
      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: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7185989d
    • N
      [PATCH] knfsd: Fix two problems that can cause rmmod nfsd to die · f2d39586
      NeilBrown 提交于
      Both cause the 'entries' count in the export cache to be non-zero at module
      removal time, so unregistering that cache fails and results in an oops.
      
      1/ exp_pseudoroot (used for NFSv4 only) leaks a reference to an export
         entry.
      2/ sunrpc_cache_update doesn't increment the entries count when it adds
         an entry.
      
      Thanks to "david m.  richter" <richterd@citi.umich.edu> for triggering the
      problem and finding one of the bugs.
      
      Cc: "david m. richter" <richterd@citi.umich.edu>
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f2d39586
  7. 23 5月, 2006 3 次提交
  8. 20 5月, 2006 4 次提交
  9. 19 5月, 2006 5 次提交
  10. 17 5月, 2006 6 次提交
  11. 13 5月, 2006 1 次提交
    • S
      [NEIGH]: Fix IP-over-ATM and ARP interaction. · bd89efc5
      Simon Kelley 提交于
      The classical IP over ATM code maintains its own IPv4 <-> <ATM stuff>
      ARP table, using the standard neighbour-table code. The
      neigh_table_init function adds this neighbour table to a linked list
      of all neighbor tables which is used by the functions neigh_delete()
      neigh_add() and neightbl_set(), all called by the netlink code.
      
      Once the ATM neighbour table is added to the list, there are two
      tables with family == AF_INET there, and ARP entries sent via netlink
      go into the first table with matching family. This is indeterminate
      and often wrong.
      
      To see the bug, on a kernel with CLIP enabled, create a standard IPv4
      ARP entry by pinging an unused address on a local subnet. Then attempt
      to complete that entry by doing
      
      ip neigh replace <ip address> lladdr <some mac address> nud reachable
      
      Looking at the ARP tables by using 
      
      ip neigh show
      
      will reveal two ARP entries for the same address. One of these can be
      found in /proc/net/arp, and the other in /proc/net/atm/arp.
      
      This patch adds a new function, neigh_table_init_no_netlink() which
      does everything the neigh_table_init() does, except add the table to
      the netlink all-arp-tables chain. In addition neigh_table_init() has a
      check that all tables on the chain have a distinct address family.
      The init call in clip.c is changed to call
      neigh_table_init_no_netlink().
      
      Since ATM ARP tables are rather more complicated than can currently be
      handled by the available rtattrs in the netlink protocol, no
      functionality is lost by this patch, and non-ATM ARP manipulation via
      netlink is rescued. A more complete solution would involve a rtattr
      for ATM ARP entries and some way for the netlink code to give
      neigh_add and friends more information than just address family with
      which to find the correct ARP table.
      
      [ I've changed the assertion checking in neigh_table_init() to not
        use BUG_ON() while holding neigh_tbl_lock.  Instead we remember that
        we found an existing tbl with the same family, and after dropping
        the lock we'll give a diagnostic kernel log message and a stack dump.
        -DaveM ]
      Signed-off-by: NSimon Kelley <simon@thekelleys.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd89efc5
  12. 12 5月, 2006 1 次提交
  13. 11 5月, 2006 3 次提交
  14. 10 5月, 2006 1 次提交