[01/17] aio: check for multiplication overflow in do_io_submit

[01/17] aio: check for multiplication overflow in do_io_submit

[Greg KH]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1467 bytes --]

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

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

From: Jeff Moyer <jmoyer@redhat.com>

commit 75e1c70fc31490ef8a373ea2a4bea2524099b478 upstream.

Tavis Ormandy pointed out that do_io_submit does not do proper bounds
checking on the passed-in iocb array:

       if (unlikely(nr < 0))
               return -EINVAL;

       if (unlikely(!access_ok(VERIFY_READ, iocbpp, (nr*sizeof(iocbpp)))))
               return -EFAULT;                      ^^^^^^^^^^^^^^^^^^

The attached patch checks for overflow, and if it is detected, the
number of iocbs submitted is scaled down to a number that will fit in
the long.  This is an ok thing to do, as sys_io_submit is documented as
returning the number of iocbs submitted, so callers should handle a
return value of less than the 'nr' argument passed in.

Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com>
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/aio.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1677,6 +1677,9 @@ SYSCALL_DEFINE3(io_submit, aio_context_t
 	if (unlikely(nr < 0))
 		return -EINVAL;
 
+	if (unlikely(nr > LONG_MAX/sizeof(*iocbpp)))
+		nr = LONG_MAX/sizeof(*iocbpp);
+
 	if (unlikely(!access_ok(VERIFY_READ, iocbpp, (nr*sizeof(*iocbpp)))))
 		return -EFAULT;
 

[02/17] guard page for stacks that grow upwards

[Greg KH]

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

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

From: Luck, Tony <tony.luck@intel.com>

commit 8ca3eb08097f6839b2206e2242db4179aee3cfb3 upstream.

pa-risc and ia64 have stacks that grow upwards. Check that
they do not run into other mappings. By making VM_GROWSUP
0x0 on architectures that do not ever use it, we can avoid
some unpleasant #ifdefs in check_stack_guard_page().

Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: dann frazier <dannf@debian.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 include/linux/mm.h |    8 +++++++-
 mm/memory.c        |   15 +++++++++++----
 mm/mmap.c          |    3 ---
 3 files changed, 18 insertions(+), 8 deletions(-)

--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -87,7 +87,11 @@ extern unsigned int kobjsize(const void
 #define VM_MAYSHARE	0x00000080
 
 #define VM_GROWSDOWN	0x00000100	/* general info on the segment */
+#if defined(CONFIG_STACK_GROWSUP) || defined(CONFIG_IA64)
 #define VM_GROWSUP	0x00000200
+#else
+#define VM_GROWSUP	0x00000000
+#endif
 #define VM_PFNMAP	0x00000400	/* Page-ranges managed without "struct page", just pure PFN */
 #define VM_DENYWRITE	0x00000800	/* ETXTBSY on write attempts.. */
 
@@ -1181,8 +1185,10 @@ unsigned long max_sane_readahead(unsigne
 
 /* Do stack extension */
 extern int expand_stack(struct vm_area_struct *vma, unsigned long address);
-#ifdef CONFIG_IA64
+#if VM_GROWSUP
 extern int expand_upwards(struct vm_area_struct *vma, unsigned long address);
+#else
+  #define expand_upwards(vma, address) do { } while (0)
 #endif
 extern int expand_stack_downwards(struct vm_area_struct *vma,
 				  unsigned long address);
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2396,11 +2396,9 @@ out_nomap:
 }
 
 /*
- * This is like a special single-page "expand_downwards()",
- * except we must first make sure that 'address-PAGE_SIZE'
+ * This is like a special single-page "expand_{down|up}wards()",
+ * except we must first make sure that 'address{-|+}PAGE_SIZE'
  * doesn't hit another vma.
- *
- * The "find_vma()" will do the right thing even if we wrap
  */
 static inline int check_stack_guard_page(struct vm_area_struct *vma, unsigned long address)
 {
@@ -2412,6 +2410,15 @@ static inline int check_stack_guard_page
 
 		expand_stack(vma, address);
 	}
+	if ((vma->vm_flags & VM_GROWSUP) && address + PAGE_SIZE == vma->vm_end) {
+		struct vm_area_struct *next = vma->vm_next;
+
+		/* As VM_GROWSDOWN but s/below/above/ */
+		if (next && next->vm_start == address + PAGE_SIZE)
+			return next->vm_flags & VM_GROWSUP ? 0 : -ENOMEM;
+
+		expand_upwards(vma, address + PAGE_SIZE);
+	}
 	return 0;
 }
 
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1589,9 +1589,6 @@ static int acct_stack_growth(struct vm_a
  * PA-RISC uses this for its stack; IA64 for its Register Backing Store.
  * vma is the last one with address > vma->vm_end.  Have to extend vma.
  */
-#ifndef CONFIG_IA64
-static inline
-#endif
 int expand_upwards(struct vm_area_struct *vma, unsigned long address)
 {
 	int error;

[03/17] ALSA: sound/pci/rme9652: prevent reading uninitialized stack memory

[Greg KH]

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

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

From: Dan Rosenberg <drosenberg@vsecurity.com>

commit e68d3b316ab7b02a074edc4f770e6a746390cb7d upstream.

The SNDRV_HDSP_IOCTL_GET_CONFIG_INFO and
SNDRV_HDSP_IOCTL_GET_CONFIG_INFO ioctls in hdspm.c and hdsp.c allow
unprivileged users to read uninitialized kernel stack memory, because
several fields of the hdsp{m}_config_info structs declared on the stack
are not altered or zeroed before being copied back to the user.  This
patch takes care of it.

Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 sound/pci/rme9652/hdsp.c  |    1 +
 sound/pci/rme9652/hdspm.c |    1 +
 2 files changed, 2 insertions(+)

--- a/sound/pci/rme9652/hdsp.c
+++ b/sound/pci/rme9652/hdsp.c
@@ -4569,6 +4569,7 @@ static int snd_hdsp_hwdep_ioctl(struct s
 			snd_printk(KERN_ERR "Hammerfall-DSP: Firmware needs to be uploaded to the card.\n");	
 			return -EINVAL;
 		}
+		memset(&info, 0, sizeof(info));
 		spin_lock_irqsave(&hdsp->lock, flags);
 		info.pref_sync_ref = (unsigned char)hdsp_pref_sync_ref(hdsp);
 		info.wordclock_sync_check = (unsigned char)hdsp_wc_sync_check(hdsp);
--- a/sound/pci/rme9652/hdspm.c
+++ b/sound/pci/rme9652/hdspm.c
@@ -4133,6 +4133,7 @@ static int snd_hdspm_hwdep_ioctl(struct
 
 	case SNDRV_HDSPM_IOCTL_GET_CONFIG_INFO:
 
+		memset(&info, 0, sizeof(info));
 		spin_lock_irq(&hdspm->lock);
 		info.pref_sync_ref = hdspm_pref_sync_ref(hdspm);
 		info.wordclock_sync_check = hdspm_wc_sync_check(hdspm);

[04/17] ALSA: prevent heap corruption in snd_ctl_new()

[Greg KH]

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

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

From: Dan Rosenberg <drosenberg@vsecurity.com>

commit 5591bf07225523600450edd9e6ad258bb877b779 upstream.

The snd_ctl_new() function in sound/core/control.c allocates space for a
snd_kcontrol struct by performing arithmetic operations on a
user-provided size without checking for integer overflow.  If a user
provides a large enough size, an overflow will occur, the allocated
chunk will be too small, and a second user-influenced value will be
written repeatedly past the bounds of this chunk.  This code is
reachable by unprivileged users who have permission to open
a /dev/snd/controlC* device (on many distros, this is group "audio") via
the SNDRV_CTL_IOCTL_ELEM_ADD and SNDRV_CTL_IOCTL_ELEM_REPLACE ioctls.

Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 sound/core/control.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/sound/core/control.c
+++ b/sound/core/control.c
@@ -31,6 +31,7 @@
 
 /* max number of user-defined controls */
 #define MAX_USER_CONTROLS	32
+#define MAX_CONTROL_COUNT	1028
 
 struct snd_kctl_ioctl {
 	struct list_head list;		/* list of all ioctls */
@@ -190,6 +191,8 @@ static struct snd_kcontrol *snd_ctl_new(
 	
 	snd_assert(control != NULL, return NULL);
 	snd_assert(control->count > 0, return NULL);
+	if (control->count > MAX_CONTROL_COUNT)
+		return NULL;
 	kctl = kzalloc(sizeof(*kctl) + sizeof(struct snd_kcontrol_volatile) * control->count, GFP_KERNEL);
 	if (kctl == NULL) {
 		snd_printk(KERN_ERR "Cannot allocate control instance\n");

[05/17] v4l1: fix 32-bit compat microcode loading translation

[Greg KH]

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

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

From: Linus Torvalds <torvalds@linux-foundation.org>

commit 3e645d6b485446c54c6745c5e2cf5c528fe4deec upstream.

The compat code for the VIDIOCSMICROCODE ioctl is totally buggered.
It's only used by the VIDEO_STRADIS driver, and that one is scheduled to
staging and eventually removed unless somebody steps up to maintain it
(at which point it should use request_firmware() rather than some magic
ioctl).  So we'll get rid of it eventually.

But in the meantime, the compatibility ioctl code is broken, and this
tries to get it to at least limp along (even if Mauro suggested just
deleting it entirely, which may be the right thing to do - I don't think
the compatibility translation code has ever worked unless you were very
lucky).

Reported-by: Kees Cook <kees.cook@canonical.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/video/compat_ioctl32.c |   32 +++++++++++++++++++++-----------
 1 file changed, 21 insertions(+), 11 deletions(-)

--- a/drivers/media/video/compat_ioctl32.c
+++ b/drivers/media/video/compat_ioctl32.c
@@ -499,17 +499,24 @@ struct video_code32
 {
 	char		loadwhat[16];	/* name or tag of file being passed */
 	compat_int_t	datasize;
-	unsigned char	*data;
+	compat_uptr_t	data;
 };
 
-static inline int microcode32(struct video_code *kp, struct video_code32 __user *up)
+static struct video_code __user *get_microcode32(struct video_code32 *kp)
 {
-	if(!access_ok(VERIFY_READ, up, sizeof(struct video_code32)) ||
-		copy_from_user(kp->loadwhat, up->loadwhat, sizeof (up->loadwhat)) ||
-		get_user(kp->datasize, &up->datasize) ||
-		copy_from_user(kp->data, up->data, up->datasize))
-			return -EFAULT;
-	return 0;
+	struct video_code __user *up;
+
+	up = compat_alloc_user_space(sizeof(*up));
+
+	/*
+	 * NOTE! We don't actually care if these fail. If the
+	 * user address is invalid, the native ioctl will do
+	 * the error handling for us
+	 */
+	(void) copy_to_user(up->loadwhat, kp->loadwhat, sizeof(up->loadwhat));
+	(void) put_user(kp->datasize, &up->datasize);
+	(void) put_user(compat_ptr(kp->data), &up->data);
+	return up;
 }
 
 #define VIDIOCGTUNER32		_IOWR('v',4, struct video_tuner32)
@@ -618,7 +625,7 @@ static int do_video_ioctl(struct file *f
 		struct video_tuner vt;
 		struct video_buffer vb;
 		struct video_window vw;
-		struct video_code vc;
+		struct video_code32 vc;
 		struct video_audio va;
 #endif
 		struct v4l2_format v2f;
@@ -745,8 +752,11 @@ static int do_video_ioctl(struct file *f
 		break;
 #ifdef CONFIG_VIDEO_V4L1_COMPAT
 	case VIDIOCSMICROCODE:
-		err = microcode32(&karg.vc, up);
-		compatible_arg = 0;
+		/* Copy the 32-bit "video_code32" to kernel space */
+		if (copy_from_user(&karg.vc, up, sizeof(karg.vc)))
+			return -EFAULT;
+		/* Convert the 32-bit version to a 64-bit version in user space */
+		up = get_microcode32(&karg.vc);
 		break;
 #endif
 	};

[06/17] dmaengine: fix interrupt clearing for mv_xor

[Greg KH]

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

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

From: Simon Guinot <sguinot@lacie.com>

commit cc60f8878eab892c03d06b10f389232b9b66bd83 upstream.

When using simultaneously the two DMA channels on a same engine, some
transfers are never completed. For example, an endless lock can occur
while writing heavily on a RAID5 array (with async-tx offload support
enabled).

Note that this issue can also be reproduced by using the DMA test
client.

On a same engine, the interrupt cause register is shared between two
DMA channels. This patch make sure that the cause bit is only cleared
for the requested channel.

Signed-off-by: Simon Guinot <sguinot@lacie.com>
Tested-by: Luc Saillard <luc@saillard.org>
Acked-by: saeed bishara <saeed.bishara@gmail.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/dma/mv_xor.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -162,7 +162,7 @@ static int mv_is_err_intr(u32 intr_cause
 
 static void mv_xor_device_clear_eoc_cause(struct mv_xor_chan *chan)
 {
-	u32 val = (1 << (1 + (chan->idx * 16)));
+	u32 val = ~(1 << (chan->idx * 16));
 	dev_dbg(chan->device->common.dev, "%s, val 0x%08x\n", __func__, val);
 	__raw_writel(val, XOR_INTR_CAUSE(chan));
 }

[07/17] wext: fix potential private ioctl memory content leak

[Greg KH]

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

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

From: Johannes Berg <johannes.berg@intel.com>

commit df6d02300f7c2fbd0fbe626d819c8e5237d72c62 upstream.

When a driver doesn't fill the entire buffer, old
heap contents may remain, and if it also doesn't
update the length properly, this old heap content
will be copied back to userspace.

It is very unlikely that this happens in any of
the drivers using private ioctls since it would
show up as junk being reported by iwpriv, but it
seems better to be safe here, so use kzalloc.

Reported-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/wireless/wext.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/wireless/wext.c
+++ b/net/wireless/wext.c
@@ -947,7 +947,7 @@ static int ioctl_private_iw_point(struct
 	} else if (!iwp->pointer)
 		return -EFAULT;
 
-	extra = kmalloc(extra_size, GFP_KERNEL);
+	extra = kzalloc(extra_size, GFP_KERNEL);
 	if (!extra)
 		return -ENOMEM;
 

[08/17] atl1: fix resume

[Greg KH]

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

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

From: Luca Tettamanti <kronos.it@gmail.com>

commit ec5a32f67c603b11d68eb283d94eb89a4f6cfce1 upstream.

adapter->cmb.cmb is initialized when the device is opened and freed when
it's closed. Accessing it unconditionally during resume results either
in a crash (NULL pointer dereference, when the interface has not been
opened yet) or data corruption (when the interface has been used and
brought down adapter->cmb.cmb points to a deallocated memory area).

Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
Acked-by: Chris Snook <chris.snook@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/atlx/atl1.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/net/atlx/atl1.c
+++ b/drivers/net/atlx/atl1.c
@@ -2881,10 +2881,11 @@ static int atl1_resume(struct pci_dev *p
 	pci_enable_wake(pdev, PCI_D3cold, 0);
 
 	atl1_reset_hw(&adapter->hw);
-	adapter->cmb.cmb->int_stats = 0;
 
-	if (netif_running(netdev))
+	if (netif_running(netdev)) {
+		adapter->cmb.cmb->int_stats = 0;
 		atl1_up(adapter);
+	}
 	netif_device_attach(netdev);
 
 	return 0;

[09/17] [SCSI] bsg: fix incorrect device_status value

[Greg KH]

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

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

From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>

commit 478971600e47cb83ff2d3c63c5c24f2b04b0d6a1 upstream.

bsg incorrectly returns sg's masked_status value for device_status.

[jejb: fix up expression logic]
Reported-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 block/bsg.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/block/bsg.c
+++ b/block/bsg.c
@@ -421,7 +421,7 @@ static int blk_complete_sgv4_hdr_rq(stru
 	/*
 	 * fill in all the output members
 	 */
-	hdr->device_status = status_byte(rq->errors);
+	hdr->device_status = rq->errors & 0xff;
 	hdr->transport_status = host_byte(rq->errors);
 	hdr->driver_status = driver_byte(rq->errors);
 	hdr->info = 0;

[10/17] r6040: fix r6040_multicast_list

[Greg KH]

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

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

From: Florian Fainelli <florian@openwrt.org>

commit 3bcf8229a8c49769e48d3e0bd1e20d8e003f8106 upstream.

As reported in <https://bugzilla.kernel.org/show_bug.cgi?id=15355>, r6040_
multicast_list currently crashes. This is due a wrong maximum of multicast
entries. This patch fixes the following issues with multicast:

- number of maximum entries if off-by-one (4 instead of 3)

- the writing of the hash table index is not necessary and leads to invalid
values being written into the MCR1 register, so the MAC is simply put in a non
coherent state

- when we exceed the maximum number of mutlticast address, writing the
broadcast address should be done in registers MID_1{L,M,H} instead of
MID_O{L,M,H}, otherwise we would loose the adapter's MAC address

[bwh: Adjust for 2.6.32; should also apply to 2.6.27]

Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/r6040.c |   11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -135,7 +135,7 @@
 #define RX_DESC_SIZE	(RX_DCNT * sizeof(struct r6040_descriptor))
 #define TX_DESC_SIZE	(TX_DCNT * sizeof(struct r6040_descriptor))
 #define MBCR_DEFAULT	0x012A	/* MAC Bus Control Register */
-#define MCAST_MAX	4	/* Max number multicast addresses to filter */
+#define MCAST_MAX	3	/* Max number multicast addresses to filter */
 
 /* Descriptor status */
 #define DSC_OWNER_MAC	0x8000	/* MAC is the owner of this descriptor */
@@ -969,9 +969,6 @@ static void r6040_multicast_list(struct
 			crc >>= 26;
 			hash_table[crc >> 4] |= 1 << (15 - (crc & 0xf));
 		}
-		/* Write the index of the hash table */
-		for (i = 0; i < 4; i++)
-			iowrite16(hash_table[i] << 14, ioaddr + MCR1);
 		/* Fill the MAC hash tables with their values */
 		iowrite16(hash_table[0], ioaddr + MAR0);
 		iowrite16(hash_table[1], ioaddr + MAR1);
@@ -987,9 +984,9 @@ static void r6040_multicast_list(struct
 		dmi = dmi->next;
 	}
 	for (i = dev->mc_count; i < MCAST_MAX; i++) {
-		iowrite16(0xffff, ioaddr + MID_0L + 8*i);
-		iowrite16(0xffff, ioaddr + MID_0M + 8*i);
-		iowrite16(0xffff, ioaddr + MID_0H + 8*i);
+		iowrite16(0xffff, ioaddr + MID_1L + 8*i);
+		iowrite16(0xffff, ioaddr + MID_1M + 8*i);
+		iowrite16(0xffff, ioaddr + MID_1H + 8*i);
 	}
 }
 

[11/17] r6040: Fix multicast list iteration when hash filter is used

[Greg KH]

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

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

From: Ben Hutchings <ben@decadent.org.uk>

This was fixed in mainline by the interface change made in commit
f9dcbcc9e338d08c0f7de7eba4eaafbbb7f81249.

After walking the multicast list to set up the hash filter, this
function will walk off the end of the list when filling the
exact-match entries.  This was fixed in mainline by the interface
change made in commit f9dcbcc9e338d08c0f7de7eba4eaafbbb7f81249.

Reported-by: spamalot@hispeed.ch
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=15355
Reported-by: Jason Heeris <jason.heeris@gmail.com>
Reference: http://bugs.debian.org/600155
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/r6040.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -976,6 +976,7 @@ static void r6040_multicast_list(struct
 		iowrite16(hash_table[3], ioaddr + MAR3);
 	}
 	/* Multicast Address 1~4 case */
+	dmi = dev->mc_list;
 	for (i = 0, dmi; (i < dev->mc_count) && (i < MCAST_MAX); i++) {
 		adrp = (u16 *)dmi->dmi_addr;
 		iowrite16(adrp[0], ioaddr + MID_1L + 8*i);

[12/17] powerpc: Initialise paca->kstack before early_setup_secondary

[Greg KH]

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

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

From: Matt Evans <matt@ozlabs.org>

commit f761622e59433130bc33ad086ce219feee9eb961 upstream.

As early setup calls down to slb_initialize(), we must have kstack
initialised before checking "should we add a bolted SLB entry for our kstack?"

Failing to do so means stack access requires an SLB miss exception to refill
an entry dynamically, if the stack isn't accessible via SLB(0) (kernel text
& static data).  It's not always allowable to take such a miss, and
intermittent crashes will result.

Primary CPUs don't have this issue; an SLB entry is not bolted for their
stack anyway (as that lives within SLB(0)).  This patch therefore only
affects the init of secondaries.

Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/powerpc/kernel/head_64.S |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -1479,9 +1479,6 @@ __secondary_start:
 	/* Load TOC */
 	ld	r2,PACATOC(r13)
 
-	/* Do early setup for that CPU (stab, slb, hash table pointer) */
-	bl	.early_setup_secondary
-
 	/* Initialize the kernel stack.  Just a repeat for iSeries.	 */
 	LOAD_REG_ADDR(r3, current_set)
 	sldi	r28,r24,3		/* get current_set[cpu#]	 */
@@ -1489,6 +1486,9 @@ __secondary_start:
 	addi	r1,r1,THREAD_SIZE-STACK_FRAME_OVERHEAD
 	std	r1,PACAKSAVE(r13)
 
+	/* Do early setup for that CPU (stab, slb, hash table pointer) */
+	bl	.early_setup_secondary
+
 	/* Clear backchain so we get nice backtraces */
 	li	r7,0
 	mtlr	r7

[13/17] powerpc: Dont use kernel stack with translation off

[Greg KH]

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

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

From: Michael Neuling <mikey@neuling.org>

commit 54a834043314c257210db2a9d59f8cc605571639 upstream.

In f761622e59433130bc33ad086ce219feee9eb961 we changed
early_setup_secondary so it's called using the proper kernel stack
rather than the emergency one.

Unfortunately, this stack pointer can't be used when translation is off
on PHYP as this stack pointer might be outside the RMO.  This results in
the following on all non zero cpus:
  cpu 0x1: Vector: 300 (Data Access) at [c00000001639fd10]
      pc: 000000000001c50c
      lr: 000000000000821c
      sp: c00000001639ff90
     msr: 8000000000001000
     dar: c00000001639ffa0
   dsisr: 42000000
    current = 0xc000000016393540
    paca    = 0xc000000006e00200
      pid   = 0, comm = swapper

The original patch was only tested on bare metal system, so it never
caught this problem.

This changes __secondary_start so that we calculate the new stack
pointer but only start using it after we've called early_setup_secondary.

With this patch, the above problem goes away.

Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/powerpc/kernel/head_64.S |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -1482,13 +1482,19 @@ __secondary_start:
 	/* Initialize the kernel stack.  Just a repeat for iSeries.	 */
 	LOAD_REG_ADDR(r3, current_set)
 	sldi	r28,r24,3		/* get current_set[cpu#]	 */
-	ldx	r1,r3,r28
-	addi	r1,r1,THREAD_SIZE-STACK_FRAME_OVERHEAD
-	std	r1,PACAKSAVE(r13)
+	ldx	r14,r3,r28
+	addi	r14,r14,THREAD_SIZE-STACK_FRAME_OVERHEAD
+	std	r14,PACAKSAVE(r13)
 
 	/* Do early setup for that CPU (stab, slb, hash table pointer) */
 	bl	.early_setup_secondary
 
+	/*
+	 * setup the new stack pointer, but *don't* use this until
+	 * translation is on.
+	 */
+	mr	r1, r14
+
 	/* Clear backchain so we get nice backtraces */
 	li	r7,0
 	mtlr	r7

[14/17] b44: fix carrier detection on bind

[Greg KH]

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

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

From: Paul Fertser <fercerpav@gmail.com>

commit bcf64aa379fcadd074449cbf0c049da70071b06f upstream.

For carrier detection to work properly when binding the driver with a cable
unplugged, netif_carrier_off() should be called after register_netdev(),
not before.

Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/b44.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -2164,8 +2164,6 @@ static int __devinit b44_init_one(struct
 	dev->irq = sdev->irq;
 	SET_ETHTOOL_OPS(dev, &b44_ethtool_ops);
 
-	netif_carrier_off(dev);
-
 	err = ssb_bus_powerup(sdev->bus, 0);
 	if (err) {
 		dev_err(sdev->dev,
@@ -2205,6 +2203,8 @@ static int __devinit b44_init_one(struct
 		goto err_out_powerdown;
 	}
 
+	netif_carrier_off(dev);
+
 	ssb_set_drvdata(sdev, dev);
 
 	/* Chip reset provides power to the b44 MAC & PCI cores, which

[15/17] setup_arg_pages: diagnose excessive argument size

[Greg KH]

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

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

From: Roland McGrath <roland@redhat.com>

commit 1b528181b2ffa14721fb28ad1bd539fe1732c583 upstream.

The CONFIG_STACK_GROWSDOWN variant of setup_arg_pages() does not
check the size of the argument/environment area on the stack.
When it is unworkably large, shift_arg_pages() hits its BUG_ON.
This is exploitable with a very large RLIMIT_STACK limit, to
create a crash pretty easily.

Check that the initial stack is not too large to make it possible
to map in any executable.  We're not checking that the actual
executable (or intepreter, for binfmt_elf) will fit.  So those
mappings might clobber part of the initial stack mapping.  But
that is just userland lossage that userland made happen, not a
kernel problem.

Signed-off-by: Roland McGrath <roland@redhat.com>
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/exec.c |    5 +++++
 1 file changed, 5 insertions(+)

--- a/fs/exec.c
+++ b/fs/exec.c
@@ -608,6 +608,11 @@ int setup_arg_pages(struct linux_binprm
 #else
 	stack_top = arch_align_stack(stack_top);
 	stack_top = PAGE_ALIGN(stack_top);
+
+	if (unlikely(stack_top < mmap_min_addr) ||
+	    unlikely(vma->vm_end - vma->vm_start >= stack_top - mmap_min_addr))
+		return -ENOMEM;
+
 	stack_shift = vma->vm_end - stack_top;
 
 	bprm->p -= stack_shift;

[16/17] execve: improve interactivity with large arguments

[Greg KH]

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

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

From: Roland McGrath <roland@redhat.com>

commit 7993bc1f4663c0db67bb8f0d98e6678145b387cd upstream.

This adds a preemption point during the copying of the argument and
environment strings for execve, in copy_strings().  There is already
a preemption point in the count() loop, so this doesn't add any new
points in the abstract sense.

When the total argument+environment strings are very large, the time
spent copying them can be much more than a normal user time slice.
So this change improves the interactivity of the rest of the system
when one process is doing an execve with very large arguments.

Signed-off-by: Roland McGrath <roland@redhat.com>
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/exec.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/fs/exec.c
+++ b/fs/exec.c
@@ -436,6 +436,8 @@ static int copy_strings(int argc, char _
 		while (len > 0) {
 			int offset, bytes_to_copy;
 
+			cond_resched();
+
 			offset = pos % PAGE_SIZE;
 			if (offset == 0)
 				offset = PAGE_SIZE;

[17/17] execve: make responsive to SIGKILL with large arguments

[Greg KH]

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

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

From: Roland McGrath <roland@redhat.com>

commit 9aea5a65aa7a1af9a4236dfaeb0088f1624f9919 upstream.

An execve with a very large total of argument/environment strings
can take a really long time in the execve system call.  It runs
uninterruptibly to count and copy all the strings.  This change
makes it abort the exec quickly if sent a SIGKILL.

Note that this is the conservative change, to interrupt only for
SIGKILL, by using fatal_signal_pending().  It would be perfectly
correct semantics to let any signal interrupt the string-copying in
execve, i.e. use signal_pending() instead of fatal_signal_pending().
We'll save that change for later, since it could have user-visible
consequences, such as having a timer set too quickly make it so that
an execve can never complete, though it always happened to work before.

Signed-off-by: Roland McGrath <roland@redhat.com>
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

---
 fs/exec.c |    7 +++++++
 1 file changed, 7 insertions(+)

--- a/fs/exec.c
+++ b/fs/exec.c
@@ -393,6 +393,9 @@ static int count(char __user * __user *
 			argv++;
 			if(++i > max)
 				return -E2BIG;
+
+			if (fatal_signal_pending(current))
+				return -ERESTARTNOHAND;
 			cond_resched();
 		}
 	}
@@ -436,6 +439,10 @@ static int copy_strings(int argc, char _
 		while (len > 0) {
 			int offset, bytes_to_copy;
 
+			if (fatal_signal_pending(current)) {
+				ret = -ERESTARTNOHAND;
+				goto out;
+			}
 			cond_resched();
 
 			offset = pos % PAGE_SIZE;

[00/17] 2.6.27.55-stable review

[Greg KH]

This is the start of the stable review cycle for the 2.6.27.55 release.
There are 17 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let us know.  If anyone is a maintainer of the proper subsystem, and
wants to add a Signed-off-by: line to the patch, please respond with it.

Responses should be made by Monday, October 25, 2010 16:00:00 UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.27.55-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

 Makefile                             |    2 +-
 arch/powerpc/kernel/head_64.S        |   18 ++++++++++++------
 block/bsg.c                          |    2 +-
 drivers/dma/mv_xor.c                 |    2 +-
 drivers/media/video/compat_ioctl32.c |   32 +++++++++++++++++++++-----------
 drivers/net/atlx/atl1.c              |    5 +++--
 drivers/net/b44.c                    |    4 ++--
 drivers/net/r6040.c                  |   12 +++++-------
 fs/aio.c                             |    3 +++
 fs/exec.c                            |   14 ++++++++++++++
 include/linux/mm.h                   |    8 +++++++-
 mm/memory.c                          |   15 +++++++++++----
 mm/mmap.c                            |    3 ---
 net/wireless/wext.c                  |    2 +-
 sound/core/control.c                 |    3 +++
 sound/pci/rme9652/hdsp.c             |    1 +
 sound/pci/rme9652/hdspm.c            |    1 +
 17 files changed, 87 insertions(+), 40 deletions(-)

Re: [11/17] r6040: Fix multicast list iteration when hash filter is used

[Jack Stone]

On 22/10/2010 19:39, Greg KH wrote:
>  drivers/net/r6040.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> --- a/drivers/net/r6040.c
> +++ b/drivers/net/r6040.c
> @@ -976,6 +976,7 @@ static void r6040_multicast_list(struct
>  		iowrite16(hash_table[3], ioaddr + MAR3);
>  	}
>  	/* Multicast Address 1~4 case */
> +	dmi = dev->mc_list;
>  	for (i = 0, dmi; (i < dev->mc_count) && (i < MCAST_MAX); i++) {
Any reason for the dmi in the above line? As far as I can see it is a
nop.

>  		adrp = (u16 *)dmi->dmi_addr;
>  		iowrite16(adrp[0], ioaddr + MID_1L + 8*i);
> 

Re: [11/17] r6040: Fix multicast list iteration when hash filter is used

[Greg KH]

On Fri, Oct 22, 2010 at 08:13:27PM +0100, Jack Stone wrote:
> On 22/10/2010 19:39, Greg KH wrote:
> >  drivers/net/r6040.c |    1 +
> >  1 file changed, 1 insertion(+)
> > 
> > --- a/drivers/net/r6040.c
> > +++ b/drivers/net/r6040.c
> > @@ -976,6 +976,7 @@ static void r6040_multicast_list(struct
> >  		iowrite16(hash_table[3], ioaddr + MAR3);
> >  	}
> >  	/* Multicast Address 1~4 case */
> > +	dmi = dev->mc_list;
> >  	for (i = 0, dmi; (i < dev->mc_count) && (i < MCAST_MAX); i++) {
> Any reason for the dmi in the above line? As far as I can see it is a
> nop.

Look closer at the for loop please.

thanks,

greg k-h

Re: [11/17] r6040: Fix multicast list iteration when hash filter is used

[Jack Stone]

On 22/10/2010 20:23, Greg KH wrote:
> On Fri, Oct 22, 2010 at 08:13:27PM +0100, Jack Stone wrote:
>> On 22/10/2010 19:39, Greg KH wrote:
>>>  drivers/net/r6040.c |    1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> --- a/drivers/net/r6040.c
>>> +++ b/drivers/net/r6040.c
>>> @@ -976,6 +976,7 @@ static void r6040_multicast_list(struct
>>>  		iowrite16(hash_table[3], ioaddr + MAR3);
>>>  	}
>>>  	/* Multicast Address 1~4 case */
>>> +	dmi = dev->mc_list;
>>>  	for (i = 0, dmi; (i < dev->mc_count) && (i < MCAST_MAX); i++) {
>> Any reason for the dmi in the above line? As far as I can see it is a
>> nop.
> 
> Look closer at the for loop please.

Maybe I'm missing something but:
for (i = 0, ---->dmi <----; (i < ...

The dmi here still doesn't seem to do anything?

Thanks,

Jack

Re: [11/17] r6040: Fix multicast list iteration when hash filter is used

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]

On Fri, 2010-10-22 at 20:29 +0100, Jack Stone wrote:
> On 22/10/2010 20:23, Greg KH wrote:
> > On Fri, Oct 22, 2010 at 08:13:27PM +0100, Jack Stone wrote:
> >> On 22/10/2010 19:39, Greg KH wrote:
> >>>  drivers/net/r6040.c |    1 +
> >>>  1 file changed, 1 insertion(+)
> >>>
> >>> --- a/drivers/net/r6040.c
> >>> +++ b/drivers/net/r6040.c
> >>> @@ -976,6 +976,7 @@ static void r6040_multicast_list(struct
> >>>  		iowrite16(hash_table[3], ioaddr + MAR3);
> >>>  	}
> >>>  	/* Multicast Address 1~4 case */
> >>> +	dmi = dev->mc_list;
> >>>  	for (i = 0, dmi; (i < dev->mc_count) && (i < MCAST_MAX); i++) {
> >> Any reason for the dmi in the above line? As far as I can see it is a
> >> nop.
> > 
> > Look closer at the for loop please.
> 
> Maybe I'm missing something but:
> for (i = 0, ---->dmi <----; (i < ...
> 
> The dmi here still doesn't seem to do anything?

It doesn't, but it doesn't do any harm either.  The loop has been
rewritten in mainline.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [11/17] r6040: Fix multicast list iteration when hash filter is used

[Jack Stone]

On 22/10/2010 22:18, Ben Hutchings wrote:
> On Fri, 2010-10-22 at 20:29 +0100, Jack Stone wrote:
>> On 22/10/2010 20:23, Greg KH wrote:
>>> On Fri, Oct 22, 2010 at 08:13:27PM +0100, Jack Stone wrote:
>>>> On 22/10/2010 19:39, Greg KH wrote:
>>>>>  drivers/net/r6040.c |    1 +
>>>>>  1 file changed, 1 insertion(+)
>>>>>
>>>>> --- a/drivers/net/r6040.c
>>>>> +++ b/drivers/net/r6040.c
>>>>> @@ -976,6 +976,7 @@ static void r6040_multicast_list(struct
>>>>>  		iowrite16(hash_table[3], ioaddr + MAR3);
>>>>>  	}
>>>>>  	/* Multicast Address 1~4 case */
>>>>> +	dmi = dev->mc_list;
>>>>>  	for (i = 0, dmi; (i < dev->mc_count) && (i < MCAST_MAX); i++) {
>>>> Any reason for the dmi in the above line? As far as I can see it is a
>>>> nop.
>>>
>>> Look closer at the for loop please.
>>
>> Maybe I'm missing something but:
>> for (i = 0, ---->dmi <----; (i < ...
>>
>> The dmi here still doesn't seem to do anything?
> 
> It doesn't, but it doesn't do any harm either.  The loop has been
> rewritten in mainline.

Agreed, it causes no problems, but it seems like it was intended to be
the dmi init, i.e.

for (i = 0, dmi = dev->mc_list; ...

I suppose it doesn't really matter but either removing the dmi in the
for loop or moving the dmi init in there would make more sense to me.

I really should learn to explain myself fully. Sorry for taking up
your time.

Thanks,

Jack