2.6.32.17-rc1 -stable review

2.6.32-stable review patch. If anyone has any objections, please let us know.

------------------

From: Andre Osterhues <[email protected]>

commit a6f80fb7b5986fda663d94079d3bba0937a6b6ff upstream.

The function ecryptfs_uid_hash wrongly assumes that the second parameter to hash_long() is the number of hash buckets instead of the number of hash bits. This patch fixes that and renames the variable ecryptfs_hash_buckets to ecryptfs_hash_bits to make it clearer.

---
 fs/ecryptfs/messaging.c |   17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

@@ -30,9 +30,9 @@ static struct mutex ecryptfs_msg_ctx_lis
 
 static struct hlist_head *ecryptfs_daemon_hash;
 struct mutex ecryptfs_daemon_hash_mux;
-static int ecryptfs_hash_buckets;
+static int ecryptfs_hash_bits;
 #define ecryptfs_uid_hash(uid) \
-        hash_long((unsigned long)uid, ecryptfs_hash_buckets)
+        hash_long((unsigned long)uid, ecryptfs_hash_bits)
 
 static u32 ecryptfs_msg_counter;
 static struct ecryptfs_msg_ctx *ecryptfs_msg_ctx_arr;

@@ -485,18 +485,19 @@ int ecryptfs_init_messaging(void)
 	}
 	mutex_init(&ecryptfs_daemon_hash_mux);
 	mutex_lock(&ecryptfs_daemon_hash_mux);
-	ecryptfs_hash_buckets = 1;
-	while (ecryptfs_number_of_users >> ecryptfs_hash_buckets)
-		ecryptfs_hash_buckets++;
+	ecryptfs_hash_bits = 1;
+	while (ecryptfs_number_of_users >> ecryptfs_hash_bits)
+		ecryptfs_hash_bits++;
 	ecryptfs_daemon_hash = kmalloc((sizeof(struct hlist_head)
-					* ecryptfs_hash_buckets), GFP_KERNEL);
+					* (1 << ecryptfs_hash_bits)),
+				       GFP_KERNEL);
 	if (!ecryptfs_daemon_hash) {
 		rc = -ENOMEM;
 		printk(KERN_ERR "%s: Failed to allocate memory\n", __func__);
 		mutex_unlock(&ecryptfs_daemon_hash_mux);
 		goto out;
 	}
