linux-toradex.git/net, branch v2.6.16.23

[PATCH] NETFILTER: SCTP conntrack: fix crash triggered by packet without chunks [CVE-2006-2934]

2006-06-30T21:06:52+00:00

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 

Signed-off-by: Patrick McHardy 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] xt_sctp: fix endless loop caused by 0 chunk length (CVE-2006-3085)

2006-06-20T08:54:53+00:00

Fix endless loop in the SCTP match similar to those already fixed in the
SCTP conntrack helper (was CVE-2006-1527).

Signed-off-by: Patrick McHardy 
Signed-off-by: Chris Wright

[PATCH] NETFILTER: Fix small information leak in SO_ORIGINAL_DST (CVE-2006-1343)

2006-05-31T00:31:35+00:00

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 
Signed-off-by: Chris Wright

[PATCH] NETFILTER: SNMP NAT: fix memory corruption (CVE-2006-2444)

2006-05-22T18:04:25+00:00

CVE-2006-2444 - Potential remote DoS in SNMP NAT helper.

Fix memory corruption caused by snmp_trap_decode:

- When snmp_trap_decode fails before the id and address are allocated,
  the pointers contain random memory, but are freed by the caller
  (snmp_parse_mangle).

- When snmp_trap_decode fails after allocating just the ID, it tries
  to free both address and ID, but the address pointer still contains
  random memory. The caller frees both ID and random memory again.

- When snmp_trap_decode fails after allocating both, it frees both,
  and the callers frees both again.

The corruption can be triggered remotely when the ip_nat_snmp_basic
module is loaded and traffic on port 161 or 162 is NATed.

Found by multiple testcases of the trap-app and trap-enc groups of the
PROTOS c06-snmpv1 testsuite.

Signed-off-by: Patrick McHardy 
Signed-off-by: Chris Wright

[PATCH] SCTP: Validate the parameter length in HB-ACK chunk (CVE-2006-1857)

2006-05-20T22:00:34+00:00

If SCTP receives a badly formatted HB-ACK chunk, it is possible
that we may access invalid memory and potentially have a buffer
overflow.  We should really make sure that the chunk format is
what we expect, before attempting to touch the data.

Signed-off-by: Vlad Yasevich 
Signed-off-by: Sridhar Samudrala 
Signed-off-by: Chris Wright

[PATCH] Netfilter: do_add_counters race, possible oops or info leak (CVE-2006-0039)

2006-05-20T22:00:31+00:00

Solar Designer found a race condition in do_add_counters(). The beginning
of paddc is supposed to be the same as tmp which was sanity-checked
above, but it might not be the same in reality. In case the integer
overflow and/or the race condition are triggered, paddc->num_counters
might not match the allocation size for paddc. If the check below
(t->private->number != paddc->num_counters) nevertheless passes (perhaps
this requires the race condition to be triggered), IPT_ENTRY_ITERATE()
would read kernel memory beyond the allocation size, potentially causing
an oops or leaking sensitive data (e.g., passwords from host system or
from another VPS) via counter increments.  This requires CAP_NET_ADMIN.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191698

Cc: Solar Designer 
Cc: Kirill Korotaev 
Cc: Patrick McHardy 
(chrisw: rebase of Kirill's patch to 2.6.16.16)
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] SCTP: Prevent possible infinite recursion with multiple bundled DATA. (CVE-2006-2274)

2006-05-09T19:53:21+00:00

There is a rare situation that causes lksctp to go into infinite recursion
and crash the system.  The trigger is a packet that contains at least the
first two DATA fragments of a message bundled together. The recursion is
triggered when the user data buffer is smaller that the full data message.
The problem is that we clone the skb for every fragment in the message.
When reassembling the full message, we try to link skbs from the "first
fragment" clone using the frag_list. However, since the frag_list is shared
between two clones in this rare situation, we end up setting the frag_list
pointer of the second fragment to point to itself.  This causes
sctp_skb_pull() to potentially recurse indefinitely.

Proposed solution is to make a copy of the skb when attempting to link
things using frag_list.

Signed-off-by: Vladislav Yasevich 
Signed-off-by: Sridhar Samudrala 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright

[PATCH] SCTP: Allow spillover of receive buffer to avoid deadlock. (CVE-2006-2275)

2006-05-09T19:53:21+00:00

This patch fixes a deadlock situation in the receive path by allowing
temporary spillover of the receive buffer.

- If the chunk we receive has a tsn that immediately follows the ctsn,
  accept it even if we run out of receive buffer space and renege data with
  higher TSNs.
- Once we accept one chunk in a packet, accept all the remaining chunks
  even if we run out of receive buffer space.

Signed-off-by: Neil Horman 
Acked-by: Mark Butler 
Acked-by: Vlad Yasevich 
Signed-off-by: Sridhar Samudrala 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright

[PATCH] SCTP: Fix state table entries for chunks received in CLOSED state. (CVE-2006-2271)

2006-05-09T19:53:20+00:00

Discard an unexpected chunk in CLOSED state rather can calling BUG().

Signed-off-by: Sridhar Samudrala 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright

[PATCH] SCTP: Fix panic's when receiving fragmented SCTP control chunks. (CVE-2006-2272)

2006-05-09T19:53:20+00:00

Use pskb_pull() to handle incoming COOKIE_ECHO and HEARTBEAT chunks that
are received as skb's with fragment list.

Signed-off-by: Sridhar Samudrala 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright