1. 17 Jun, 2006 19 commits
  2. 28 May, 2006 3 commits
  3. 23 May, 2006 3 commits
    • 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>
      4a063739
    • 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>
      4d942d8b
    • 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:
      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: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7185989d
  4. 22 May, 2006 1 commit
    • Patrick McHardy's avatar
      [NETFILTER]: SNMP NAT: fix memory corruption · f41d5bb1
      Patrick McHardy authored
      
      
      Fix memory corruption caused by snmp_trap_decode:
      
      - When snmp_trap_decode fails before the id and address are allocated,
        the pointers contain random memory, but are freed by the caller
        (snmp_parse_mangle).
      
      - When snmp_trap_decode fails after allocating just the ID, it tries
        to free both address and ID, but the address pointer still contains
        random memory. The caller frees both ID and random memory again.
      
      - When snmp_trap_decode fails after allocating both, it frees both,
        and the callers frees both again.
      
      The corruption can be triggered remotely when the ip_nat_snmp_basic
      module is loaded and traffic on port 161 or 162 is NATed.
      
      Found by multiple testcases of the trap-app and trap-enc groups of the
      PROTOS c06-snmpv1 testsuite.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f41d5bb1
  5. 19 May, 2006 4 commits
  6. 04 May, 2006 5 commits
  7. 02 May, 2006 1 commit
  8. 01 May, 2006 1 commit
    • Patrick McHardy's avatar
      [NETFILTER] x_tables: fix compat related crash on non-x86 · 46c5ea3c
      Patrick McHardy authored
      
      
      When iptables userspace adds an ipt_standard_target, it calculates the size
      of the entire entry as:
      
      sizeof(struct ipt_entry) + XT_ALIGN(sizeof(struct ipt_standard_target))
      
      ipt_standard_target looks like this:
      
        struct xt_standard_target
        {
              struct xt_entry_target target;
              int verdict;
        };
      
      xt_entry_target contains a pointer, so when compiled for 64 bit the
      structure gets an extra 4 byte of padding at the end. On 32 bit
      architectures where iptables aligns to 8 byte it will also have 4
      byte padding at the end because it is only 36 bytes large.
      
      The compat_ipt_standard_fn in the kernel adjusts the offsets by
      
        sizeof(struct ipt_standard_target) - sizeof(struct compat_ipt_standard_target),
      
      which will always result in 4, even if the structure from userspace
      was already padded to a multiple of 8. On x86 this works out by
      accident because userspace only aligns to 4, on all other
      architectures this is broken and causes incorrect adjustments to
      the size and following offsets.
      
      Thanks to Linus for lots of debugging help and testing.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      46c5ea3c
  9. 24 Apr, 2006 1 commit
  10. 11 Apr, 2006 1 commit
  11. 09 Apr, 2006 1 commit