<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/net/ipv4, branch v2.6.17.10</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>H.323 helper: fix possible NULL-ptr dereference</title>
<updated>2006-08-07T03:52:13+00:00</updated>
<author>
<name>Patrick McHardy</name>
<email>kaber@trash.net</email>
</author>
<published>2006-07-25T00:31:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=4f40508af128fc5ead71aab6e9932039d2a07fd4'/>
<id>4f40508af128fc5ead71aab6e9932039d2a07fd4</id>
<content type='text'>
[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 &lt;tdillig@stanford.edu&gt;
and Isil Dillig &lt;isil@stanford.edu&gt;.

Signed-off-by: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[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 &lt;tdillig@stanford.edu&gt;
and Isil Dillig &lt;isil@stanford.edu&gt;.

Signed-off-by: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Fix IPv4/DECnet routing rule dumping</title>
<updated>2006-07-25T03:35:27+00:00</updated>
<author>
<name>Patrick McHardy</name>
<email>kaber@trash.net</email>
</author>
<published>2006-07-08T20:39:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=1e8cd841d65774e96f5a52b0faa898b7ffebcece'/>
<id>1e8cd841d65774e96f5a52b0faa898b7ffebcece</id>
<content type='text'>
When more rules are present than fit in a single skb, the remaining
rules are incorrectly skipped.

Signed-off-by: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When more rules are present than fit in a single skb, the remaining
rules are incorrectly skipped.

Signed-off-by: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] NETFILTER: SCTP conntrack: fix crash triggered by packet without chunks [CVE-2006-2934]</title>
<updated>2006-06-30T17:37:31+00:00</updated>
<author>
<name>Patrick McHardy</name>
<email>kaber@trash.net</email>
</author>
<published>2006-06-30T03:33:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=9c48e1ea8cf8800cc5e2d39ccbb8b5ff9704f8e9'/>
<id>9c48e1ea8cf8800cc5e2d39ccbb8b5ff9704f8e9</id>
<content type='text'>
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 &lt;theall@tenablesecurity.com&gt;

Signed-off-by: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;theall@tenablesecurity.com&gt;

Signed-off-by: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[IPV4]: Increment ipInHdrErrors when TTL expires.</title>
<updated>2006-06-12T20:09:59+00:00</updated>
<author>
<name>Weidong</name>
<email>weid@nanjing-fnst.com</email>
</author>
<published>2006-06-12T20:09:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=42d1d52e695d87475846e9a09964cae1209eeecb'/>
<id>42d1d52e695d87475846e9a09964cae1209eeecb</id>
<content type='text'>
Signed-off-by: Weidong &lt;weid@nanjing-fnst.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Weidong &lt;weid@nanjing-fnst.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>[TCP]: continued: reno sacked_out count fix</title>
<updated>2006-06-12T04:18:56+00:00</updated>
<author>
<name>Aki M Nyrhinen</name>
<email>anyrhine@cs.helsinki.fi</email>
</author>
<published>2006-06-12T04:18:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=79320d7e14900c549c3520791a297328f53ff71e'/>
<id>79320d7e14900c549c3520791a297328f53ff71e</id>
<content type='text'>
From: Aki M Nyrhinen &lt;anyrhine@cs.helsinki.fi&gt;

IMHO the current fix to the problem (in_flight underflow in reno)
is incorrect.  it treats the symptons but ignores the problem. the
problem is timing out packets other than the head packet when we
don't have sack. i try to explain (sorry if explaining the obvious).

with sack, scanning the retransmit queue for timed out packets is
fine because we know which packets in our retransmit queue have been
acked by the receiver.

without sack, we know only how many packets in our retransmit queue the
receiver has acknowledged, but no idea which packets.

think of a "typical" slow-start overshoot case, where for example
every third packet in a window get lost because a router buffer gets
full.

with sack, we check for timeouts on those every third packet (as the
rest have been sacked). the packet counting works out and if there
is no reordering, we'll retransmit exactly the packets that were 
lost.

without sack, however, we check for timeout on every packet and end up
retransmitting consecutive packets in the retransmit queue. in our
slow-start example, 2/3 of those retransmissions are unnecessary. these
unnecessary retransmissions eat the congestion window and evetually
prevent fast recovery from continuing, if enough packets were lost.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
From: Aki M Nyrhinen &lt;anyrhine@cs.helsinki.fi&gt;

IMHO the current fix to the problem (in_flight underflow in reno)
is incorrect.  it treats the symptons but ignores the problem. the
problem is timing out packets other than the head packet when we
don't have sack. i try to explain (sorry if explaining the obvious).

with sack, scanning the retransmit queue for timed out packets is
fine because we know which packets in our retransmit queue have been
acked by the receiver.

without sack, we know only how many packets in our retransmit queue the
receiver has acknowledged, but no idea which packets.

think of a "typical" slow-start overshoot case, where for example
every third packet in a window get lost because a router buffer gets
full.

with sack, we check for timeouts on those every third packet (as the
rest have been sacked). the packet counting works out and if there
is no reordering, we'll retransmit exactly the packets that were 
lost.

without sack, however, we check for timeout on every packet and end up
retransmitting consecutive packets in the retransmit queue. in our
slow-start example, 2/3 of those retransmissions are unnecessary. these
unnecessary retransmissions eat the congestion window and evetually
prevent fast recovery from continuing, if enough packets were lost.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[TCP]: Avoid skb_pull if possible when trimming head</title>
<updated>2006-06-05T22:03:37+00:00</updated>
<author>
<name>Herbert Xu ~{PmVHI~}</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2006-06-05T22:03:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=f291196979ca80cdef199ca2b55e2758e8c23a0d'/>
<id>f291196979ca80cdef199ca2b55e2758e8c23a0d</id>
<content type='text'>
Trimming the head of an skb by calling skb_pull can cause the packet
to become unaligned if the length pulled is odd.  Since the length is
entirely arbitrary for a FIN packet carrying data, this is actually
quite common.

Unaligned data is not the end of the world, but we should avoid it if
it's easily done.  In this case it is trivial.  Since we're discarding
all of the head data it doesn't matter whether we move skb-&gt;data forward
or back.

However, it is still possible to have unaligned skb-&gt;data in general.
So network drivers should be prepared to handle it instead of crashing.

This patch also adds an unlikely marking on len &lt; headlen since partial
ACKs on head data are extremely rare in the wild.  As the return value
of __pskb_trim_head is no longer ever NULL that has been removed.

Signed-off-by: Herbert Xu ~{PmV&gt;HI~} &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Trimming the head of an skb by calling skb_pull can cause the packet
to become unaligned if the length pulled is odd.  Since the length is
entirely arbitrary for a FIN packet carrying data, this is actually
quite common.

Unaligned data is not the end of the world, but we should avoid it if
it's easily done.  In this case it is trivial.  Since we're discarding
all of the head data it doesn't matter whether we move skb-&gt;data forward
or back.

However, it is still possible to have unaligned skb-&gt;data in general.
So network drivers should be prepared to handle it instead of crashing.

This patch also adds an unlikely marking on len &lt; headlen since partial
ACKs on head data are extremely rare in the wild.  As the return value
of __pskb_trim_head is no longer ever NULL that has been removed.

Signed-off-by: Herbert Xu ~{PmV&gt;HI~} &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[TCP] tcp_highspeed: Fix problem observed by Xiaoliang (David) Wei</title>
<updated>2006-06-03T00:51:08+00:00</updated>
<author>
<name>Stephen Hemminger</name>
<email>shemminger@osdl.org</email>
</author>
<published>2006-06-03T00:51:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=fb80a6e1a521eb298edb4365429d533dd39427fa'/>
<id>fb80a6e1a521eb298edb4365429d533dd39427fa</id>
<content type='text'>
When snd_cwnd is smaller than 38 and the connection is in
congestion avoidance phase (snd_cwnd &gt; snd_ssthresh), the snd_cwnd
seems to stop growing.

The additive increase was confused because C array's are 0 based.

Signed-off-by: Stephen Hemminger &lt;shemminger@osdl.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When snd_cwnd is smaller than 38 and the connection is in
congestion avoidance phase (snd_cwnd &gt; snd_ssthresh), the snd_cwnd
seems to stop growing.

The additive increase was confused because C array's are 0 based.

Signed-off-by: Stephen Hemminger &lt;shemminger@osdl.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[NETFILTER]: PPTP helper: fix sstate/cstate typo</title>
<updated>2006-05-29T05:51:05+00:00</updated>
<author>
<name>Alexey Dobriyan</name>
<email>adobriyan@gmail.com</email>
</author>
<published>2006-05-29T05:51:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=7114b0bb6df7b2db266ba4847e4dd8333fa98a9a'/>
<id>7114b0bb6df7b2db266ba4847e4dd8333fa98a9a</id>
<content type='text'>
Signed-off-by: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Signed-off-by: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Signed-off-by: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[NETFILTER]: mark H.323 helper experimental</title>
<updated>2006-05-29T05:50:40+00:00</updated>
<author>
<name>Patrick McHardy</name>
<email>kaber@trash.net</email>
</author>
<published>2006-05-29T05:50:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=ca3ba88d0cf4b5d7a628caf505c231162dde9429'/>
<id>ca3ba88d0cf4b5d7a628caf505c231162dde9429</id>
<content type='text'>
Signed-off-by: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[NETFILTER]: Fix small information leak in SO_ORIGINAL_DST (CVE-2006-1343)</title>
<updated>2006-05-29T05:50:18+00:00</updated>
<author>
<name>Marcel Holtmann</name>
<email>marcel@holtmann.org</email>
</author>
<published>2006-05-29T05:50:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=6c813c3fe9e30fcf3c4d94d2ba24108babd745b0'/>
<id>6c813c3fe9e30fcf3c4d94d2ba24108babd745b0</id>
<content type='text'>
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 &lt;marcel@holtmann.org&gt;
Signed-off-by: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;marcel@holtmann.org&gt;
Signed-off-by: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
</feed>
