[GIT PATCH] Fixes in the -stable tree, but not in mainline

[GIT PATCH] Fixes in the -stable tree, but not in mainline

[Greg KH]

Here are 5 patches that are in the -stable tree, yet not currently fixed
in your mainline tree.  One of them is a security fix, so it probably
would be a good idea to get it into there :)

Please pull from:
	rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/stable-2.6.git/
or from:
	master.kernel.org:/pub/scm/linux/kernel/git/gregkh/stable-2.6.git/
if it isn't synced up yet.

The full patch series will sent to the linux-kernel mailing list, if
anyone wants to see them.

thanks,

greg k-h


 drivers/block/cciss.c       |   96 ++++++++++++++++++++++----------------------
 drivers/usb/storage/Kconfig |    3 -
 fs/ext3/resize.c            |    1 
 fs/partitions/check.c       |    5 ++
 ipc/shm.c                   |    2 
 5 files changed, 59 insertions(+), 48 deletions(-)

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

Ananiev, Leonid I:
      ext3: Fix missed mutex unlock

Hugh Dickins:
      shmat: stop mprotect from giving write permission to a readonly attachment (CVE-2006-1524)

Mike Miller:
      cciss: bug fix for crash when running hpacucli

Randy Dunlap:
      isd200: limit to BLK_DEV_IDE

Stephen Rothwell:
      Fix block device symlink name

[PATCH 1/5] isd200: limit to BLK_DEV_IDE

[Greg KH]

From: Randy Dunlap <rdunlap@xenotime.net>

Limit USB_STORAGE_ISD200 to whatever BLK_DEV_IDE and USB_STORAGE
are set to (y, m) since isd200 calls ide_fix_driveid() in the
BLK_DEV_IDE code.

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---

 drivers/usb/storage/Kconfig |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

66e0a9888b774af625ce544f7c6597c7506d07db
diff --git a/drivers/usb/storage/Kconfig b/drivers/usb/storage/Kconfig
index 92be101..be9eec2 100644
--- a/drivers/usb/storage/Kconfig
+++ b/drivers/usb/storage/Kconfig
@@ -48,7 +48,8 @@ config USB_STORAGE_FREECOM
 
 config USB_STORAGE_ISD200
 	bool "ISD-200 USB/ATA Bridge support"
-	depends on USB_STORAGE && BLK_DEV_IDE
+	depends on USB_STORAGE
+	depends on BLK_DEV_IDE=y || BLK_DEV_IDE=USB_STORAGE
 	---help---
 	  Say Y here if you want to use USB Mass Store devices based
 	  on the In-Systems Design ISD-200 USB/ATA bridge.
-- 
1.2.6

[PATCH 2/5] Fix block device symlink name

[Greg KH]

From: Stephen Rothwell <sfr@canb.auug.org.au>

As noted further on the this file, some block devices have a / in their
name, so fix the "block:..." symlink name the same as the /sys/block name.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---

 fs/partitions/check.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