-	for (i = 0; i < ecryptfs_hash_buckets; i++)
+	for (i = 0; i < (1 << ecryptfs_hash_bits); i++)
 		INIT_HLIST_HEAD(&ecryptfs_daemon_hash[i]);
 	mutex_unlock(&ecryptfs_daemon_hash_mux);
 	ecryptfs_msg_ctx_arr = kmalloc((sizeof(struct ecryptfs_msg_ctx)

@@ -553,7 +554,7 @@ void ecryptfs_release_messaging(void)
 		int i;
 
 		mutex_lock(&ecryptfs_daemon_hash_mux);
-		for (i = 0; i < ecryptfs_hash_buckets; i++) {
+		for (i = 0; i < (1 << ecryptfs_hash_bits); i++) {
 			int rc;
 
 			hlist_for_each_entry(daemon, elem,

2.6.32-stable review patch. If anyone has any objections, please let us know.

------------------

From: Bob Copeland <[email protected]>

commit b6855772f4a22c4fbdd4fcaceff5c8a527035123 upstream.

ath5k assumes ah_current_channel is always a valid pointer in several places, but a newly created interface may not have a channel. To avoid null pointer dereferences, set it up to point to the first available channel until later reconfigured.

This fixes the following oops:

$ rmmod ath5k
$ insmod ath5k
$ iw phy0 set distance 11000

BUG: unable to handle kernel NULL pointer dereference at 00000006
IP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k]
*pde = 00000000
Oops: 0000 [#1]
last sysfs file: /sys/devices/pci0000:00/0000:00:0e.0/ieee80211/phy0/index
Modules linked in: usbhid option usb_storage usbserial usblp evdev lm90

scx200_acb i2c_algo_bit i2c_dev i2c_core via_rhine ohci_hcd ne2k_pci 8390 leds_alix2 xt_IMQ imq nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_cc

Pid: 1597, comm: iw Not tainted (2.6.32.14 #8)
EIP: 0060:[<d0a1ff24>] EFLAGS: 00010296 CPU: 0
EIP is at ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k]
EAX: 000000c2 EBX: 00000000 ECX: ffffffff EDX: c12d2080
ESI: 00000019 EDI: cf8c0000 EBP: d0a30edc ESP: cfa09bf4
DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
Process iw (pid: 1597, ti=cfa09000 task=cf88a000 task.ti=cfa09000)

Stack:
  d0a34f35 d0a353f8 d0a30edc 000000fe cf8c0000 00000000 1900063d cfa8c9e0
<0> cfa8c9e8 cfa8c0c0 cfa8c000 d0a27f0c 199d84b4 cfa8c200 00000010 d09bfdc7
<0> 00000000 00000000 ffffffff d08e0d28 cf9263c0 00000001 cfa09cc4 00000000
Call Trace:
  [<d0a27f0c>] ? ath5k_hw_attach+0xc8c/0x3c10 [ath5k]
  [<d09bfdc7>] ? __ieee80211_request_smps+0x1347/0x1580 [mac80211]
  [<d08e0d28>] ? nl80211_send_scan_start+0x7b8/0x4520 [cfg80211]
  [<c10f5db9>] ? nla_parse+0x59/0xc0
  [<c11ca8d9>] ? genl_rcv_msg+0x169/0x1a0
  [<c11ca770>] ? genl_rcv_msg+0x0/0x1a0
  [<c11c7e68>] ? netlink_rcv_skb+0x38/0x90
  [<c11c9649>] ? genl_rcv+0x19/0x30
  [<c11c7c03>] ? netlink_unicast+0x1b3/0x220
  [<c11c893e>] ? netlink_sendmsg+0x26e/0x290
  [<c11a409e>] ? sock_sendmsg+0xbe/0xf0
  [<c1032780>] ? autoremove_wake_function+0x0/0x50
  [<c104d846>] ? __alloc_pages_nodemask+0x106/0x530
  [<c1074933>] ? do_lookup+0x53/0x1b0
  [<c10766f9>] ? __link_path_walk+0x9b9/0x9e0
  [<c11acab0>] ? verify_iovec+0x50/0x90
  [<c11a42b1>] ? sys_sendmsg+0x1e1/0x270
  [<c1048e50>] ? find_get_page+0x10/0x50
  [<c104a96f>] ? filemap_fault+0x5f/0x370
  [<c1059159>] ? __do_fault+0x319/0x370
  [<c11a55b4>] ? sys_socketcall+0x244/0x290
  [<c101962c>] ? do_page_fault+0x1ec/0x270
  [<c1019440>] ? do_page_fault+0x0/0x270
  [<c1002ae5>] ? syscall_call+0x7/0xb
Code: 00 b8 fe 00 00 00 b9 f8 53 a3 d0 89 5c 24 14 89 7c 24 10 89 44 24

0c 89 6c 24 08 89 4c 24 04 c7 04 24 35 4f a3 d0 e8 7c 30 60 f0 <0f> b7 43 06 ba 06 00 00 00 a8 10 75 0e 83 e0 20 83 f8 01 19 d2
EIP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] SS:ESP 0068:cfa09bf4
CR2: 0000000000000006

---[ end trace 54f73d6b10ceb87b ]---

---
 drivers/net/wireless/ath/ath5k/attach.c |    1 +
 1 file changed, 1 insertion(+)

@@ -133,6 +133,7 @@ struct ath5k_hw *ath5k_hw_attach(struct
 	ah->ah_cw_min = AR5K_TUNE_CWMIN;
 	ah->ah_limit_tx_retries = AR5K_INIT_TX_RETRY;
 	ah->ah_software_retry = false;
+	ah->ah_current_channel = &sc->channels[0];
 
 	/*
 	 * Find the mac version

2.6.32-stable review patch. If anyone has any objections, please let us know.

------------------

From: Dmitry Torokhov <[email protected]>

commit 2e65a2075cc740b485ab203430bdf3459d5551b6 upstream.

Commit 3fea60261e73 ("Input: twl40300-keypad - fix handling of "all ground" rows") broke compilation as I managed to use non-existent keycodes.

---
 arch/arm/mach-omap2/board-rx51-peripherals.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

@@ -82,10 +82,10 @@ static int board_keymap[] = {
 	KEY(4, 4, KEY_LEFTCTRL),
 	KEY(4, 5, KEY_RIGHTALT),
 	KEY(4, 6, KEY_LEFTSHIFT),
-	KEY(4, 8, KEY_10),
+	KEY(4, 8, KEY_F10),
 
 	KEY(5, 0, KEY_Y),
-	KEY(5, 8, KEY_11),
+	KEY(5, 8, KEY_F11),
 
 	KEY(6, 0, KEY_U),
 

2.6.32-stable review patch. If anyone has any objections, please let us know.

------------------

From: Daniel Ritz <[email protected]>

commit 68f194e027ecfbbc8d5515bc40787e542eed59e9 upstream.

For some unknown reason, on a MacBookPro5,3 the iSight sometimes report a different video format GUID. This patch add the other (wrong) GUID to the format table, making the iSight work always w/o other problems.

What it should report: 32595559-0000-0010-8000-00aa00389b71 What it often reports: 32595559-0000-0010-8000-000000389b71

---
 drivers/media/video/uvc/uvc_driver.c |    5 +++++
 drivers/media/video/uvc/uvcvideo.h   |    3 +++
 2 files changed, 8 insertions(+)

@@ -58,6 +58,11 @@ static struct uvc_format_desc uvc_fmts[]
 		.fcc		= V4L2_PIX_FMT_YUYV,
 	},
 	{
+		.name		= "YUV 4:2:2 (YUYV)",
+		.guid		= UVC_GUID_FORMAT_YUY2_ISIGHT,
+		.fcc		= V4L2_PIX_FMT_YUYV,
+	},
+	{
 		.name		= "YUV 4:2:0 (NV12)",
 		.guid		= UVC_GUID_FORMAT_NV12,
 		.fcc		= V4L2_PIX_FMT_NV12,

@@ -112,6 +112,9 @@ struct uvc_xu_control {
 #define UVC_GUID_FORMAT_YUY2 \
 	{ 'Y',  'U',  'Y',  '2', 0x00, 0x00, 0x10, 0x00, \
 	 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_YUY2_ISIGHT \
+	{ 'Y',  'U',  'Y',  '2', 0x00, 0x00, 0x10, 0x00, \
+	 0x80, 0x00, 0x00, 0x00, 0x00, 0x38, 0x9b, 0x71}
 #define UVC_GUID_FORMAT_NV12 \
 	{ 'N',  'V',  '1',  '2', 0x00, 0x00, 0x10, 0x00, \
 	 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}

I still don't see this one in 2.6.32-stable:

commit 1f5a81e41f8b1a782c68d3843e9ec1bfaadf7d72 upstream.
Subject: ext4: Make sure the MOVE_EXT ioctl can't overwrite append-only files

This fixes CVE-2010-2066; I'm pretty sure 2.6.32 is vulnerable.

Ick. I have 40+ ext4 patches already in this release, and here we didn't get one that really mattered :)

Ted, care to forward on the needed patch(s) to me?

thanks,

greg k-h