Skip to content
Snippets Groups Projects
  1. Feb 27, 2009
  2. Feb 25, 2009
  3. Feb 24, 2009
    • Josef Drexler's avatar
      netfilter: xt_recent: fix proc-file addition/removal of IPv4 addresses · 325fb5b4
      Josef Drexler authored
      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: default avatarPatrick McHardy <kaber@trash.net>
      325fb5b4
    • Jesper Dangaard Brouer's avatar
      Doc: Refer to ip-sysctl.txt for strict vs. loose rp_filter mode · d18921a0
      Jesper Dangaard Brouer authored
      
      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: default avatarJesper Dangaard Brouer <hawk@comx.dk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d18921a0
  4. Feb 23, 2009
  5. Feb 22, 2009
    • Paul Moore's avatar
      cipso: Fix documentation comment · 586c2500
      Paul Moore authored
      
      The CIPSO protocol engine incorrectly stated that the FIPS-188 specification
      could be found in the kernel's Documentation directory.  This patch corrects
      that by removing the comment and directing users to the FIPS-188 documented
      hosted online.  For the sake of completeness I've also included a link to the
      CIPSO draft specification on the NetLabel website.
      
      Thanks to Randy Dunlap for spotting the error and letting me know.
      
      Signed-off-by: default avatarPaul Moore <paul.moore@hp.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      586c2500
    • Daniel Lezcano's avatar
      netns: fix double free at netns creation · 486a87f1
      Daniel Lezcano authored
      
      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: default avatarDaniel Lezcano <daniel.lezcano@free.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      486a87f1
    • Herbert Xu's avatar
      tcp: Always set urgent pointer if it's beyond snd_nxt · 7691367d
      Herbert Xu authored
      
      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: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7691367d
    • Hannes Eder's avatar
      ipv6: fix sparse warning: Using plain integer as NULL pointer · 66da8c52
      Hannes Eder authored
      
      Fix this sparse warning:
        net/ipv6/xfrm6_state.c:72:26: warning: Using plain integer as NULL pointer
      
      Signed-off-by: default avatarHannes Eder <hannes@hanneseder.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      66da8c52
Loading