<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net, branch linux-2.6.29.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>mac80211: fix minstrel single-rate memory corruption</title>
<updated>2009-07-02T23:40:48+00:00</updated>
<author>
<name>Bob Copeland</name>
<email>me@bobcopeland.com</email>
</author>
<published>2009-06-05T12:21:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6e8ad8ea9d8c134f345ef3cca89c91aeadf2553e'/>
<id>6e8ad8ea9d8c134f345ef3cca89c91aeadf2553e</id>
<content type='text'>
commit 5ee58d7e6ad019675b4090582aec4fa1180d8703 upstream.

The minstrel rate controller periodically looks up rate indexes in
a sampling table.  When accessing a specific row and column, minstrel
correctly does a bounds check which, on the surface, appears to handle
the case where mi-&gt;n_rates &lt; 2.  However, mi-&gt;sample_idx is actually
defined as an unsigned, so the right hand side is taken to be a huge
positive number when negative, and the check will always fail.

Consequently, the RC will overrun the array and cause random memory
corruption when communicating with a peer that has only a single rate.
The max value of mi-&gt;sample_idx is around 25 so casting to int should
have no ill effects.

Without the change, uptime is a few minutes under load with an AP
that has a single hard-coded rate, and both the AP and STA could
potentially crash.  With the change, both lasted 12 hours with a
steady load.

