1. 28 2月, 2009 17 次提交
  2. 25 2月, 2009 6 次提交
  3. 24 2月, 2009 4 次提交
    • J
      netfilter: xt_recent: fix proc-file addition/removal of IPv4 addresses · 325fb5b4
      Josef Drexler 提交于
      Fix regression introduded by commit 079aa88f (netfilter: xt_recent: IPv6 support):
      
      From http://bugzilla.kernel.org/show_bug.cgi?id=12753:
      
      Problem Description:
      An uninitialized buffer causes IPv4 addresses added manually (via the +IP
      command to the proc interface) to never match any packets. Similarly, the -IP
      command fails to remove IPv4 addresses.
      
      Details:
      In the function recent_entry_lookup, the xt_recent module does comparisons of
      the entire nf_inet_addr union value, both for IPv4 and IPv6 addresses. For
      addresses initialized from actual packets the remaining 12 bytes not occupied
      by the IPv4 are zeroed so this works correctly. However when setting the
      nf_inet_addr addr variable in the recent_mt_proc_write function, only the IPv4
      bytes are initialized and the remaining 12 bytes contain garbage.
      
      Hence addresses added in this way never match any packets, unless these
      uninitialized 12 bytes happened to be zero by coincidence. Similarly, addresses
      cannot consistently be removed using the proc interface due to mismatch of the
      garbage bytes (although it will sometimes work to remove an address that was
      added manually).
      
      Reading the /proc/net/xt_recent/ entries hides this problem because this only
      uses the first 4 bytes when displaying IPv4 addresses.
      
      Steps to reproduce:
      $ iptables -I INPUT -m recent --rcheck -j LOG
      $ echo +169.254.156.239 > /proc/net/xt_recent/DEFAULT
      $ cat /proc/net/xt_recent/DEFAULT
      src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
      
      [At this point no packets from 169.254.156.239 are being logged.]
      
      $ iptables -I INPUT -s 169.254.156.239 -m recent --set
      $ cat /proc/net/xt_recent/DEFAULT
      src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
      src=169.254.156.239 ttl: 255 last_seen: 126184 oldest_pkt: 4 125434, 125684, 125934, 126184
      
      [At this point, adding the address via an iptables rule, packets are being
      logged correctly.]
      
      $ echo -169.254.156.239 > /proc/net/xt_recent/DEFAULT
      $ cat /proc/net/xt_recent/DEFAULT
      src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
      src=169.254.156.239 ttl: 255 last_seen: 126992 oldest_pkt: 10 125434, 125684, 125934, 126184, 126434, 126684, 126934, 126991, 126991, 126992
      $ echo -169.254.156.239 > /proc/net/xt_recent/DEFAULT
      $ cat /proc/net/xt_recent/DEFAULT
      src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
      src=169.254.156.239 ttl: 255 last_seen: 126992 oldest_pkt: 10 125434, 125684, 125934, 126184, 126434, 126684, 126934, 126991, 126991, 126992
      
      [Removing the address via /proc interface failed evidently.]
      
      Possible solutions:
      - initialize the addr variable in recent_mt_proc_write
      - compare only 4 bytes for IPv4 addresses in recent_entry_lookup
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      325fb5b4
    • J
      Doc: Refer to ip-sysctl.txt for strict vs. loose rp_filter mode · d18921a0
      Jesper Dangaard Brouer 提交于
      The IP_ADVANCED_ROUTER Kconfig describes the rp_filter
      proc option.  Recent changes added a loose mode.
      Instead of documenting this change too places, refer to
      the document describing it:
       Documentation/networking/ip-sysctl.txt
      
      I'm considering moving the rp_filter description away
      from the Kconfig file into ip-sysctl.txt.
      Signed-off-by: NJesper Dangaard Brouer <hawk@comx.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d18921a0
    • E
      net: amend the fix for SO_BSDCOMPAT gsopt infoleak · 50fee1de
      Eugene Teo 提交于
      The fix for CVE-2009-0676 (upstream commit df0bca04) is incomplete. Note
      that the same problem of leaking kernel memory will reappear if someone
      on some architecture uses struct timeval with some internal padding (for
      example tv_sec 64-bit and tv_usec 32-bit) --- then, you are going to
      leak the padded bytes to userspace.
      Signed-off-by: NEugene Teo <eugeneteo@kernel.sg>
      Reported-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      50fee1de
    • C
      netns: build fix for net_alloc_generic · ebe47d47
      Clemens Noss 提交于
      net_alloc_generic was defined in #ifdef CONFIG_NET_NS, but used
      unconditionally. Move net_alloc_generic out of #ifdef.
      Signed-off-by: NClemens Noss <cnoss@gmx.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ebe47d47
  4. 23 2月, 2009 10 次提交
  5. 22 2月, 2009 3 次提交
    • D
      netns: fix double free at netns creation · 486a87f1
      Daniel Lezcano 提交于
      This patch fix a double free when a network namespace fails.
      The previous code does a kfree of the net_generic structure when
      one of the init subsystem initialization fails.
      The 'setup_net' function does kfree(ng) and returns an error.
      The caller, 'copy_net_ns', call net_free on error, and this one
      calls kfree(net->gen), making this pointer freed twice.
      
      This patch make the code symetric, the net_alloc does the net_generic
      allocation and the net_free frees the net_generic.
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@free.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      486a87f1
    • H
      tcp: Always set urgent pointer if it's beyond snd_nxt · 7691367d
      Herbert Xu 提交于
      Our TCP stack does not set the urgent flag if the urgent pointer
      does not fit in 16 bits, i.e., if it is more than 64K from the
      sequence number of a packet.
      
      This behaviour is different from the BSDs, and clearly contradicts
      the purpose of urgent mode, which is to send the notification
      (though not necessarily the associated data) as soon as possible.
      Our current behaviour may in fact delay the urgent notification
      indefinitely if the receiver window does not open up.
      
      Simply matching BSD however may break legacy applications which
      incorrectly rely on the out-of-band delivery of urgent data, and
      conversely the in-band delivery of non-urgent data.
      
      Alexey Kuznetsov suggested a safe solution of following BSD only
      if the urgent pointer itself has not yet been transmitted.  This
      way we guarantee that when the remote end sees the packet with
      non-urgent data marked as urgent due to wrap-around we would have
      advanced the urgent pointer beyond, either to the actual urgent
      data or to an as-yet untransmitted packet.
      
      The only potential downside is that applications on the remote
      end may see multiple SIGURG notifications.  However, this would
      occur anyway with other TCP stacks.  More importantly, the outcome
      of such a duplicate notification is likely to be harmless since
      the signal itself does not carry any information other than the
      fact that we're in urgent mode.
      
      Thanks to Ilpo Järvinen for fixing a critical bug in this and
      Jeff Chua for reporting that bug.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7691367d
    • H
      ipv6: fix sparse warning: Using plain integer as NULL pointer · 66da8c52
      Hannes Eder 提交于
      Fix this sparse warning:
        net/ipv6/xfrm6_state.c:72:26: warning: Using plain integer as NULL pointer
      Signed-off-by: NHannes Eder <hannes@hanneseder.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      66da8c52