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

NETFILTER: nf_conntrack_tcp: conntrack reopening fix

2008-02-26T00:14:07+00:00

[NETFILTER]: nf_conntrack_tcp: conntrack reopening fix

[Upstream commits b2155e7f + d0c1fd7a]

TCP connection tracking in netfilter did not handle TCP reopening
properly: active close was taken into account for one side only and
not for any side, which is fixed now. The patch includes more comments
to explain the logic how the different cases are handled.
The bug was discovered by Jeff Chua.

Signed-off-by: Jozsef Kadlecsik 
Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

NETFILTER: xt_TCPMSS: remove network triggerable WARN_ON

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

[NETFILTER]: xt_TCPMSS: remove network triggerable WARN_ON

[ Upstream commit: 9dc0564e862b1b9a4677dec2c736b12169e03e99 ]

ipv6_skip_exthdr() returns -1 for invalid packets. don't WARN_ON
that.

Signed-off-by: Patrick McHardy 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

NETFILTER: fix forgotten module release in xt_CONNMARK and xt_CONNSECMARK

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

[NETFILTER]: fix forgotten module release in xt_CONNMARK and xt_CONNSECMARK

[ Upstream commit: 67b4af297033f5f65999885542f95ba7b562848a ]

Fix forgotten module release in xt_CONNMARK and xt_CONNSECMARK

When xt_CONNMARK is used outside the mangle table and the user specified
"--restore-mark", the connmark_tg_check() function will (correctly)
error out, but (incorrectly) forgets to release the L3 conntrack module.
Same for xt_CONNSECMARK.

Fix is to move the call to acquire the L3 module after the basic
constraint checks.

Signed-off-by: Jan Engelhardt 
Signed-off-by: Patrick McHardy 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

NETFILTER: Fix NULL pointer dereference in nf_nat_move_storage()

2007-12-14T17:50:50+00:00

[NETFILTER]: Fix NULL pointer dereference in nf_nat_move_storage()

[ Upstream commit: 7799652557d966e49512479f4d3b9079bbc01fff ]

Reported by Chuck Ebbert as:

	https://bugzilla.redhat.com/show_bug.cgi?id=259501#c14

This routine is called each time hash should be replaced, nf_conn has
extension list which contains pointers to connection tracking users
(like nat, which is right now the only such user), so when replace takes
place it should copy own extensions. Loop above checks for own
extension, but tries to move higer-layer one, which can lead to above
oops.

Signed-off-by: Evgeniy Polyakov 
Signed-off-by: David S. Miller 
Cc: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

NETFILTER: nf_conntrack_tcp: fix connection reopening

2007-11-16T16:27:38+00:00

Upstream commits: 17311393 + bc34b841 merged together.  Merge done by
Patrick McHardy 

[NETFILTER]: nf_conntrack_tcp: fix connection reopening

With your description I could reproduce the bug and actually you were
completely right: the code above is incorrect. Somehow I was able to
misread RFC1122 and mixed the roles :-(:

   When a connection is >>closed actively<<, it MUST linger in
   TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime).
   However, it MAY >>accept<< a new SYN from the remote TCP to
   reopen the connection directly from TIME-WAIT state, if it:
   [...]

The fix is as follows: if the receiver initiated an active close, then the
sender may reopen the connection - otherwise try to figure out if we hold
a dead connection.

Signed-off-by: Jozsef Kadlecsik 
Tested-by: Krzysztof Piotr Oledzki 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

[NETFILTER]: nfnetlink_log: fix sending of multipart messages

2007-09-20T19:13:52+00:00

The following patch fixes the handling of netlink packets containing
multiple messages.

As exposed during netfilter workshop, nfnetlink_log was overwritten the
message type of the last message (setting it to MSG_DONE) in a multipart
packet. The consequence was libnfnetlink to ignore the last message in the
packet.

The following patch adds a supplementary message (with type MSG_DONE) af
the end of the netlink skb.

Signed-off-by: Eric Leblond 
Signed-off-by: Patrick McHardy 
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

[NETFILTER]: xt_tcpudp: fix wrong struct in udp_checkentry

2007-08-31T05:36:43+00:00

It doesn't seem to have any effect on the x86 architecture but it does
have effect on the Axis CRIS architecture.

Signed-off-by: Jesper Bengtsson 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller

[NETFILTER]: nf_conntrack_sip: fix SIP-URI parsing

2007-08-14T20:14:35+00:00

The userinfo component of a SIP-URI is optional, continue parsing at the
beginning of the SIP-URI in case its not found.

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

[NETFILTER]: nf_conntrack_sip: check sname != NULL before calling strncmp

2007-08-14T20:13:54+00:00

The check got lost during the conversion to nf_conntrack.

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