01 Oct, 2009

1 commit

  • This provides safety against negative optlen at the type
    level instead of depending upon (sometimes non-trivial)
    checks against this sprinkled all over the the place, in
    each and every implementation.

    Based upon work done by Arjan van de Ven and feedback
    from Linus Torvalds.

    Signed-off-by: David S. Miller

    David S. Miller
     

08 Oct, 2008

2 commits

  • From kernel perspective, allow entrance in nf_hook_slow().

    Stuff which uses nf_register_hook/nf_register_hooks, but otherwise not netns-ready:

    DECnet netfilter
    ipt_CLUSTERIP
    nf_nat_standalone.c together with XFRM (?)
    IPVS
    several individual match modules (like hashlimit)
    ctnetlink
    NOTRACK
    all sorts of queueing and reporting to userspace
    L3 and L4 protocol sysctls, bridge sysctls
    probably something else

    Anyway critical mass has been achieved, there is no reason to hide netfilter any longer.

    From userspace perspective, allow to manipulate all sorts of
    iptables/ip6tables/arptables rules.

    Signed-off-by: Alexey Dobriyan
    Signed-off-by: Patrick McHardy

    Alexey Dobriyan
     
  • and (try to) consistently use u_int8_t for the L3 family.

    Signed-off-by: Jan Engelhardt
    Signed-off-by: Patrick McHardy

    Jan Engelhardt
     

20 Jul, 2008

1 commit


26 Mar, 2008

1 commit


16 Nov, 2007

1 commit


13 Nov, 2007

1 commit


07 Nov, 2007

1 commit


11 Oct, 2007

1 commit


11 Sep, 2007

1 commit

  • So I've had a deadlock reported to me. I've found that the sequence of
    events goes like this:

    1) process A (modprobe) runs to remove ip_tables.ko

    2) process B (iptables-restore) runs and calls setsockopt on a netfilter socket,
    increasing the ip_tables socket_ops use count

    3) process A acquires a file lock on the file ip_tables.ko, calls remove_module
    in the kernel, which in turn executes the ip_tables module cleanup routine,
    which calls nf_unregister_sockopt

    4) nf_unregister_sockopt, seeing that the use count is non-zero, puts the
    calling process into uninterruptible sleep, expecting the process using the
    socket option code to wake it up when it exits the kernel

    4) the user of the socket option code (process B) in do_ipt_get_ctl, calls
    ipt_find_table_lock, which in this case calls request_module to load
    ip_tables_nat.ko

    5) request_module forks a copy of modprobe (process C) to load the module and
    blocks until modprobe exits.

    6) Process C. forked by request_module process the dependencies of
    ip_tables_nat.ko, of which ip_tables.ko is one.

    7) Process C attempts to lock the request module and all its dependencies, it
    blocks when it attempts to lock ip_tables.ko (which was previously locked in
    step 3)

    Theres not really any great permanent solution to this that I can see, but I've
    developed a two part solution that corrects the problem

    Part 1) Modifies the nf_sockopt registration code so that, instead of using a
    use counter internal to the nf_sockopt_ops structure, we instead use a pointer
    to the registering modules owner to do module reference counting when nf_sockopt
    calls a modules set/get routine. This prevents the deadlock by preventing set 4
    from happening.

    Part 2) Enhances the modprobe utilty so that by default it preforms non-blocking
    remove operations (the same way rmmod does), and add an option to explicity
    request blocking operation. So if you select blocking operation in modprobe you
    can still cause the above deadlock, but only if you explicity try (and since
    root can do any old stupid thing it would like.... :) ).

    Signed-off-by: Neil Horman
    Signed-off-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Neil Horman
     

13 Feb, 2007

1 commit


01 Jul, 2006

1 commit


21 Mar, 2006

3 commits


30 Aug, 2005

1 commit