1. 04 5月, 2006 3 次提交
    • P
      [NETFILTER]: NAT: silence unused variable warnings with CONFIG_XFRM=n · 2354feae
      Patrick McHardy 提交于
      net/ipv4/netfilter/ip_nat_standalone.c: In function 'ip_nat_out':
      net/ipv4/netfilter/ip_nat_standalone.c:223: warning: unused variable 'ctinfo'
      net/ipv4/netfilter/ip_nat_standalone.c:222: warning: unused variable 'ct'
      
      Surprisingly no complaints so far ..
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2354feae
    • P
      [NETFILTER]: H.323 helper: fix use of uninitialized data · 4228e2a9
      Patrick McHardy 提交于
      When a Choice element contains an unsupported choice no error is returned
      and parsing continues normally, but the choice value is not set and
      contains data from the last parsed message. This may in turn lead to
      parsing of more stale data and following crashes.
      
      Fixes a crash triggered by testcase 0003243 from the PROTOS c07-h2250v4
      testsuite following random other testcases:
      
      CPU:    0
      EIP:    0060:[<c01a9554>]    Not tainted VLI
      EFLAGS: 00210646   (2.6.17-rc2 #3)
      EIP is at memmove+0x19/0x22
      eax: d7be0307   ebx: d7be0307   ecx: e841fcf9   edx: d7be0307
      esi: bfffffff   edi: bfffffff   ebp: da5eb980   esp: c0347e2c
      ds: 007b   es: 007b   ss: 0068
      Process events/0 (pid: 4, threadinfo=c0347000 task=dff86a90)
      Stack: <0>00000006 c0347ea6 d7be0301 e09a6b2c 00000006 da5eb980 d7be003e d7be0052
             c0347f6c e09a6d9c 00000006 c0347ea6 00000006 00000000 d7b9a548 00000000
             c0347f6c d7b9a548 00000004 e0a1a119 0000028f 00000006 c0347ea6 00000006
      Call Trace:
       [<e09a6b2c>] mangle_contents+0x40/0xd8 [ip_nat]
       [<e09a6d9c>] ip_nat_mangle_tcp_packet+0xa1/0x191 [ip_nat]
       [<e0a1a119>] set_addr+0x60/0x14d [ip_nat_h323]
       [<e0ab6e66>] q931_help+0x2da/0x71a [ip_conntrack_h323]
       [<e0ab6e98>] q931_help+0x30c/0x71a [ip_conntrack_h323]
       [<e09af242>] ip_conntrack_help+0x22/0x2f [ip_conntrack]
       [<c022934a>] nf_iterate+0x2e/0x5f
       [<c025d357>] xfrm4_output_finish+0x0/0x39f
       [<c02294ce>] nf_hook_slow+0x42/0xb0
       [<c025d357>] xfrm4_output_finish+0x0/0x39f
       [<c025d732>] xfrm4_output+0x3c/0x4e
       [<c025d357>] xfrm4_output_finish+0x0/0x39f
       [<c0230370>] ip_forward+0x1c2/0x1fa
       [<c022f417>] ip_rcv+0x388/0x3b5
       [<c02188f9>] netif_receive_skb+0x2bc/0x2ec
       [<c0218994>] process_backlog+0x6b/0xd0
       [<c021675a>] net_rx_action+0x4b/0xb7
       [<c0115606>] __do_softirq+0x35/0x7d
       [<c0104294>] do_softirq+0x38/0x3f
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4228e2a9
    • P
      [NETFILTER]: H.323 helper: fix endless loop caused by invalid TPKT len · 6fd73703
      Patrick McHardy 提交于
      When the TPKT len included in the packet is below the lowest valid value
      of 4 an underflow occurs which results in an endless loop.
      
      Found by testcase 0000058 from the PROTOS c07-h2250v4 testsuite.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6fd73703
  2. 03 5月, 2006 4 次提交
    • P
      [NETFILTER] SCTP conntrack: fix infinite loop · e17df688
      Patrick McHardy 提交于
      fix infinite loop in the SCTP-netfilter code: check SCTP chunk size to
      guarantee progress of for_each_sctp_chunk(). (all other uses of
      for_each_sctp_chunk() are preceded by do_basic_checks(), so this fix
      should be complete.)
      
      Based on patch from Ingo Molnar <mingo@elte.hu>
      
      CVE-2006-1527
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e17df688
    • A
      forcedeth: fix multi irq issues · ebf34c9b
      Ayaz Abdulla 提交于
      This patch fixes the issues with multiple irqs.
      
      I am resending based on feedback. I decoupled the dma mask for
      consistent memory and fixed leak with multiple irq in error path.
      
      Thanks to Manfred for catching the spin lock problem.
      Signed-Off-By: NAyaz Abdulla <aabdulla@nvidia.com>
      ebf34c9b
    • C
      [PATCH] via-rhine: zero pad short packets on Rhine I ethernet cards · 3e0d167a
      Craig Brind 提交于
      Fixes Rhine I cards disclosing fragments of previously transmitted frames
      in new transmissions.
      
      Before transmission, any socket buffer (skb) shorter than the ethernet
      minimum length of 60 bytes was zero-padded.  On Rhine I cards the data can
      later be copied into an aligned transmission buffer without copying this
      padding.  This resulted in the transmission of the frame with the extra
      bytes beyond the provided content leaking the previous contents of this
      buffer on to the network.
      
      Now zero-padding is repeated in the local aligned buffer if one is used.
      
      Following a suggestion from the via-rhine maintainer, no attempt is made
      here to avoid the duplicated effort of padding the skb if it is known that
      an aligned buffer will definitely be used.  This is to make the change
      "obviously correct" and allow it to be applied to a stable kernel if
      necessary.  There is no change to the flow of control and the changes are
      only to the Rhine I code path.
      
      The patch has run on an in-service Rhine-I host without incident.  Frames
      shorter than 60 bytes are now correctly zero-padded when captured on a
      separate host.  I see no unusual stats reported by ifconfig, and no unusual
      log messages.
      Signed-off-by: NCraig Brind <craigbrind@gmail.com>
      Signed-off-by: NRoger Luethi <rl@hellgate.ch>
      Cc: Jeff Garzik <jeff@garzik.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      3e0d167a
    • O
      [PATCH] mv643xx_eth: provide sysfs class device symlink · b0b8dab2
      Olaf Hering 提交于
      On Sat, Mar 11, Olaf Hering wrote:
      > Why is the /sys/class/net/eth0/device symlink not created for the
      > mv643xx_eth driver? Does this work for other platform device drivers?
      > Seems to work for the ps2 keyboard at least.
      
      The SET_NETDEV_DEV has to be done before a call to register_netdev.  With
      the new patch below, the device symlink for the platform device was
      created.  Unfortunately, after the 4 ls commands, the network connection
      died.  No idea if the box crashed or if something else broke, lost remote
      access.
      
      Provide sysfs 'device' in /class/net/ethN Also, set module owner field,
      like pcnet32 driver does.
      Signed-off-by: NOlaf Hering <olh@suse.de>
      Acked-by: NDale Farnsworth <dale@farnsworth.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      b0b8dab2
  3. 02 5月, 2006 33 次提交