.32 patches

4 files changed, 118 insertions, 0 deletions

diff --git a/queue-2.6.32/b43-fix-beacon-problem-in-ad-hoc-mode.patch b/queue-2.6.32/b43-fix-beacon-problem-in-ad-hoc-mode.patch
new file mode 100644
index 0000000..9d28871
--- /dev/null
+++ b/queue-2.6.32/b43-fix-beacon-problem-in-ad-hoc-mode.patch
@@ -0,0 +1,33 @@
+From 8c23516fbb209ccf8f8c36268311c721faff29ee Mon Sep 17 00:00:00 2001
+From: Manual Munz <freifunk@somakoma.de>
+Date: Sun, 18 Sep 2011 18:24:03 -0500
+Subject: b43: Fix beacon problem in ad-hoc mode
+
+From: Manual Munz <freifunk@somakoma.de>
+
+commit 8c23516fbb209ccf8f8c36268311c721faff29ee upstream.
+
+In ad-hoc mode, driver b43 does not issue beacons.
+
+Signed-off-by: Manual Munz <freifunk@somakoma.de>
+Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
+Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/net/wireless/b43/main.c |    3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/b43/main.c
++++ b/drivers/net/wireless/b43/main.c
+@@ -1526,7 +1526,8 @@ static void handle_irq_beacon(struct b43
+ 	u32 cmd, beacon0_valid, beacon1_valid;
+ 
+ 	if (!b43_is_mode(wl, NL80211_IFTYPE_AP) &&
+-	    !b43_is_mode(wl, NL80211_IFTYPE_MESH_POINT))
++	    !b43_is_mode(wl, NL80211_IFTYPE_MESH_POINT) &&
++	    !b43_is_mode(wl, NL80211_IFTYPE_ADHOC))
+ 		return;
+ 
+ 	/* This is the bottom half of the asynchronous beacon update. */
diff --git a/queue-2.6.32/cifs-fix-possible-memory-corruption-in-cifsfindnext.patch b/queue-2.6.32/cifs-fix-possible-memory-corruption-in-cifsfindnext.patch
new file mode 100644
index 0000000..21abc31
--- /dev/null
+++ b/queue-2.6.32/cifs-fix-possible-memory-corruption-in-cifsfindnext.patch
@@ -0,0 +1,43 @@
+From 9438fabb73eb48055b58b89fc51e0bc4db22fabd Mon Sep 17 00:00:00 2001
+From: Jeff Layton <jlayton@redhat.com>
+Date: Tue, 23 Aug 2011 07:21:28 -0400
+Subject: cifs: fix possible memory corruption in CIFSFindNext
+
+From: Jeff Layton <jlayton@redhat.com>
+
+commit 9438fabb73eb48055b58b89fc51e0bc4db22fabd upstream.
+
+The name_len variable in CIFSFindNext is a signed int that gets set to
+the resume_name_len in the cifs_search_info. The resume_name_len however
+is unsigned and for some infolevels is populated directly from a 32 bit
+value sent by the server.
+
+If the server sends a very large value for this, then that value could
+look negative when converted to a signed int. That would make that
+value pass the PATH_MAX check later in CIFSFindNext. The name_len would
+then be used as a length value for a memcpy. It would then be treated
+as unsigned again, and the memcpy scribbles over a ton of memory.
+
+Fix this by making the name_len an unsigned value in CIFSFindNext.
+
+Reported-by: Darren Lavender <dcl@hppine99.gbr.hp.com>
+Signed-off-by: Jeff Layton <jlayton@redhat.com>
+Signed-off-by: Steve French <sfrench@us.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/cifs/cifssmb.c |    3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/fs/cifs/cifssmb.c
++++ b/fs/cifs/cifssmb.c
+@@ -3596,7 +3596,8 @@ int CIFSFindNext(const int xid, struct c
+ 	T2_FNEXT_RSP_PARMS *parms;
+ 	char *response_data;
+ 	int rc = 0;
+-	int bytes_returned, name_len;
++	int bytes_returned;
++	unsigned int name_len;
+ 	__u16 params, byte_count;
+ 
+ 	cFYI(1, ("In FindNext"));
diff --git a/queue-2.6.32/series b/queue-2.6.32/series
index 446500f..2bd26ff 100644
--- a/queue-2.6.32/series
+++ b/queue-2.6.32/series
@@ -26,3 +26,6 @@ e1000-fix-driver-to-be-used-on-pa-risc-c8000-workstations.patch
 asoc-fix-reporting-of-partial-jack-updates.patch
 alsa-hda-cirrus-fix-surround-speaker-volume-control-name.patch
 drm-radeon-kms-fix-typo-in-r100_blit_copy.patch
+cifs-fix-possible-memory-corruption-in-cifsfindnext.patch
+b43-fix-beacon-problem-in-ad-hoc-mode.patch
+wireless-reset-beacon_found-while-updating-regulatory.patch
diff --git a/queue-2.6.32/wireless-reset-beacon_found-while-updating-regulatory.patch b/queue-2.6.32/wireless-reset-beacon_found-while-updating-regulatory.patch
new file mode 100644
index 0000000..b1407a7
--- /dev/null
+++ b/queue-2.6.32/wireless-reset-beacon_found-while-updating-regulatory.patch
@@ -0,0 +1,39 @@
+From aa3d7eef398dd4f29045e9889b817d5161afe03e Mon Sep 17 00:00:00 2001
+From: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
+Date: Wed, 14 Sep 2011 14:28:17 +0530
+Subject: wireless: Reset beacon_found while updating regulatory
+
+From: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
+
+commit aa3d7eef398dd4f29045e9889b817d5161afe03e upstream.
+
+During the association, the regulatory is updated by country IE
+that reaps the previously found beacons. The impact is that
+after a STA disconnects *or* when for any reason a regulatory
+domain change happens the beacon hint flag is not cleared
+therefore preventing future beacon hints to be learned.
+This is important as a regulatory domain change or a restore
+of regulatory settings would set back the passive scan and no-ibss
+flags on the channel. This is the right place to do this given that
+it covers any regulatory domain change.
+
+Reviewed-by: Luis R. Rodriguez <mcgrof@gmail.com>
+Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
+Acked-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ net/wireless/reg.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/net/wireless/reg.c
++++ b/net/wireless/reg.c
+@@ -1023,6 +1023,7 @@ static void handle_channel(struct wiphy
+ 		return;
+ 	}
+ 
++	chan->beacon_found = false;
+ 	chan->flags = flags | bw_flags | map_regdom_flags(reg_rule->flags);
+ 	chan->max_antenna_gain = min(chan->orig_mag,
+ 		(int) MBI_TO_DBI(power_rule->max_antenna_gain));