linux-stable.git/net/ipv4/netfilter, branch linux-2.6.17.y Linux kernel stable tree ip_tables: fix table locking in ipt_do_table 2006-08-23T21:13:31+00:00 Patrick McHardy kaber@trash.net 2006-08-18T05:52:57+00:00 0872a284963a642ba748cbd75842138dd9a3bd00 [NETFILTER]: ip_tables: fix table locking in ipt_do_table table->private might change because of ruleset changes, don't use it without holding the lock. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
[NETFILTER]: ip_tables: fix table locking in ipt_do_table

table->private might change because of ruleset changes, don't use it without
holding the lock.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ulog: fix panic on SMP kernels 2006-08-23T21:13:31+00:00 Mark Huang mlhuang@cs.princeton.edu 2006-08-12T00:45:44+00:00 bb417c4bad96b07f075b98f874fb28cf258f8065 [NETFILTER]: ulog: fix panic on SMP kernels Fix kernel panic on various SMP machines. The culprit is a null ub->skb in ulog_send(). If ulog_timer() has already been scheduled on one CPU and is spinning on the lock, and ipt_ulog_packet() flushes the queue on another CPU by calling ulog_send() right before it exits, there will be no skbuff when ulog_timer() acquires the lock and calls ulog_send(). Cancelling the timer in ulog_send() doesn't help because it has already been scheduled and is running on the first CPU. Similar problem exists in ebt_ulog.c and nfnetlink_log.c. Signed-off-by: Mark Huang <mlhuang@cs.princeton.edu> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
[NETFILTER]: ulog: fix panic on SMP kernels

Fix kernel panic on various SMP machines. The culprit is a null
ub->skb in ulog_send(). If ulog_timer() has already been scheduled on
one CPU and is spinning on the lock, and ipt_ulog_packet() flushes the
queue on another CPU by calling ulog_send() right before it exits,
there will be no skbuff when ulog_timer() acquires the lock and calls
ulog_send(). Cancelling the timer in ulog_send() doesn't help because
it has already been scheduled and is running on the first CPU.

Similar problem exists in ebt_ulog.c and nfnetlink_log.c.

Signed-off-by: Mark Huang <mlhuang@cs.princeton.edu>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
H.323 helper: fix possible NULL-ptr dereference 2006-08-07T03:52:13+00:00 Patrick McHardy kaber@trash.net 2006-07-25T00:31:14+00:00 4f40508af128fc5ead71aab6e9932039d2a07fd4 [NETFILTER]: H.323 helper: fix possible NULL-ptr dereference An RCF message containing a timeout results in a NULL-ptr dereference if no RRQ has been seen before. Noticed by the "SATURN tool", reported by Thomas Dillig <tdillig@stanford.edu> and Isil Dillig <isil@stanford.edu>. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
[NETFILTER]: H.323 helper: fix possible NULL-ptr dereference

An RCF message containing a timeout results in a NULL-ptr dereference if
no RRQ has been seen before.

Noticed by the "SATURN tool", reported by Thomas Dillig <tdillig@stanford.edu>
and Isil Dillig <isil@stanford.edu>.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] NETFILTER: SCTP conntrack: fix crash triggered by packet without chunks [CVE-2006-2934] 2006-06-30T17:37:31+00:00 Patrick McHardy kaber@trash.net 2006-06-30T03:33:12+00:00 9c48e1ea8cf8800cc5e2d39ccbb8b5ff9704f8e9 When a packet without any chunks is received, the newconntrack variable in sctp_packet contains an out of bounds value that is used to look up an pointer from the array of timeouts, which is then dereferenced, resulting in a crash. Make sure at least a single chunk is present. Problem noticed by George A. Theall <theall@tenablesecurity.com> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
When a packet without any chunks is received, the newconntrack variable
in sctp_packet contains an out of bounds value that is used to look up an
pointer from the array of timeouts, which is then dereferenced, resulting
in a crash. Make sure at least a single chunk is present.