Thanks to Ognjen Maric for providing the single-rate clue so I could
reproduce this.

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=12490 on the
regression list (also http://bugzilla.kernel.org/show_bug.cgi?id=13000).

Reported-by: Sergey S. Kostyliov &lt;rathamahata@gmail.com&gt;
Reported-by: Ognjen Maric &lt;ognjen.maric@gmail.com&gt;
Signed-off-by: Bob Copeland &lt;me@bobcopeland.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&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>
commit 5ee58d7e6ad019675b4090582aec4fa1180d8703 upstream.

The minstrel rate controller periodically looks up rate indexes in
a sampling table.  When accessing a specific row and column, minstrel
correctly does a bounds check which, on the surface, appears to handle
the case where mi-&gt;n_rates &lt; 2.  However, mi-&gt;sample_idx is actually
defined as an unsigned, so the right hand side is taken to be a huge
positive number when negative, and the check will always fail.

Consequently, the RC will overrun the array and cause random memory
corruption when communicating with a peer that has only a single rate.
The max value of mi-&gt;sample_idx is around 25 so casting to int should
have no ill effects.

Without the change, uptime is a few minutes under load with an AP
that has a single hard-coded rate, and both the AP and STA could
potentially crash.  With the change, both lasted 12 hours with a
steady load.

Thanks to Ognjen Maric for providing the single-rate clue so I could
reproduce this.

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=12490 on the
regression list (also http://bugzilla.kernel.org/show_bug.cgi?id=13000).

Reported-by: Sergey S. Kostyliov &lt;rathamahata@gmail.com&gt;
Reported-by: Ognjen Maric &lt;ognjen.maric@gmail.com&gt;
Signed-off-by: Bob Copeland &lt;me@bobcopeland.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: avoid NULL ptr deref when finding max_rates in PID and minstrel</title>
<updated>2009-06-15T16:40:12+00:00</updated>
<author>
<name>John W. Linville</name>
<email>linville@tuxdriver.com</email>
</author>
<published>2009-05-05T19:18:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=56009774704b0cf6052466b82300b4cdd5ccc855'/>
<id>56009774704b0cf6052466b82300b4cdd5ccc855</id>
<content type='text'>
commit 621ad7c96aa138cfeab53cd4debc5a4e08b2189b upstream.

"There is another problem with this piece of code. The sband will be NULL
after second iteration on single band device and cause null pointer
dereference. Everything is working with dual band card. Sorry, but i
don't know how to explain this clearly in English. I have looked on the
second patch for pid algorithm and found similar bug."

Reported-by: Karol Szuster &lt;qflon@o2.pl&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&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>
commit 621ad7c96aa138cfeab53cd4debc5a4e08b2189b upstream.

"There is another problem with this piece of code. The sband will be NULL
after second iteration on single band device and cause null pointer
dereference. Everything is working with dual band card. Sorry, but i
don't know how to explain this clearly in English. I have looked on the
second patch for pid algorithm and found similar bug."

Reported-by: Karol Szuster &lt;qflon@o2.pl&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: pid, fix memory corruption</title>
<updated>2009-06-15T16:40:12+00:00</updated>
<author>
<name>Jiri Slaby</name>
<email>jirislaby@gmail.com</email>
</author>
<published>2009-05-04T16:10:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=94a9ef2fbeed9360a2036fcc79873dcf9ab7acf3'/>
<id>94a9ef2fbeed9360a2036fcc79873dcf9ab7acf3</id>
<content type='text'>
commit 6909268dc93ae4b0b8e1ebb4b2fa70b1a47dd347 upstream.

pid doesn't count with some band having more bitrates than the one
associated the first time.
Fix that by counting the maximal available bitrate count and allocate
big enough space.

Secondly, fix touching uninitialized memory which causes panics.
Index sucked from this random memory points to the hell.
The fix is to sort the rates on each band change.

Signed-off-by: Jiri Slaby &lt;jirislaby@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&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>
commit 6909268dc93ae4b0b8e1ebb4b2fa70b1a47dd347 upstream.

pid doesn't count with some band having more bitrates than the one
associated the first time.
Fix that by counting the maximal available bitrate count and allocate
big enough space.

Secondly, fix touching uninitialized memory which causes panics.
Index sucked from this random memory points to the hell.
The fix is to sort the rates on each band change.

Signed-off-by: Jiri Slaby &lt;jirislaby@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: minstrel, fix memory corruption</title>
<updated>2009-06-15T16:40:12+00:00</updated>
<author>
<name>Jiri Slaby</name>
<email>jirislaby@gmail.com</email>
</author>
<published>2009-05-04T16:04:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5a28cafbab1d07e4161f00678b6a45620a2c2e4f'/>
<id>5a28cafbab1d07e4161f00678b6a45620a2c2e4f</id>
<content type='text'>
commit 8e532175277d9a5eae49768ed086555081f741a7 upstream.

minstrel doesn't count max rate count in fact, since it doesn't use
a loop variable `i' and hence allocs space only for bitrates found in
the first band.

Fix it by involving the `i' as an index so that it traverses all the
bands now and finds the real max bitrate count.

Signed-off-by: Jiri Slaby &lt;jirislaby@gmail.com&gt;
Cc: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&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>
commit 8e532175277d9a5eae49768ed086555081f741a7 upstream.

minstrel doesn't count max rate count in fact, since it doesn't use
a loop variable `i' and hence allocs space only for bitrates found in
the first band.

Fix it by involving the `i' as an index so that it traverses all the
bands now and finds the real max bitrate count.

Signed-off-by: Jiri Slaby &lt;jirislaby@gmail.com&gt;
Cc: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: fix race between core hint and driver's custom apply</title>
<updated>2009-06-15T16:40:02+00:00</updated>
<author>
<name>Luis R. Rodriguez</name>
<email>lrodriguez@atheros.com</email>
</author>
<published>2009-05-13T21:04:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c1cc5093ab054f5d2c4942d3f5b0bf7b106ce975'/>
<id>c1cc5093ab054f5d2c4942d3f5b0bf7b106ce975</id>
<content type='text'>
commit 5078b2e32ad4b1f753b1c837c15892202f753c97 upstream.

Its possible for cfg80211 to have scheduled the work and for
the global workqueue to not have kicked in prior to a cfg80211
driver's regulatory hint or wiphy_apply_custom_regulatory().

Although this is very unlikely its possible and should fix
this race. When this race would happen you are expected to have
hit a null pointer dereference panic.

Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.com&gt;
Tested-by: Alan Jenkins &lt;alan-jenkins@tuffmail.co.uk&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&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>
commit 5078b2e32ad4b1f753b1c837c15892202f753c97 upstream.

Its possible for cfg80211 to have scheduled the work and for
the global workqueue to not have kicked in prior to a cfg80211
driver's regulatory hint or wiphy_apply_custom_regulatory().

Although this is very unlikely its possible and should fix
this race. When this race would happen you are expected to have
hit a null pointer dereference panic.

Signed-off-by: Luis R. Rodriguez &lt;lrodriguez@atheros.com&gt;
Tested-by: Alan Jenkins &lt;alan-jenkins@tuffmail.co.uk&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>wimax: fix oops if netlink fails to add attribute</title>
<updated>2009-06-15T16:39:58+00:00</updated>
<author>
<name>Inaky Perez-Gonzalez</name>
<email>inaky@linux.intel.com</email>
</author>
<published>2009-03-31T00:50:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7e3ab8deaa79f69dc99ce624f3cc857e746d62d4'/>
<id>7e3ab8deaa79f69dc99ce624f3cc857e746d62d4</id>
<content type='text'>
commit d1a2627a29667fe7c4a9d06e1579a2d65bd39bba upstream.

When sending a message to user space using wimax_msg(), if nla_put()
fails, correctly interpret the return code from wimax_msg_alloc() as
an err ptr and return the error code instead of crashing (as it is
assuming than non-NULL means the pointer is ok).

Signed-off-by: Inaky Perez-Gonzalez &lt;inaky@linux.intel.com&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>
commit d1a2627a29667fe7c4a9d06e1579a2d65bd39bba upstream.

When sending a message to user space using wimax_msg(), if nla_put()
fails, correctly interpret the return code from wimax_msg_alloc() as
an err ptr and return the error code instead of crashing (as it is
assuming than non-NULL means the pointer is ok).

Signed-off-by: Inaky Perez-Gonzalez &lt;inaky@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>vlan/macvlan: fix NULL pointer dereferences in ethtool handlers</title>
<updated>2009-06-15T16:39:54+00:00</updated>
<author>
<name>Patrick McHardy</name>
<email>kaber@trash.net</email>
</author>
<published>2009-04-17T22:59:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=11f9c95f05a392a3f58362447197a1d1bc5302c7'/>
<id>11f9c95f05a392a3f58362447197a1d1bc5302c7</id>
<content type='text'>
[ Upstream commit 7816a0a862d851d0b05710e7d94bfe390f3180e2 ]

Check whether the underlying device provides a set of ethtool ops before
checking for individual handlers to avoid NULL pointer dereferences.

Reported-by: Art van Breemen &lt;ard@telegraafnet.nl&gt;
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>
[ Upstream commit 7816a0a862d851d0b05710e7d94bfe390f3180e2 ]

Check whether the underlying device provides a set of ethtool ops before
checking for individual handlers to avoid NULL pointer dereferences.

Reported-by: Art van Breemen &lt;ard@telegraafnet.nl&gt;
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>pktgen: do not access flows[] beyond its length</title>
<updated>2009-06-15T16:39:53+00:00</updated>
<author>
<name>Florian Westphal</name>
<email>fw@strlen.de</email>
</author>
<published>2009-05-21T22:07:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=94c571ca297247524159f6b045cd82beb6312876'/>
<id>94c571ca297247524159f6b045cd82beb6312876</id>
<content type='text'>
[ Upstream commit 5b5f792a6a9a2f9ae812d151ed621f72e99b1725 ]

typo -- pkt_dev-&gt;nflows is for stats only, the number of concurrent
flows is stored in cflows.

Reported-By: Vladimir Ivashchenko &lt;hazard@francoudi.com&gt;
Signed-off-by: Florian Westphal &lt;fw@strlen.de&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>
[ Upstream commit 5b5f792a6a9a2f9ae812d151ed621f72e99b1725 ]

typo -- pkt_dev-&gt;nflows is for stats only, the number of concurrent
flows is stored in cflows.

Reported-By: Vladimir Ivashchenko &lt;hazard@francoudi.com&gt;
Signed-off-by: Florian Westphal &lt;fw@strlen.de&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>Revert "rose: zero length frame filtering in af_rose.c"</title>
<updated>2009-06-15T16:39:52+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2009-04-15T03:28:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c930a1bcf48a0ba7350c224071455afcb9da0882'/>
<id>c930a1bcf48a0ba7350c224071455afcb9da0882</id>
<content type='text'>
[ Upstream commit 6fd4777a1fec1f7757b5a302ad3fdcc1eae2abba ]

This reverts commit 244f46ae6e9e18f6fc0be7d1f49febde4762c34b.

Alan Cox did the research, and just like the other radio protocols
zero-length frames have meaning because at the top level ROSE is
X.25 PLP.

So this zero-length filtering is invalid.

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>
[ Upstream commit 6fd4777a1fec1f7757b5a302ad3fdcc1eae2abba ]

This reverts commit 244f46ae6e9e18f6fc0be7d1f49febde4762c34b.

Alan Cox did the research, and just like the other radio protocols
zero-length frames have meaning because at the top level ROSE is
X.25 PLP.

So this zero-length filtering is invalid.

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>net: fix rtable leak in net/ipv4/route.c</title>
<updated>2009-06-15T16:39:52+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>dada1@cosmosbay.com</email>
</author>
<published>2009-05-19T20:14:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=224db0799320b9ad875e4115ad16ee64f44a2fea'/>
<id>224db0799320b9ad875e4115ad16ee64f44a2fea</id>
<content type='text'>
[ Upstream commit 1ddbcb005c395518c2cd0df504cff3d4b5c85853 ]

Alexander V. Lukyanov found a regression in 2.6.29 and made a complete
analysis found in http://bugzilla.kernel.org/show_bug.cgi?id=13339
Quoted here because its a perfect one :

begin_of_quotation
 2.6.29 patch has introduced flexible route cache rebuilding. Unfortunately the
 patch has at least one critical flaw, and another problem.

 rt_intern_hash calculates rthi pointer, which is later used for new entry
 insertion. The same loop calculates cand pointer which is used to clean the
 list. If the pointers are the same, rtable leak occurs, as first the cand is
 removed then the new entry is appended to it.

 This leak leads to unregister_netdevice problem (usage count &gt; 0).

 Another problem of the patch is that it tries to insert the entries in certain
 order, to facilitate counting of entries distinct by all but QoS parameters.
 Unfortunately, referencing an existing rtable entry moves it to list beginning,
 to speed up further lookups, so the carefully built order is destroyed.

 For the first problem the simplest patch it to set rthi=0 when rthi==cand, but
 it will also destroy the ordering.
end_of_quotation

Problematic commit is 1080d709fb9d8cd4392f93476ee46a9d6ea05a5b
(net: implement emergency route cache rebulds when gc_elasticity is exceeded)

Trying to keep dst_entries ordered is too complex and breaks the fact that
order should depend on the frequency of use for garbage collection.

A possible fix is to make rt_intern_hash() simpler, and only makes
rt_check_expire() a litle bit smarter, being able to cope with an arbitrary
entries order. The added loop is running on cache hot data, while cpu
is prefetching next object, so should be unnoticied.

Reported-and-analyzed-by: Alexander V. Lukyanov &lt;lav@yar.ru&gt;
Signed-off-by: Eric Dumazet &lt;dada1@cosmosbay.com&gt;
Acked-by: Neil Horman &lt;nhorman@tuxdriver.com&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>
[ Upstream commit 1ddbcb005c395518c2cd0df504cff3d4b5c85853 ]

Alexander V. Lukyanov found a regression in 2.6.29 and made a complete
analysis found in http://bugzilla.kernel.org/show_bug.cgi?id=13339
Quoted here because its a perfect one :

begin_of_quotation
 2.6.29 patch has introduced flexible route cache rebuilding. Unfortunately the
 patch has at least one critical flaw, and another problem.

 rt_intern_hash calculates rthi pointer, which is later used for new entry
 insertion. The same loop calculates cand pointer which is used to clean the
 list. If the pointers are the same, rtable leak occurs, as first the cand is
 removed then the new entry is appended to it.

 This leak leads to unregister_netdevice problem (usage count &gt; 0).

 Another problem of the patch is that it tries to insert the entries in certain
 order, to facilitate counting of entries distinct by all but QoS parameters.
 Unfortunately, referencing an existing rtable entry moves it to list beginning,
 to speed up further lookups, so the carefully built order is destroyed.

 For the first problem the simplest patch it to set rthi=0 when rthi==cand, but
 it will also destroy the ordering.
end_of_quotation

Problematic commit is 1080d709fb9d8cd4392f93476ee46a9d6ea05a5b
(net: implement emergency route cache rebulds when gc_elasticity is exceeded)

Trying to keep dst_entries ordered is too complex and breaks the fact that
order should depend on the frequency of use for garbage collection.

A possible fix is to make rt_intern_hash() simpler, and only makes
rt_check_expire() a litle bit smarter, being able to cope with an arbitrary
entries order. The added loop is running on cache hot data, while cpu
is prefetching next object, so should be unnoticied.

Reported-and-analyzed-by: Alexander V. Lukyanov &lt;lav@yar.ru&gt;
Signed-off-by: Eric Dumazet &lt;dada1@cosmosbay.com&gt;
Acked-by: Neil Horman &lt;nhorman@tuxdriver.com&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>
</feed>