2436f039d26a91e5404974ee0cb789b17db46168
diff --git a/fs/partitions/check.c b/fs/partitions/check.c
index f3b6af0..45ae7dd 100644
--- a/fs/partitions/check.c
+++ b/fs/partitions/check.c
@@ -372,6 +372,7 @@ static char *make_block_name(struct gend
 	char *name;
 	static char *block_str = "block:";
 	int size;
+	char *s;
 
 	size = strlen(block_str) + strlen(disk->disk_name) + 1;
 	name = kmalloc(size, GFP_KERNEL);
@@ -379,6 +380,10 @@ static char *make_block_name(struct gend
 		return NULL;
 	strcpy(name, block_str);
 	strcat(name, disk->disk_name);
+	/* ewww... some of these buggers have / in name... */
+	s = strchr(name, '/');
+	if (s)
+		*s = '!';
 	return name;
 }
 
-- 
1.2.6

[PATCH 3/5] ext3: Fix missed mutex unlock

[Greg KH]

From: Ananiev, Leonid I <leonid.i.ananiev@intel.com>

Missed unlock_super()call is added in error condition code path.

Signed-off-by: Leonid Ananiev <leonid.i.ananiev@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---

 fs/ext3/resize.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

75616cf9854b83eb83a968b1338ae0ee11c9673c
diff --git a/fs/ext3/resize.c b/fs/ext3/resize.c
index 14f5f6e..c5ffa85 100644
--- a/fs/ext3/resize.c
+++ b/fs/ext3/resize.c
@@ -767,6 +767,7 @@ int ext3_group_add(struct super_block *s
 	if (input->group != sbi->s_groups_count) {
 		ext3_warning(sb, __FUNCTION__,
 			     "multiple resizers run on filesystem!");
+		unlock_super(sb);
 		err = -EBUSY;
 		goto exit_journal;
 	}
-- 
1.2.6

[PATCH 4/5] cciss: bug fix for crash when running hpacucli

[Greg KH]

From: Mike Miller <mikem@beardog.cca.cpqcorp.net>

Fix a crash when running hpacucli with multiple logical volumes on a cciss
controller.  We were not properly initializing the disk->queue and causing
a fault.

Thanks to Hasso Tepper for reporting the problem.  Thanks to Steve Cameron
for root causing the problem.  Most of the patch just moves things around.
The fix is a one-liner.

Signed-off-by: Mike Miller <mike.miller@hp.com>
Signed-off-by: Stephen Cameron <steve.cameron@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---

 drivers/block/cciss.c |   96 +++++++++++++++++++++++++------------------------
 1 files changed, 49 insertions(+), 47 deletions(-)

ca1e0484d9fe8a9048ac32b0f9894545f43704e8
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 1b0fd31..1319d8f 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -1180,6 +1180,53 @@ static int revalidate_allvol(ctlr_info_t
         return 0;
 }
 
+static inline void complete_buffers(struct bio *bio, int status)
+{
+	while (bio) {
+		struct bio *xbh = bio->bi_next;
+		int nr_sectors = bio_sectors(bio);
+
+		bio->bi_next = NULL;
+		blk_finished_io(len);
+		bio_endio(bio, nr_sectors << 9, status ? 0 : -EIO);
+		bio = xbh;
+	}
+
+}
+
+static void cciss_softirq_done(struct request *rq)
+{
+	CommandList_struct *cmd = rq->completion_data;
+	ctlr_info_t *h = hba[cmd->ctlr];
+	unsigned long flags;
+	u64bit temp64;
+	int i, ddir;
+
+	if (cmd->Request.Type.Direction == XFER_READ)
+		ddir = PCI_DMA_FROMDEVICE;
+	else
+		ddir = PCI_DMA_TODEVICE;
+
+	/* command did not need to be retried */
+	/* unmap the DMA mapping for all the scatter gather elements */
+	for(i=0; i<cmd->Header.SGList; i++) {
+		temp64.val32.lower = cmd->SG[i].Addr.lower;
+		temp64.val32.upper = cmd->SG[i].Addr.upper;
+		pci_unmap_page(h->pdev, temp64.val, cmd->SG[i].Len, ddir);
+	}
+
+	complete_buffers(rq->bio, rq->errors);
+
+#ifdef CCISS_DEBUG
+	printk("Done with %p\n", rq);
+#endif /* CCISS_DEBUG */
+
+	spin_lock_irqsave(&h->lock, flags);
+	end_that_request_last(rq, rq->errors);
+	cmd_free(h, cmd,1);
+	spin_unlock_irqrestore(&h->lock, flags);
+}
+
 /* This function will check the usage_count of the drive to be updated/added.
  * If the usage_count is zero then the drive information will be updated and
  * the disk will be re-registered with the kernel.  If not then it will be
@@ -1248,6 +1295,8 @@ static void cciss_update_drive_info(int 
 
 		blk_queue_max_sectors(disk->queue, 512);
 
+		blk_queue_softirq_done(disk->queue, cciss_softirq_done);
+
 		disk->queue->queuedata = hba[ctlr];
 
 		blk_queue_hardsect_size(disk->queue,
@@ -2147,20 +2196,6 @@ static void start_io( ctlr_info_t *h)
 		addQ (&(h->cmpQ), c); 
 	}
 }
-
-static inline void complete_buffers(struct bio *bio, int status)
-{
-	while (bio) {
-		struct bio *xbh = bio->bi_next; 
-		int nr_sectors = bio_sectors(bio);
-
-		bio->bi_next = NULL; 
-		blk_finished_io(len);
-		bio_endio(bio, nr_sectors << 9, status ? 0 : -EIO);
-		bio = xbh;
-	}
-
-} 
 /* Assumes that CCISS_LOCK(h->ctlr) is held. */
 /* Zeros out the error record and then resends the command back */
 /* to the controller */
@@ -2178,39 +2213,6 @@ static inline void resend_cciss_cmd( ctl
 	start_io(h);
 }
 
-static void cciss_softirq_done(struct request *rq)
-{
-	CommandList_struct *cmd = rq->completion_data;
-	ctlr_info_t *h = hba[cmd->ctlr];
-	unsigned long flags;
-	u64bit temp64;
-	int i, ddir;
-
-	if (cmd->Request.Type.Direction == XFER_READ)
-		ddir = PCI_DMA_FROMDEVICE;
-	else
-		ddir = PCI_DMA_TODEVICE;
-
-	/* command did not need to be retried */
-	/* unmap the DMA mapping for all the scatter gather elements */
-	for(i=0; i<cmd->Header.SGList; i++) {
-		temp64.val32.lower = cmd->SG[i].Addr.lower;
-		temp64.val32.upper = cmd->SG[i].Addr.upper;
-		pci_unmap_page(h->pdev, temp64.val, cmd->SG[i].Len, ddir);
-	}
-
-	complete_buffers(rq->bio, rq->errors);
-
-#ifdef CCISS_DEBUG
-	printk("Done with %p\n", rq);
-#endif /* CCISS_DEBUG */ 
-
-	spin_lock_irqsave(&h->lock, flags);
-	end_that_request_last(rq, rq->errors);
-	cmd_free(h, cmd,1);
-	spin_unlock_irqrestore(&h->lock, flags);
-}
-
 /* checks the status of the job and calls complete buffers to mark all 
  * buffers for the completed job. Note that this function does not need
  * to hold the hba/queue lock.
-- 
1.2.6

[PATCH 5/5] shmat: stop mprotect from giving write permission to a readonly attachment (CVE-2006-1524)

[Greg KH]

From: Hugh Dickins <hugh@veritas.com>

I found that all of 2.4 and 2.6 have been letting mprotect give write
permission to a readonly attachment of shared memory, whether or not IPC
would give the caller that permission.

SUS says "The behaviour of this function [mprotect] is unspecified if the
mapping was not established by a call to mmap", but I don't think we can
interpret that as allowing it to subvert IPC permissions.

I haven't tried 2.2, but the 2.2.26 source looks like it gets it right; and
the patch below reproduces that behaviour - mprotect cannot be used to add
write permission to a shared memory segment attached readonly.

This patch is simple, and I'm sure it's what we should have done in 2.4.0:
if you want to go on to switch write permission on and off with mprotect,
just don't attach the segment readonly in the first place.

However, we could have accumulated apps which attach readonly (even though
they would be permitted to attach read/write), and which subsequently use
mprotect to switch write permission on and off: it's not unreasonable.

I was going to add a second ipcperms check in do_shmat, to check for
writable when readonly, and if not writable find_vma and clear VM_MAYWRITE.
 But security_ipc_permission might do auditing, and it seems wrong to
report an attempt for write permission when there has been none.  Or we
could flag the vma as SHM, note the shmid or shp in vm_private_data, and
then get mprotect to check.

But the patch below is a lot simpler: I'd rather stick with it, if we can
convince ourselves somehow that it'll be safe.

Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---

 ipc/shm.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

b78b6af66a5fbaf17d7e6bfc32384df5e34408c8
diff --git a/ipc/shm.c b/ipc/shm.c
index 6b0c9af..1c2faf6 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -162,6 +162,8 @@ static int shm_mmap(struct file * file, 
 	ret = shmem_mmap(file, vma);
 	if (ret == 0) {
 		vma->vm_ops = &shm_vm_ops;
+		if (!(vma->vm_flags & VM_WRITE))
+			vma->vm_flags &= ~VM_MAYWRITE;
 		shm_inc(file->f_dentry->d_inode->i_ino);
 	}
 
-- 
1.2.6

Re: [GIT PATCH] Fixes in the -stable tree, but not in mainline

[Theodore Ts'o]

On Mon, Apr 17, 2006 at 02:29:46PM -0700, Greg KH wrote:
> Here are 5 patches that are in the -stable tree, yet not currently fixed
> in your mainline tree.  One of them is a security fix, so it probably
> would be a good idea to get it into there :)

I thought one of the requirements for accepting a patch into -stable
was that it was already in mainline.  Was this a change in policy that
I missed, or just an oversight when we vetted these patches?

Not that I have anything against these patches, just curious in the
future if we should NACK patches proposed for -stable if we notice
that they aren't yet in mainline.

						- Ted

Re: [GIT PATCH] Fixes in the -stable tree, but not in mainline

[Greg KH]

On Tue, Apr 18, 2006 at 12:06:10PM -0400, Theodore Ts'o wrote:
> On Mon, Apr 17, 2006 at 02:29:46PM -0700, Greg KH wrote:
> > Here are 5 patches that are in the -stable tree, yet not currently fixed
> > in your mainline tree.  One of them is a security fix, so it probably
> > would be a good idea to get it into there :)
> 
> I thought one of the requirements for accepting a patch into -stable
> was that it was already in mainline.  Was this a change in policy that
> I missed, or just an oversight when we vetted these patches?
> 
> Not that I have anything against these patches, just curious in the
> future if we should NACK patches proposed for -stable if we notice
> that they aren't yet in mainline.

Sometimes some of these patches don't make it into Linus's tree because
they get lost in the shuffle (like the Kconfig one), or because they
were security issues that hit -stable first (like another one in there).

Either way, yes, the rule is that it should be in mainline, or in the
pipe to get into mainline (as was the 5 in this patchset.)  I just
wanted to make sure they made it into there, and didn't get lost.

thanks,

greg k-h

Re: [GIT PATCH] Fixes in the -stable tree, but not in mainline

[Andrew Morton]

Greg KH <gregkh@suse.de> wrote:
>
> On Tue, Apr 18, 2006 at 12:06:10PM -0400, Theodore Ts'o wrote:
> > On Mon, Apr 17, 2006 at 02:29:46PM -0700, Greg KH wrote:
> > > Here are 5 patches that are in the -stable tree, yet not currently fixed
> > > in your mainline tree.  One of them is a security fix, so it probably
> > > would be a good idea to get it into there :)
> > 
> > I thought one of the requirements for accepting a patch into -stable
> > was that it was already in mainline.  Was this a change in policy that
> > I missed, or just an oversight when we vetted these patches?
> > 
> > Not that I have anything against these patches, just curious in the
> > future if we should NACK patches proposed for -stable if we notice
> > that they aren't yet in mainline.
> 
> Sometimes some of these patches don't make it into Linus's tree because
> they get lost in the shuffle (like the Kconfig one), or because they
> were security issues that hit -stable first (like another one in there).
> 
> Either way, yes, the rule is that it should be in mainline, or in the
> pipe to get into mainline (as was the 5 in this patchset.)  I just
> wanted to make sure they made it into there, and didn't get lost.
> 

I had them queued up as well, but I'm being sluggish and Greg got there first.