Problem noticed by George A. Theall <theall@tenablesecurity.com>

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
[NETFILTER]: PPTP helper: fix sstate/cstate typo 2006-05-29T05:51:05+00:00 Alexey Dobriyan adobriyan@gmail.com 2006-05-29T05:51:05+00:00 7114b0bb6df7b2db266ba4847e4dd8333fa98a9a Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> 
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
[NETFILTER]: mark H.323 helper experimental 2006-05-29T05:50:40+00:00 Patrick McHardy kaber@trash.net 2006-05-29T05:50:40+00:00 ca3ba88d0cf4b5d7a628caf505c231162dde9429 Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> 
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
[NETFILTER]: Fix small information leak in SO_ORIGINAL_DST (CVE-2006-1343) 2006-05-29T05:50:18+00:00 Marcel Holtmann marcel@holtmann.org 2006-05-29T05:50:18+00:00 6c813c3fe9e30fcf3c4d94d2ba24108babd745b0 It appears that sockaddr_in.sin_zero is not zeroed during getsockopt(...SO_ORIGINAL_DST...) operation. This can lead to an information leak (CVE-2006-1343). Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> 
It appears that sockaddr_in.sin_zero is not zeroed during
getsockopt(...SO_ORIGINAL_DST...) operation. This can lead
to an information leak (CVE-2006-1343).

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
[NETFILTER]: SNMP NAT: fix memleak in snmp_object_decode 2006-05-23T22:15:13+00:00 Chris Wright chrisw@sous-sol.org 2006-05-23T22:08:13+00:00 4a063739138e2c4e933188d641f1593e01ce8285 If kmalloc fails, error path leaks data allocated from asn1_oid_decode(). Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> 
If kmalloc fails, error path leaks data allocated from asn1_oid_decode().

Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
[NETFILTER]: H.323 helper: fix sequence extension parsing 2006-05-23T22:15:10+00:00 Patrick McHardy kaber@trash.net 2006-05-23T22:07:46+00:00 4d942d8b39bf7d43ce93d85964aeb63aeace0593 When parsing unknown sequence extensions the "son"-pointer points behind the last known extension for this type, don't try to interpret it. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> 
When parsing unknown sequence extensions the "son"-pointer points behind
the last known extension for this type, don't try to interpret it.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
[NETFILTER]: H.323 helper: fix parser error propagation 2006-05-23T22:15:08+00:00 Patrick McHardy kaber@trash.net 2006-05-23T22:07:07+00:00 7185989db4d926dbef1a2f638c464f35599c83e0 The condition "> H323_ERROR_STOP" can never be true since H323_ERROR_STOP is positive and is the highest possible return code, while real errors are negative, fix the checks. Also only abort on real errors in some spots that were just interpreting any return value != 0 as error. Fixes crashes caused by use of stale data after a parsing error occured: BUG: unable to handle kernel paging request at virtual address bfffffff printing eip: c01aa0f8 *pde = 1a801067 *pte = 00000000 Oops: 0000 [#1] PREEMPT Modules linked in: ip_nat_h323 ip_conntrack_h323 nfsd exportfs sch_sfq sch_red cls_fw sch_hfsc xt_length ipt_owner xt_MARK iptable_mangle nfs lockd sunrpc pppoe pppoxx CPU: 0 EIP: 0060:[<c01aa0f8>] Not tainted VLI EFLAGS: 00210646 (2.6.17-rc4 #8) EIP is at memmove+0x19/0x22 eax: d77264e9 ebx: d77264e9 ecx: e88d9b17 edx: d77264e9 esi: bfffffff edi: bfffffff ebp: de6a7680 esp: c0349db8 ds: 007b es: 007b ss: 0068 Process asterisk (pid: 3765, threadinfo=c0349000 task=da068540) Stack: <0>00000006 c0349e5e d77264e3 e09a2b4e e09a38a0 d7726052 d7726124 00000491 00000006 00000006 00000006 00000491 de6a7680 d772601e d7726032 c0349f74 e09a2dc2 00000006 c0349e5e 00000006 00000000 d76dda28 00000491 c0349f74 Call Trace: [<e09a2b4e>] mangle_contents+0x62/0xfe [ip_nat] [<e09a2dc2>] ip_nat_mangle_tcp_packet+0xa1/0x191 [ip_nat] [<e0a2712d>] set_addr+0x74/0x14c [ip_nat_h323] [<e0ad531e>] process_setup+0x11b/0x29e [ip_conntrack_h323] [<e0ad534f>] process_setup+0x14c/0x29e [ip_conntrack_h323] [<e0ad57bd>] process_q931+0x3c/0x142 [ip_conntrack_h323] [<e0ad5dff>] q931_help+0xe0/0x144 [ip_conntrack_h323] ... Found by the PROTOS c07-h2250v4 testsuite. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> 
The condition "> H323_ERROR_STOP" can never be true since H323_ERROR_STOP
is positive and is the highest possible return code, while real errors are
negative, fix the checks. Also only abort on real errors in some spots
that were just interpreting any return value != 0 as error.

Fixes crashes caused by use of stale data after a parsing error occured:

BUG: unable to handle kernel paging request at virtual address bfffffff
 printing eip:
c01aa0f8
*pde = 1a801067
*pte = 00000000
Oops: 0000 [#1]
PREEMPT
Modules linked in: ip_nat_h323 ip_conntrack_h323 nfsd exportfs sch_sfq sch_red cls_fw sch_hfsc  xt_length ipt_owner xt_MARK iptable_mangle nfs lockd sunrpc pppoe pppoxx
CPU:    0
EIP:    0060:[<c01aa0f8>]    Not tainted VLI
EFLAGS: 00210646   (2.6.17-rc4 #8)
EIP is at memmove+0x19/0x22
eax: d77264e9   ebx: d77264e9   ecx: e88d9b17   edx: d77264e9
esi: bfffffff   edi: bfffffff   ebp: de6a7680   esp: c0349db8
ds: 007b   es: 007b   ss: 0068
Process asterisk (pid: 3765, threadinfo=c0349000 task=da068540)
Stack: <0>00000006 c0349e5e d77264e3 e09a2b4e e09a38a0 d7726052 d7726124 00000491
       00000006 00000006 00000006 00000491 de6a7680 d772601e d7726032 c0349f74
       e09a2dc2 00000006 c0349e5e 00000006 00000000 d76dda28 00000491 c0349f74
Call Trace:
 [<e09a2b4e>] mangle_contents+0x62/0xfe [ip_nat]
 [<e09a2dc2>] ip_nat_mangle_tcp_packet+0xa1/0x191 [ip_nat]
 [<e0a2712d>] set_addr+0x74/0x14c [ip_nat_h323]
 [<e0ad531e>] process_setup+0x11b/0x29e [ip_conntrack_h323]
 [<e0ad534f>] process_setup+0x14c/0x29e [ip_conntrack_h323]
 [<e0ad57bd>] process_q931+0x3c/0x142 [ip_conntrack_h323]
 [<e0ad5dff>] q931_help+0xe0/0x144 [ip_conntrack_h323]
...

Found by the PROTOS c07-h2250v4 testsuite.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>