linux-stable.git/net/bridge, branch linux-2.6.23.y

Netfilter: bridge-netfilter: fix net_device refcnt leaks

2008-02-08T20:01:49+00:00

[NETFILTER]: bridge-netfilter: fix net_device refcnt leaks

Upstream commit 2dc2f207fb251666d2396fe1a69272b307ecc333

When packets are flood-forwarded to multiple output devices, the
bridge-netfilter code reuses skb->nf_bridge for each clone to store
the bridge port. When queueing packets using NFQUEUE netfilter takes
a reference to skb->nf_bridge->physoutdev, which is overwritten
when the packet is forwarded to the second port. This causes
refcount unterflows for the first device and refcount leaks for all
others. Additionally this provides incorrect data to the iptables
physdev match.

Unshare skb->nf_bridge by copying it if it is shared before assigning
the physoutdev device.

Reported, tested and based on initial patch by
Jan Christoph Nordholz .

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Netfilter: bridge: fix double POST_ROUTING invocation

2008-02-08T20:01:48+00:00

[NETFILTER]: bridge: fix double POST_ROUTING invocation

Upstream commit 2948d2ebbb98747b912ac6d0c864b4d02be8a6f5

The bridge code incorrectly causes two POST_ROUTING hook invocations
for DNATed packets that end up on the same bridge device. This
happens because packets with a changed destination address are passed
to dst_output() to make them go through the neighbour output function
again to build a new destination MAC address, before they will continue
through the IP hooks simulated by bridge netfilter.

The resulting hook order is:
 PREROUTING (bridge netfilter)
 POSTROUTING        (dst_output -> ip_output)
 FORWARD    (bridge netfilter)
 POSTROUTING        (bridge netfilter)

The deferred hooks used to abort the first POST_ROUTING invocation,
but since the only thing bridge netfilter actually really wants is
a new MAC address, we can avoid going through the IP stack completely
by simply calling the neighbour output function directly.

Tested, reported and lots of data provided by: Damien Thebault 

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

BRIDGE: Section fix.

2007-12-15T03:44:40+00:00

WARNING: vmlinux.o(.init.text+0x204e2): Section mismatch: reference to .exit.text:br_fdb_fini (between 'br_init' and 'br_fdb_init')

Signed-off-by: Andrew Morton 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

BRIDGE: Properly dereference the br_should_route_hook

2007-12-14T17:51:17+00:00

[BRIDGE]: Properly dereference the br_should_route_hook

[ Upstream commit: 82de382ce8e1c7645984616728dc7aaa057821e4 ]

This hook is protected with the RCU, so simple

if (br_should_route_hook)
	br_should_route_hook(...)

is not enough on some architectures.

Use the rcu_dereference/rcu_assign_pointer in this case.

Fixed Stephen's comment concerning using the typeof().

Signed-off-by: Pavel Emelyanov 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

BRIDGE: Lost call to br_fdb_fini() in br_init() error path

2007-12-14T17:51:05+00:00

[BRIDGE]: Lost call to br_fdb_fini() in br_init() error path

[ Upstream commit: 17efdd45755c0eb8d1418a1368ef7c7ebbe98c6e ]
 
In case the br_netfilter_init() (or any subsequent call)
fails, the br_fdb_fini() must be called to free the allocated
in br_fdb_init() br_fdb_cache kmem cache.

Signed-off-by: Pavel Emelyanov 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

[NET] skbuff: Add skb_cow_head

2007-09-16T23:21:16+00:00

This patch adds an optimised version of skb_cow that avoids the copy if
the header can be modified even if the rest of the payload is cloned.

This can be used in encapsulating paths where we only need to modify the
header.  As it is, this can be used in PPPOE and bridging.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller

[BRIDGE]: Kill clone argument to br_flood_*

2007-09-16T23:20:48+00:00

The clone argument is only used by one caller and that caller can clone
the packet itself.  This patch moves the clone call into the caller and
kills the clone argument.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller

[NETFILTER]: Fix/improve deadlock condition on module removal netfilter

2007-09-11T09:28:26+00:00

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

[BRIDGE]: Fix OOPS when bridging device without ethtool.

2007-08-31T05:16:22+00:00

Bridge code calls ethtool to get speed. The conversion to using
only ethtool_ops broke the case of devices without ethtool_ops.
This is a new regression in 2.6.23.

Rearranged the switch to a logical order, and use gcc initializer.

Ps: speed should have been part of the network device structure from
    the start rather than burying it in ethtool.

Signed-off-by: Stephen Hemminger 
Acked-by: Matthew Wilcox 
Signed-off-by: David S. Miller

[BRIDGE]: Packets leaking out of disabled/blocked ports.

2007-08-31T05:15:35+00:00

This patch fixes some packet leakage in bridge.  The bridging code was
allowing forward table entries to be generated even if a device was
being blocked. The fix is to not add forwarding database entries
unless the port is active.

The bug arose as part of the conversion to processing STP frames
through normal receive path (in 2.6.17).

Signed-off-by: Stephen Hemminger 
Acked-by: John W. Linville 
Signed-off-by: David S. Miller