[00/07] -stable review

[00/07] -stable review

[Greg KH]

This is the start of the stable review cycle for the 2.6.11.8 release.  There
are 7 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.

These patches are sent out with a number of different people on the Bcc: line.
If you wish to be a reviewer, please email stable@linux.com to add your name to
the list.  If you want to be off the reviewer list, also email us.

Responses should be made by Friday, Apr 29 17:00 UTC.  Anything received after
that time, might be too late.

thanks,

the -stable release team

[01/07] uml: add nfsd syscall when nfsd is modular

[Greg KH]

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

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


This trick is useless, because sys_ni.c will handle this problem by itself,
like it does even on UML for other syscalls.
Also, it does not provide the NFSD syscall when NFSD is compiled as a module,
which is a big problem.

This should be merged currently in both 2.6.11-stable and the current tree.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---

 clean-linux-2.6.11-paolo/arch/um/kernel/sys_call_table.c |    8 +-------
 1 files changed, 1 insertion(+), 7 deletions(-)

diff -puN arch/um/kernel/sys_call_table.c~uml-nfsd-syscall arch/um/kernel/sys_call_table.c
--- clean-linux-2.6.11/arch/um/kernel/sys_call_table.c~uml-nfsd-syscall	2005-04-10 13:50:29.000000000 +0200
+++ clean-linux-2.6.11-paolo/arch/um/kernel/sys_call_table.c	2005-04-10 13:51:19.000000000 +0200
@@ -14,12 +14,6 @@
 #include "sysdep/syscalls.h"
 #include "kern_util.h"
 
-#ifdef CONFIG_NFSD
-#define NFSSERVCTL sys_nfsservctl
-#else
-#define NFSSERVCTL sys_ni_syscall
-#endif
-
 #define LAST_GENERIC_SYSCALL __NR_keyctl
 
 #if LAST_GENERIC_SYSCALL > LAST_ARCH_SYSCALL
@@ -190,7 +184,7 @@ syscall_handler_t *sys_call_table[] = {
 	[ __NR_getresuid ] = (syscall_handler_t *) sys_getresuid16,
 	[ __NR_query_module ] = (syscall_handler_t *) sys_ni_syscall,
 	[ __NR_poll ] = (syscall_handler_t *) sys_poll,
-	[ __NR_nfsservctl ] = (syscall_handler_t *) NFSSERVCTL,
+	[ __NR_nfsservctl ] = (syscall_handler_t *) sys_nfsservctl,
 	[ __NR_setresgid ] = (syscall_handler_t *) sys_setresgid16,
 	[ __NR_getresgid ] = (syscall_handler_t *) sys_getresgid16,
 	[ __NR_prctl ] = (syscall_handler_t *) sys_prctl,
_

Re: [01/07] uml: add nfsd syscall when nfsd is modular

[Alan Cox]

On Mer, 2005-04-27 at 18:15, Greg KH wrote:
> -stable review patch.  If anyone has any objections, please let us know.

Don't see why this one is a critical bug.

Re: [01/07] uml: add nfsd syscall when nfsd is modular

[Chris Wright]

* Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
> On Mer, 2005-04-27 at 18:15, Greg KH wrote:
> > -stable review patch.  If anyone has any objections, please let us know.
> 
> Don't see why this one is a critical bug.

I guess without it, modular nfsd has no syscall interface (for UML, or
course).

thanks,
-chris

Re: [01/07] uml: add nfsd syscall when nfsd is modular

[Alan Cox]

On Mer, 2005-04-27 at 18:46, Chris Wright wrote:
> > Don't see why this one is a critical bug.
> 
> I guess without it, modular nfsd has no syscall interface (for UML, or
> course).

And the trivial zero risk fix is to compile it in. Its hardly pressing

Re: [01/07] uml: add nfsd syscall when nfsd is modular

[Chris Wright]

* Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
> On Mer, 2005-04-27 at 18:46, Chris Wright wrote:
> > > Don't see why this one is a critical bug.
> > 
> > I guess without it, modular nfsd has no syscall interface (for UML, or
> > course).
> 
> And the trivial zero risk fix is to compile it in. Its hardly pressing

OK, let's drop it.

thanks,
-chris

Re: [01/07] uml: add nfsd syscall when nfsd is modular

[Greg KH]

On Wed, Apr 27, 2005 at 11:47:33AM -0700, Chris Wright wrote:
> * Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
> > On Mer, 2005-04-27 at 18:46, Chris Wright wrote:
> > > > Don't see why this one is a critical bug.
> > > 
> > > I guess without it, modular nfsd has no syscall interface (for UML, or
> > > course).
> > 
> > And the trivial zero risk fix is to compile it in. Its hardly pressing
> 
> OK, let's drop it.

Dropped.

thanks,

greg k-h

[02/07] [fix Bug 4395] modprobe bttv freezes the computer

[Greg KH]

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

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

Here's a patch that fixes
http://bugme.osdl.org/show_bug.cgi?id=4395.

In case there's a 2.6.11.7 before 2.6.12 is released it would
be nice to include this patch there, too.

Johannes

---
Patch by Manu Abraham and Gerd Knorr:
Remove redundant bttv_reset_audio() which caused the computer to
freeze with some bt8xx based DVB cards when loading the bttv driver.

Signed-off-by: Johannes Stezenbach <js@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

--- linux-2.6.12-rc2.orig/drivers/media/video/bttv-cards.c	2005-04-05 02:35:41.000000000 +0200
+++ linux-2.6.12-rc2/drivers/media/video/bttv-cards.c	2005-04-05 02:37:31.000000000 +0200
@@ -2785,8 +2785,6 @@ void __devinit bttv_init_card2(struct bt
         }
 	btv->pll.pll_current = -1;
 
-	bttv_reset_audio(btv);
-
 	/* tuner configuration (from card list / autodetect / insmod option) */
  	if (UNSET != bttv_tvcards[btv->c.type].tuner_type)
 		if(UNSET == btv->tuner_type)

[03/07] I2C: Fix incorrect sysfs file permissions in it87 and via686a drivers

[Greg KH]

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

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

The it87 and via686a hardware monitoring drivers each create a sysfs
file named "alarms" in R/W mode, while they should really create it in
read-only mode. Since we don't provide a store function for these files,
write attempts to these files will do something undefined (I guess) and
bad (I am sure). My own try resulted in a locked terminal (where I
attempted the write) and a 100% CPU load until next reboot.

As a side note, wouldn't it make sense to check, when creating sysfs
files, that readable files have a non-NULL show method, and writable
files have a non-NULL store method? I know drivers are not supposed to
do stupid things, but there is already a BUG_ON for several conditions
in sysfs_create_file, so maybe we could add two more?

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

--- linux-2.6.12-rc1-bk5/drivers/i2c/chips/it87.c.orig	2005-04-02 18:09:59.000000000 +0200
+++ linux-2.6.12-rc1-bk5/drivers/i2c/chips/it87.c	2005-04-02 21:12:46.000000000 +0200
@@ -668,7 +668,7 @@
 	struct it87_data *data = it87_update_device(dev);
 	return sprintf(buf,"%d\n", ALARMS_FROM_REG(data->alarms));
 }
-static DEVICE_ATTR(alarms, S_IRUGO | S_IWUSR, show_alarms, NULL);
+static DEVICE_ATTR(alarms, S_IRUGO, show_alarms, NULL);
 
 static ssize_t
 show_vrm_reg(struct device *dev, char *buf)
--- linux-2.6.12-rc1-bk5/drivers/i2c/chips/via686a.c.orig	2005-04-02 18:22:48.000000000 +0200
+++ linux-2.6.12-rc1-bk5/drivers/i2c/chips/via686a.c	2005-04-02 21:12:55.000000000 +0200
@@ -574,7 +574,7 @@
 	struct via686a_data *data = via686a_update_device(dev);
 	return sprintf(buf,"%d\n", ALARMS_FROM_REG(data->alarms));
 }
-static DEVICE_ATTR(alarms, S_IRUGO | S_IWUSR, show_alarms, NULL);
+static DEVICE_ATTR(alarms, S_IRUGO, show_alarms, NULL);
 
 /* The driver. I choose to use type i2c_driver, as at is identical to both
    smbus_driver and isa_driver, and clients could be of either kind */


-- 
Jean Delvare

Re: [03/07] I2C: Fix incorrect sysfs file permissions in it87 and via686a drivers

[Dmitry Torokhov]

On 4/27/05, Greg KH <gregkh@suse.de> wrote:
> 
> -stable review patch.  If anyone has any objections, please let us know.
> 

While the patch is correct I'd have something like this as well:

--- linux-2.6.11.orig/fs/sysfs/file.c
+++ linux-2.6.11/fs/sysfs/file.c
@@ -36,7 +36,7 @@ subsys_attr_store(struct kobject * kobj,
 {
        struct subsystem * s = to_subsys(kobj);
        struct subsys_attribute * sattr = to_sattr(attr);
-       ssize_t ret = 0;
+       ssize_t ret = -ENOSYS;
 
        if (sattr->store)
                ret = sattr->store(s,page,count);

So writes without store handler would return "not implemented".

(It is whitespace-mangled and therefore not a real patch - so no
signed-off-by...)

-- 
Dmitry

Re: [03/07] I2C: Fix incorrect sysfs file permissions in it87 and via686a drivers

[Dmitry Torokhov]

On 4/27/05, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> On 4/27/05, Greg KH <gregkh@suse.de> wrote:
> >
> > -stable review patch.  If anyone has any objections, please let us know.
> >
> 
> While the patch is correct I'd have something like this as well:
> 
> --- linux-2.6.11.orig/fs/sysfs/file.c
> +++ linux-2.6.11/fs/sysfs/file.c
> @@ -36,7 +36,7 @@ subsys_attr_store(struct kobject * kobj,
> {
>        struct subsystem * s = to_subsys(kobj);
>        struct subsys_attribute * sattr = to_sattr(attr);
> -       ssize_t ret = 0;
> +       ssize_t ret = -ENOSYS;
> 
>        if (sattr->store)
>                ret = sattr->store(s,page,count);
> 
> So writes without store handler would return "not implemented".
> 

Obviously driver_sysfs_ops, bus_sysfs_ops, etc need the same treatment...

-- 
Dmitry

Re: [03/07] I2C: Fix incorrect sysfs file permissions in it87 and via686a drivers

[Dmitry Torokhov]

On Wednesday 27 April 2005 12:16, Greg KH wrote:
> As a side note, wouldn't it make sense to check, when creating sysfs
> files, that readable files have a non-NULL show method, and writable
> files have a non-NULL store method? I know drivers are not supposed to
> do stupid things, but there is already a BUG_ON for several conditions
> in sysfs_create_file, so maybe we could add two more?

Checking at creation time is not enough. Even with such check one could
change permissions on a sysfs file and set write bit.

-- 
Dmitry

[04/07] partitions/msdos.c fix

[Greg KH]

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

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

Erik reports this fixes an oops on boot for him.

From: Andries Brouwer <Andries.Brouwer@cwi.nl>

A well-known kernel bug is that it guesses at the partition type and the
partitions on any disk it encounters.  This is bad because needless I/O is
done, slowing down the boot, sometimes quite a lot, especially when I/O
errors occur.  And it is bad because sometimes we guess wrong.

In other words, we need the user space command `partition', where
"partition -t dos /dev/sda" reads a DOS-type partition table.  (And
"partition /dev/sda" tries all known heuristics to decide what type of
partitioning might be present.) The two variants are: (i) partition tells
the kernel to do the partition table reading, and (ii) partition uses partx
to read the partition table and tells the kernel one-by-one about the
partitions found this way.

Since this is a fundamental change, a long transition period is needed, and
that period could start with a kernel boot parameter telling the kernel not
to do partition table parsing on a particular disk, or a particular type of
disks, or all disks.

This could have been the intro to a patch doing that, but is not.  (It is
just an RFC.)

The tiny patch below prompted the above - it was suggested by Uwe Bonnes
who encountered USB devices without partition table where our present
heuristics did not suffice to stop partition table parsing.  It causes the
kernel to ignore partitions of type 0.  A band-aid.

I think nobody uses such partitions seriously, but nevertheless this should
probably live in -mm for a while to see if anybody complains.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---

===== fs/partitions/msdos.c 1.26 vs 1.27 =====
--- 1.26/fs/partitions/msdos.c	2004-11-09 12:43:17 -08:00
+++ 1.27/fs/partitions/msdos.c	2005-03-07 20:41:42 -08:00
@@ -114,6 +114,9 @@ parse_extended(struct parsed_partitions 
 		 */
 		for (i=0; i<4; i++, p++) {
 			u32 offs, size, next;
+
+			if (SYS_IND(p) == 0)
+				continue;
 			if (!NR_SECTS(p) || is_extended_partition(p))
 				continue;
 
@@ -430,6 +433,8 @@ int msdos_partition(struct parsed_partit
 	for (slot = 1 ; slot <= 4 ; slot++, p++) {
 		u32 start = START_SECT(p)*sector_size;
 		u32 size = NR_SECTS(p)*sector_size;
+		if (SYS_IND(p) == 0)
+			continue;
 		if (!size)
 			continue;
 		if (is_extended_partition(p)) {

Re: [04/07] partitions/msdos.c fix

[Andries Brouwer]

On Wed, Apr 27, 2005 at 10:16:27AM -0700, Greg KH wrote:

> -stable review patch.  If anyone has any objections, please let us know.
> 
> ------------------
> 
> Erik reports this fixes an oops on boot for him.

No objections. But..

The purpose of this patch was not to fix an oops, but to avoid
partition table parsing in a situation where almost surely
no partition table is present.

If this fixes an oops, then I want to know precisely what oops.
No doubt that same oops could occur in other circumstances where
this patch does not happen to help.

Andries

Re: [04/07] partitions/msdos.c fix

[Erik Tews]

Am Mittwoch, den 27.04.2005, 22:34 +0200 schrieb Andries Brouwer:
> On Wed, Apr 27, 2005 at 10:16:27AM -0700, Greg KH wrote:
> 
> > -stable review patch.  If anyone has any objections, please let us know.
> > 
> > ------------------
> > 
> > Erik reports this fixes an oops on boot for him.
> 
> No objections. But..
> 
> The purpose of this patch was not to fix an oops, but to avoid
> partition table parsing in a situation where almost surely
> no partition table is present.
> 
> If this fixes an oops, then I want to know precisely what oops.
> No doubt that same oops could occur in other circumstances where
> this patch does not happen to help.

Hi, this happend on my laptop (ibm thinkpad t41p, intel cpu, no special
kind of partition layout). Because this happend during partition table
parsing (during bootup), I was not able to copy it.

But this should only affect the first 512 bytes of my harddisk, or? If
so, I can copy this data and send it to you.

Re: [04/07] partitions/msdos.c fix

[Andries Brouwer]

On Wed, Apr 27, 2005 at 10:49:28PM +0200, Erik Tews wrote:

> But this should only affect the first 512 bytes of my harddisk, or? If
> so, I can copy this data and send it to you.

Yes, please do.

(There are various ways in which more data could be involved,
but the first sector is a good start.)

Andries

Re: [04/07] partitions/msdos.c fix

[Pavel Machek]

Hi!

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

Well, patch author says it should go to mm...:

> I think nobody uses such partitions seriously, but nevertheless this should
> probably live in -mm for a while to see if anybody complains.

...seems like enough not to let it into .8...
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

[05/07] [PATCH] Fix reproducible SMP crash in security/keys/key.c

[Greg KH]

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

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

Jani Jaakkola <jjaakkol@cs.Helsinki.FI> wrote:
>
> SMP race handling is broken in key_user_lookup() in security/keys/key.c

This was fixed post-2.6.11.  Can you confirm that 2.6.12-rc2 works OK?

This is the patch we used.  It should go into -stable if it's not already
there.


From: Alexander Nyberg <alexn@dsv.su.se>

I looked at some of the oops reports against keyrings, I think the problem
is that the search isn't restarted after dropping the key_user_lock, *p
will still be NULL when we get back to try_again and look through the tree.

It looks like the intention was that the search start over from scratch.

Signed-off-by: Alexander Nyberg <alexn@dsv.su.se>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---

 25-akpm/security/keys/key.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletion(-)

diff -puN security/keys/key.c~race-against-parent-deletion-in-key_user_lookup security/keys/key.c
--- 25/security/keys/key.c~race-against-parent-deletion-in-key_user_lookup	2005-03-10 00:38:38.000000000 -0800
+++ 25-akpm/security/keys/key.c	2005-03-10 00:38:38.000000000 -0800
@@ -57,9 +57,10 @@ struct key_user *key_user_lookup(uid_t u
 {
 	struct key_user *candidate = NULL, *user;
 	struct rb_node *parent = NULL;
-	struct rb_node **p = &key_user_tree.rb_node;
+	struct rb_node **p;
 
  try_again:
+	p = &key_user_tree.rb_node;
 	spin_lock(&key_user_lock);
 
 	/* search the tree for a user record with a matching UID */
_

[06/07] [PATCH] SCSI tape security: require CAP_ADMIN for SG_IO etc.

[Greg KH]

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

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

The kernel currently allows any user permitted to access the tape device file
to send the tape drive commands that may either make the tape drivers internal
state inconsistent or to change the drive parameters so that other users find
the drive to be unusable. This patch changes ioctl handling so that SG_IO,
SCSI_IOCTL_COMMAND, etc. require CAP_ADMIN. This solves the consistency
problems for SCSI tapes. The st driver provides user-accessible commands to
change the drive parameters that users may need to access.

The SCSI command permissions were discussed widely on the linux lists but this
did not result in any useful refinement of the permissions. It may very well
be that the tape drives are the only devices that users are sometimes given
permissions to access and that have security problems with the current command
filtering. This patch solves the problem for tapes and no more elaborate
patches are needed.

Signed-off-by: Kai Makisara <kai.makisara@kolumbus.fi>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>


diff -Naru a/drivers/scsi/st.c b/drivers/scsi/st.c
--- a/drivers/scsi/st.c	2005-04-27 09:50:24 -07:00
+++ b/drivers/scsi/st.c	2005-04-27 09:50:24 -07:00
@@ -3461,11 +3461,17 @@
 		case SCSI_IOCTL_GET_BUS_NUMBER:
 			break;
 		default:
-			i = scsi_cmd_ioctl(file, STp->disk, cmd_in, p);
+			if (!capable(CAP_SYS_ADMIN))
+				i = -EPERM;
+			else
+				i = scsi_cmd_ioctl(file, STp->disk, cmd_in, p);
 			if (i != -ENOTTY)
 				return i;
 			break;
 	}
+	if (!capable(CAP_SYS_ADMIN) &&
+	    (cmd_in == SCSI_IOCTL_START_UNIT || cmd_in == SCSI_IOCTL_STOP_UNIT))
+		return -EPERM;
 	return scsi_ioctl(STp->device, cmd_in, p);
 
  out:

Re: [06/07] [PATCH] SCSI tape security: require CAP_ADMIN for SG_IO etc.

[Alan Cox]

On Mer, 2005-04-27 at 18:16, Greg KH wrote:
> -stable review patch.  If anyone has any objections, please let us know.

This patch is just wrong on so many different levels its hard to know
where to begin.

1. The auth for arbitary commands is CAP_SYS_RAWIO
2. "The SCSI command permissions were discussed widely on the linux
lists but this did not result in any useful refinement of the
permissions." - this is false. The process was refined, a table setup
was added and debugged. Someone even wrote an fs for managing it that is
not yet merged. Perhaps the patch author would care to re-read the
archives and submit a new patch if one is even needed
3. Pleas explain *what* the specific consistency problems are

And then please fix the same mess in 12rc.

Alan

Re: [06/07] [PATCH] SCSI tape security: require CAP_ADMIN for SG_IO etc.

[Greg KH]

On Wed, Apr 27, 2005 at 05:38:49PM +0100, Alan Cox wrote:
> On Mer, 2005-04-27 at 18:16, Greg KH wrote:
> > -stable review patch.  If anyone has any objections, please let us know.
> 
> This patch is just wrong on so many different levels its hard to know
> where to begin.

But that is what is now in mainline, right?  If so, all of these
questions still pertain to the current tree...

> 1. The auth for arbitary commands is CAP_SYS_RAWIO
> 2. "The SCSI command permissions were discussed widely on the linux
> lists but this did not result in any useful refinement of the
> permissions." - this is false. The process was refined, a table setup
> was added and debugged. Someone even wrote an fs for managing it that is
> not yet merged. Perhaps the patch author would care to re-read the
> archives and submit a new patch if one is even needed
> 3. Pleas explain *what* the specific consistency problems are
> 
> And then please fix the same mess in 12rc.

thanks,

greg k-h

Re: [06/07] [PATCH] SCSI tape security: require CAP_ADMIN for SG_IO etc.

[Alan Cox]

On Mer, 2005-04-27 at 19:26, Greg KH wrote:
> > This patch is just wrong on so many different levels its hard to know
> > where to begin.
> 
> But that is what is now in mainline, right?  If so, all of these
> questions still pertain to the current tree...

Correct, the 12rc code is also completely wrong. Good job we caught it
since its apparently not been reviewed properly until now.

Re: [06/07] [PATCH] SCSI tape security: require CAP_ADMIN for SG_IO etc.

[Kai Makisara]

On Wed, 27 Apr 2005, Alan Cox wrote:

> On Mer, 2005-04-27 at 18:16, Greg KH wrote:
> > -stable review patch.  If anyone has any objections, please let us know.
> 
> This patch is just wrong on so many different levels its hard to know
> where to begin.
> 
> 1. The auth for arbitary commands is CAP_SYS_RAWIO

Valid complaint.

> 2. "The SCSI command permissions were discussed widely on the linux
> lists but this did not result in any useful refinement of the
> permissions." - this is false. The process was refined, a table setup
> was added and debugged.

Any user having write access to the device is still allowed to send MODE 
SELECT (and some other commands useful for CD/DVD writers but being 
potentially dangerous to other). The assumption that _any_ command needed 
for burning CDs/DVDs is safe for all device types is ridiculous. This is 
why I don't consider the refinements useful.

Controlling high-level access and pass-through with the same permissions 
is not a very good model.

> Someone even wrote an fs for managing it that is
> not yet merged.

Yes. So we should wait for a miracle happen and it get merged? My patch 
is meant to fix the problems at low level until a more general fix is 
merged (if that ever happens).

> Perhaps the patch author would care to re-read the
> archives and submit a new patch if one is even needed
> 3. Pleas explain *what* the specific consistency problems are

OK. Once again....

Using MODE SELECT you can change the drive behaviour so that it may become 
practically useless for other users (and even break very quickly). A 
simple method is to disable drive buffering. The inconsistency here is 
that to the users the drive status is not what the system managers meant 
it to be.

Another inconsistency comes from using commands moving the tape so that 
the tape driver does not know it. The tape driver provides users some 
status information about the tape head location (file and block number, 
BOT, EOF, etc.). This information is not valid if tape is moved using 
pass-through. The basic problem is that the driver for this kind of a 
sequential access device has to maintain some state information and it 
gets distorted if pass-through is used. One solution would, of course, be 
to interpret the commands and statuses going to/coming from pass-through 
but this is a quite heavy solution.


OK. If the Linux solution to these kind of security problems in the not so 
central areas of kernel is to wait and see if the problem disappears 
without any action, I have to accept that. But I have tried...

-- 
Kai

Re: [06/07] [PATCH] SCSI tape security: require CAP_ADMIN for SG_IO etc.

[Arjan van de Ven]

On Thu, 2005-04-28 at 08:43 +0300, Kai Makisara wrote:
> On Wed, 27 Apr 2005, Alan Cox wrote:
> 
> > On Mer, 2005-04-27 at 18:16, Greg KH wrote:
> > > -stable review patch.  If anyone has any objections, please let us know.
> > 
> > This patch is just wrong on so many different levels its hard to know
> > where to begin.
> > 
> > 1. The auth for arbitary commands is CAP_SYS_RAWIO
> 
> Valid complaint.
> 
> > 2. "The SCSI command permissions were discussed widely on the linux
> > lists but this did not result in any useful refinement of the
> > permissions." - this is false. The process was refined, a table setup
> > was added and debugged.
> 
> Any user having write access to the device is still allowed to send MODE 
> SELECT (and some other commands useful for CD/DVD writers but being 
> potentially dangerous to other). 

If you give your user *WRITE ACCESS* to the tape you expect him to be
able to do a lot of writing, right? The restrictions for *READ* are
obviously more clear...

> OK. If the Linux solution to these kind of security problems in the not so 
> central areas of kernel is to wait and see if the problem disappears 
> without any action, I have to accept that. But I have tried...

the security problem is giving someone write access to a device and then
somehow expect that to mean "selective write" ?

Re: [06/07] [PATCH] SCSI tape security: require CAP_ADMIN for SG_IO etc.

[Alan Cox]

On Iau, 2005-04-28 at 06:43, Kai Makisara wrote:
> Any user having write access to the device is still allowed to send MODE 
> SELECT (and some other commands useful for CD/DVD writers but being 
> potentially dangerous to other). The assumption that _any_ command needed 
> for burning CDs/DVDs is safe for all device types is ridiculous. This is 
> why I don't consider the refinements useful.

Ok thats the bit I needed to know

> Using MODE SELECT you can change the drive behaviour so that it may become 
> practically useless for other users (and even break very quickly). A 
> simple method is to disable drive buffering. The inconsistency here is 
> that to the users the drive status is not what the system managers meant 
> it to be.

Equally users will want to change the drive status and in some
situations will be changing the drive status habitually when using the
tape devices. That seems to have tape level ioctls anyway.

> Another inconsistency comes from using commands moving the tape so that 
> the tape driver does not know it. The tape driver provides users some 
> status information about the tape head location (file and block number, 
> BOT, EOF, etc.). This information is not valid if tape is moved using 
> pass-through. The basic problem is that the driver for this kind of a 
> sequential access device has to maintain some state information and it 
> gets distorted if pass-through is used. One solution would, of course, be 
> to interpret the commands and statuses going to/coming from pass-through 
> but this is a quite heavy solution.

That isn't a problem. The other drivers and O_DIRECT all take the same
basic approach that users doing raw I/O commands can shoot themselves in
the feet. Anything else stops people doing clever things they need to.
What it must not allow (as you explained in your example with mode
select) is let people shoot each other in the feet.

On the info you give making it CAP_SYS_RAWIO for now does appear to make
sense. A tape safe command or filter list might be better eventually
(and/or making the driver put the state back right on open - which may
also be neccessary when drives get powered off independantly of the
host...)

Alan

Re: [06/07] [PATCH] SCSI tape security: require CAP_ADMIN for SG_IO etc.

[Greg KH]

On Thu, Apr 28, 2005 at 02:21:52PM +0100, Alan Cox wrote:
> On Iau, 2005-04-28 at 06:43, Kai Makisara wrote:
> > Any user having write access to the device is still allowed to send MODE 
> > SELECT (and some other commands useful for CD/DVD writers but being 
> > potentially dangerous to other). The assumption that _any_ command needed 
> > for burning CDs/DVDs is safe for all device types is ridiculous. This is 
> > why I don't consider the refinements useful.
> 
> Ok thats the bit I needed to know

So, do you still object to this patch being accepted?

thanks,

greg k-h

Re: [06/07] [PATCH] SCSI tape security: require CAP_ADMIN for SG_IO etc.

[Alan Cox]

On Gwe, 2005-04-29 at 05:20, Greg KH wrote:
> > Ok thats the bit I needed to know
> 
> So, do you still object to this patch being accepted?

Switched to CAP_SYS_RAWIO I don't. Its the wrong answer long term I
suspect but its definitely a good answer for now.

Alan

Re: [06/07] [PATCH] SCSI tape security: require CAP_ADMIN for SG_IO etc.

[Greg KH]

On Fri, Apr 29, 2005 at 09:16:27PM +0100, Alan Cox wrote:
> On Gwe, 2005-04-29 at 05:20, Greg KH wrote:
> > > Ok thats the bit I needed to know
> > 
> > So, do you still object to this patch being accepted?
> 
> Switched to CAP_SYS_RAWIO I don't. Its the wrong answer long term I
> suspect but its definitely a good answer for now.

Switch it in both capable() calls in the patch?  Kai, is this acceptable
to you also?

thanks,

greg k-h

Re: [06/07] [PATCH] SCSI tape security: require CAP_ADMIN for SG_IO etc.

[Kai Makisara]

On Fri, 29 Apr 2005, Greg KH wrote:

> On Fri, Apr 29, 2005 at 09:16:27PM +0100, Alan Cox wrote:
> > On Gwe, 2005-04-29 at 05:20, Greg KH wrote:
> > > > Ok thats the bit I needed to know
> > > 
> > > So, do you still object to this patch being accepted?
> > 
> > Switched to CAP_SYS_RAWIO I don't. Its the wrong answer long term I
> > suspect but its definitely a good answer for now.
> 
> Switch it in both capable() calls in the patch?  Kai, is this acceptable
> to you also?
> 
Yes. Using CAP_SYS_ADMIN here was wrong.

-- 
Kai

Re: [06/07] [PATCH] SCSI tape security: require CAP_ADMIN for SG_IO etc.

[Greg KH]

On Sat, Apr 30, 2005 at 08:52:31AM +0300, Kai Makisara wrote:
> On Fri, 29 Apr 2005, Greg KH wrote:
> 
> > On Fri, Apr 29, 2005 at 09:16:27PM +0100, Alan Cox wrote:
> > > On Gwe, 2005-04-29 at 05:20, Greg KH wrote:
> > > > > Ok thats the bit I needed to know
> > > > 
> > > > So, do you still object to this patch being accepted?
> > > 
> > > Switched to CAP_SYS_RAWIO I don't. Its the wrong answer long term I
> > > suspect but its definitely a good answer for now.
> > 
> > Switch it in both capable() calls in the patch?  Kai, is this acceptable
> > to you also?
> > 
> Yes. Using CAP_SYS_ADMIN here was wrong.

Ok, care to send a new patch that I can use for the next -stable kernel
release?

thanks,

greg k-h

Re: [06/07] [PATCH] SCSI tape security: require CAP_ADMIN for SG_IO etc.

[Kai Makisara]

On Fri, 29 Apr 2005, Greg KH wrote:

> On Sat, Apr 30, 2005 at 08:52:31AM +0300, Kai Makisara wrote:
> > On Fri, 29 Apr 2005, Greg KH wrote:
> > 
...
> > > Switch it in both capable() calls in the patch?  Kai, is this acceptable
> > > to you also?
> > > 
> > Yes. Using CAP_SYS_ADMIN here was wrong.
> 
> Ok, care to send a new patch that I can use for the next -stable kernel
> release?
> 
Sent in a different message. This patch does not restrict 
usage of SCSI_IOCTL_START_UNIT and SCSI_IOCTL_STOP_UNIT. For tapes, those 
mean load and unload commands. The drive status changes resulting from 
these commands seem to be caught by st otherwise. I will do a patch for 
-12rc later today or tomorrow. It may add changing some st status bits if 
these commands succeed but that is not -stable material.

Thanks for the review for all participants.

-- 
Kai

[07/07] uml: quick fix syscall table

[Greg KH]

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

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

I'm resending this for inclusion in the -stable tree. I've deleted whitespace
cleanups, and hope this can be merged. I've been asked to split the former
patch, I don't know if I must split again this one, even because I don't want
to split this correct patch into multiple non-correct ones by mistake.

Uml 2.6.11 does not compile with gcc 2.95.4 because some entries are
duplicated, and that GCC does not accept this (unlike gcc 3). Plus various
other bugs in the syscall table definitions, resulting in probable wrong
syscall entries:

  *) 223 is a syscall hole (i.e. ni_syscall) only on i386, on x86_64 it's a
  valid syscall (thus a duplicated one).

  *) __NR_vserver must be only once with sys_ni_syscall, and not multiple
  times with different values!

  *) syscalls duplicated in SUBARCHs and in common files (thus assigning twice
  to the same array entry and causing the GCC 2.95.4 failure mentioned above):
  sys_utimes, which is common, and sys_fadvise64_64, sys_statfs64,
  sys_fstatfs64, which exist only on i386.

  *) syscalls duplicated in each SUBARCH, to put in common files:
  sys_remap_file_pages, sys_utimes, sys_fadvise64

  *) 285 is a syscall hole (i.e. ni_syscall) only on i386, on x86_64 the range
  does not arrive to that point.

  *) on x86_64, the macro name is __NR_kexec_load and not __NR_sys_kexec_load.
  Use the correct name in either case.

Note: as you can see, part of the syscall table definition in UML is
arch-independent (with everywhere defined syscalls), and part is
arch-dependant. This has created confusion (some syscalls are listed in both
places, some in the wrong one, some are wrong on one arch or another).

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---

 clean-linux-2.6.11-paolo/arch/um/include/sysdep-i386/syscalls.h   |   12 +++++-----
 clean-linux-2.6.11-paolo/arch/um/include/sysdep-x86_64/syscalls.h |    5 ----
 clean-linux-2.6.11-paolo/arch/um/kernel/sys_call_table.c          |   11 +++------
 3 files changed, 10 insertions(+), 18 deletions(-)

diff -puN arch/um/include/sysdep-i386/syscalls.h~uml-quick-fix-syscall-table-for-stable arch/um/include/sysdep-i386/syscalls.h
--- clean-linux-2.6.11/arch/um/include/sysdep-i386/syscalls.h~uml-quick-fix-syscall-table-for-stable	2005-04-05 16:56:57.000000000 +0200
+++ clean-linux-2.6.11-paolo/arch/um/include/sysdep-i386/syscalls.h	2005-04-05 16:56:57.000000000 +0200
@@ -23,6 +23,9 @@ extern long sys_mmap2(unsigned long addr
 		      unsigned long prot, unsigned long flags,
 		      unsigned long fd, unsigned long pgoff);
 
+/* On i386 they choose a meaningless naming.*/
+#define __NR_kexec_load __NR_sys_kexec_load
+
 #define ARCH_SYSCALLS \
 	[ __NR_waitpid ] = (syscall_handler_t *) sys_waitpid, \
 	[ __NR_break ] = (syscall_handler_t *) sys_ni_syscall, \
@@ -101,15 +104,12 @@ extern long sys_mmap2(unsigned long addr
 	[ 223 ] = (syscall_handler_t *) sys_ni_syscall, \
 	[ __NR_set_thread_area ] = (syscall_handler_t *) sys_ni_syscall, \
 	[ __NR_get_thread_area ] = (syscall_handler_t *) sys_ni_syscall, \
-	[ __NR_fadvise64 ] = (syscall_handler_t *) sys_fadvise64, \
 	[ 251 ] = (syscall_handler_t *) sys_ni_syscall, \
-        [ __NR_remap_file_pages ] = (syscall_handler_t *) sys_remap_file_pages, \
-	[ __NR_utimes ] = (syscall_handler_t *) sys_utimes, \
-	[ __NR_vserver ] = (syscall_handler_t *) sys_ni_syscall,
-        
+	[ 285 ] = (syscall_handler_t *) sys_ni_syscall,
+
 /* 222 doesn't yet have a name in include/asm-i386/unistd.h */
 
-#define LAST_ARCH_SYSCALL __NR_vserver
+#define LAST_ARCH_SYSCALL 285
 
 /*
  * Overrides for Emacs so that we follow Linus's tabbing style.
diff -puN arch/um/include/sysdep-x86_64/syscalls.h~uml-quick-fix-syscall-table-for-stable arch/um/include/sysdep-x86_64/syscalls.h
--- clean-linux-2.6.11/arch/um/include/sysdep-x86_64/syscalls.h~uml-quick-fix-syscall-table-for-stable	2005-04-05 16:56:57.000000000 +0200
+++ clean-linux-2.6.11-paolo/arch/um/include/sysdep-x86_64/syscalls.h	2005-04-05 16:56:57.000000000 +0200
@@ -71,12 +71,7 @@ extern syscall_handler_t sys_arch_prctl;
 	[ __NR_iopl ] = (syscall_handler_t *) sys_ni_syscall, \
 	[ __NR_set_thread_area ] = (syscall_handler_t *) sys_ni_syscall, \
 	[ __NR_get_thread_area ] = (syscall_handler_t *) sys_ni_syscall, \
-        [ __NR_remap_file_pages ] = (syscall_handler_t *) sys_remap_file_pages, \
 	[ __NR_semtimedop ] = (syscall_handler_t *) sys_semtimedop, \
-	[ __NR_fadvise64 ] = (syscall_handler_t *) sys_fadvise64, \
-	[ 223 ] = (syscall_handler_t *) sys_ni_syscall, \
-	[ __NR_utimes ] = (syscall_handler_t *) sys_utimes, \
-	[ __NR_vserver ] = (syscall_handler_t *) sys_ni_syscall, \
 	[ 251 ] = (syscall_handler_t *) sys_ni_syscall,
 
 #define LAST_ARCH_SYSCALL 251
diff -puN arch/um/kernel/sys_call_table.c~uml-quick-fix-syscall-table-for-stable arch/um/kernel/sys_call_table.c
--- clean-linux-2.6.11/arch/um/kernel/sys_call_table.c~uml-quick-fix-syscall-table-for-stable	2005-04-05 16:56:57.000000000 +0200
+++ clean-linux-2.6.11-paolo/arch/um/kernel/sys_call_table.c	2005-04-05 16:56:57.000000000 +0200
@@ -48,7 +48,6 @@ extern syscall_handler_t sys_vfork;
 extern syscall_handler_t old_select;
 extern syscall_handler_t sys_modify_ldt;
 extern syscall_handler_t sys_rt_sigsuspend;
-extern syscall_handler_t sys_vserver;
 extern syscall_handler_t sys_mbind;
 extern syscall_handler_t sys_get_mempolicy;
 extern syscall_handler_t sys_set_mempolicy;
@@ -242,6 +241,7 @@ syscall_handler_t *sys_call_table[] = {
 	[ __NR_epoll_create ] = (syscall_handler_t *) sys_epoll_create,
 	[ __NR_epoll_ctl ] = (syscall_handler_t *) sys_epoll_ctl,
 	[ __NR_epoll_wait ] = (syscall_handler_t *) sys_epoll_wait,
+	[ __NR_remap_file_pages ] = (syscall_handler_t *) sys_remap_file_pages,
         [ __NR_set_tid_address ] = (syscall_handler_t *) sys_set_tid_address,
 	[ __NR_timer_create ] = (syscall_handler_t *) sys_timer_create,
 	[ __NR_timer_settime ] = (syscall_handler_t *) sys_timer_settime,
@@ -252,12 +252,10 @@ syscall_handler_t *sys_call_table[] = {
 	[ __NR_clock_gettime ] = (syscall_handler_t *) sys_clock_gettime,
 	[ __NR_clock_getres ] = (syscall_handler_t *) sys_clock_getres,
 	[ __NR_clock_nanosleep ] = (syscall_handler_t *) sys_clock_nanosleep,
-	[ __NR_statfs64 ] = (syscall_handler_t *) sys_statfs64,
-	[ __NR_fstatfs64 ] = (syscall_handler_t *) sys_fstatfs64,
 	[ __NR_tgkill ] = (syscall_handler_t *) sys_tgkill,
 	[ __NR_utimes ] = (syscall_handler_t *) sys_utimes,
-	[ __NR_fadvise64_64 ] = (syscall_handler_t *) sys_fadvise64_64,
-	[ __NR_vserver ] = (syscall_handler_t *) sys_vserver,
+	[ __NR_fadvise64 ] = (syscall_handler_t *) sys_fadvise64,
+	[ __NR_vserver ] = (syscall_handler_t *) sys_ni_syscall,
 	[ __NR_mbind ] = (syscall_handler_t *) sys_mbind,
 	[ __NR_get_mempolicy ] = (syscall_handler_t *) sys_get_mempolicy,
 	[ __NR_set_mempolicy ] = (syscall_handler_t *) sys_set_mempolicy,
@@ -267,9 +265,8 @@ syscall_handler_t *sys_call_table[] = {
 	[ __NR_mq_timedreceive ] = (syscall_handler_t *) sys_mq_timedreceive,
 	[ __NR_mq_notify ] = (syscall_handler_t *) sys_mq_notify,
 	[ __NR_mq_getsetattr ] = (syscall_handler_t *) sys_mq_getsetattr,
-	[ __NR_sys_kexec_load ] = (syscall_handler_t *) sys_ni_syscall,
+	[ __NR_kexec_load ] = (syscall_handler_t *) sys_ni_syscall,
 	[ __NR_waitid ] = (syscall_handler_t *) sys_waitid,
-	[ 285 ] = (syscall_handler_t *) sys_ni_syscall,
 	[ __NR_add_key ] = (syscall_handler_t *) sys_add_key,
 	[ __NR_request_key ] = (syscall_handler_t *) sys_request_key,
 	[ __NR_keyctl ] = (syscall_handler_t *) sys_keyctl,
_

_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable

Re: [00/07] -stable review

[Chris Wright]

* Greg KH (gregkh@suse.de) wrote:
> This is the start of the stable review cycle for the 2.6.11.8 release.  There
> are 7 patches in this series, all will be posted as a response to this one.

There are actually 10.  We missed 3 patches from DaveM (100% my fault,
somehow I messed up pushing them into the queue 10 days ago).  Those three
will follow-up shortly as 8/7, 9/7, and 10/7.  Sorry for the mix up.

thanks,
-chris

[08/07] sparc64: Fix copy_siginfo_to_user32()

[Chris Wright]

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

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


Because this routine was not filling in the siginfo
values for si_band and si_fd, this broke applications
trying to actually get at this data.

This makes the sparc64 code in line with PowerPC64's
implementation, which already gets it right.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@osdl.org>
---

===== arch/sparc64/kernel/signal32.c 1.52 vs edited =====
--- 1.52/arch/sparc64/kernel/signal32.c	2005-03-13 15:29:47 -08:00
+++ edited/arch/sparc64/kernel/signal32.c	2005-04-17 14:37:13 -07:00
@@ -192,9 +192,12 @@
 			err |= __put_user(from->si_uid, &to->si_uid);
 			break;
 		case __SI_FAULT >> 16:
-		case __SI_POLL >> 16:
 			err |= __put_user(from->si_trapno, &to->si_trapno);
 			err |= __put_user((unsigned long)from->si_addr, &to->si_addr);
+			break;
+		case __SI_POLL >> 16:
+			err |= __put_user(from->si_band, &to->si_band);
+			err |= __put_user(from->si_fd, &to->si_fd);
 			break;
 		case __SI_RT >> 16: /* This is not generated by the kernel as of now.  */
 		case __SI_MESGQ >> 16:

[09/07] sparc64: use message queue compat syscalls

[Chris Wright]

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

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


A couple message queue system call entries for compat tasks
were not using the necessary compat_sys_*() functions, causing
some glibc test cases to fail.

From: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@osdl.org>
---

===== arch/sparc64/kernel/systbls.S 1.69 vs edited =====
--- 1.69/arch/sparc64/kernel/systbls.S	2005-01-14 11:56:05 -08:00
+++ edited/arch/sparc64/kernel/systbls.S	2005-04-11 15:09:49 -07:00
@@ -75,7 +75,7 @@
 /*260*/	.word compat_sys_sched_getaffinity, compat_sys_sched_setaffinity, sys32_timer_settime, compat_sys_timer_gettime, sys_timer_getoverrun
 	.word sys_timer_delete, sys32_timer_create, sys_ni_syscall, compat_sys_io_setup, sys_io_destroy
 /*270*/	.word sys32_io_submit, sys_io_cancel, compat_sys_io_getevents, sys32_mq_open, sys_mq_unlink
-	.word sys_mq_timedsend, sys_mq_timedreceive, compat_sys_mq_notify, compat_sys_mq_getsetattr, compat_sys_waitid
+	.word compat_sys_mq_timedsend, compat_sys_mq_timedreceive, compat_sys_mq_notify, compat_sys_mq_getsetattr, compat_sys_waitid
 /*280*/	.word sys_ni_syscall, sys_add_key, sys_request_key, sys_keyctl
 
 #endif /* CONFIG_COMPAT */

[10/07] sparc: Fix PTRACE_CONT bogosity

[Chris Wright]

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

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


SunOS aparently had this weird PTRACE_CONT semantic which
we copied.  If the addr argument is something other than
1, it sets the process program counter to whatever that
value is.

This is different from every other Linux architecture, which
don't do anything with the addr and data args.

This difference in particular breaks the Linux native GDB support
for fork and vfork tracing on sparc and sparc64.

There is no interest in running SunOS binaries using this weird
PTRACE_CONT behavior, so just delete it so we behave like other
platforms do.

From: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@osdl.org>
---

===== arch/sparc/kernel/ptrace.c 1.22 vs edited =====
--- 1.22/arch/sparc/kernel/ptrace.c	2005-03-13 15:29:55 -08:00
+++ edited/arch/sparc/kernel/ptrace.c	2005-04-13 22:37:33 -07:00
@@ -531,18 +531,6 @@
 			pt_error_return(regs, EIO);
 			goto out_tsk;
 		}
-		if (addr != 1) {
-			if (addr & 3) {
-				pt_error_return(regs, EINVAL);
-				goto out_tsk;
-			}
-#ifdef DEBUG_PTRACE
-			printk ("Original: %08lx %08lx\n", child->thread.kregs->pc, child->thread.kregs->npc);
-			printk ("Continuing with %08lx %08lx\n", addr, addr+4);
-#endif
-			child->thread.kregs->pc = addr;
-			child->thread.kregs->npc = addr + 4;
-		}
 
 		if (request == PTRACE_SYSCALL)
 			set_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
===== arch/sparc64/kernel/ptrace.c 1.24 vs edited =====
--- 1.24/arch/sparc64/kernel/ptrace.c	2005-02-10 19:06:44 -08:00
+++ edited/arch/sparc64/kernel/ptrace.c	2005-04-16 20:52:21 -07:00
@@ -514,25 +563,6 @@
 			pt_error_return(regs, EIO);
 			goto out_tsk;
 		}
-		if (addr != 1) {
-			unsigned long pc_mask = ~0UL;
-
-			if ((child->thread_info->flags & _TIF_32BIT) != 0)
-				pc_mask = 0xffffffff;
-
-			if (addr & 3) {
-				pt_error_return(regs, EINVAL);
-				goto out_tsk;
-			}
-#ifdef DEBUG_PTRACE
-			printk ("Original: %016lx %016lx\n",
-				child->thread_info->kregs->tpc,
-				child->thread_info->kregs->tnpc);
-			printk ("Continuing with %016lx %016lx\n", addr, addr+4);
-#endif
-			child->thread_info->kregs->tpc = (addr & pc_mask);
-			child->thread_info->kregs->tnpc = ((addr + 4) & pc_mask);
-		}
 
 		if (request == PTRACE_SYSCALL) {
 			set_tsk_thread_flag(child, TIF_SYSCALL_TRACE);

Re: [10/07] sparc: Fix PTRACE_CONT bogosity

[Alan Cox]

On Mer, 2005-04-27 at 19:38, Chris Wright wrote:
> -stable review patch.  If anyone has any objections, please let us know.
> 
> ------------------
> 
> 
> SunOS aparently had this weird PTRACE_CONT semantic which
> we copied.  If the addr argument is something other than
> 1, it sets the process program counter to whatever that
> value is.

7-9 look sane don't see why 10 is a critical issue but then its in arch
specific obscure code and obvious.

Alan

Re: [00/07] -stable review

[Nick Piggin]

Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.11.8 release.  There
> are 7 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.
> 
> These patches are sent out with a number of different people on the Bcc: line.
> If you wish to be a reviewer, please email stable@linux.com to add your name to
> the list.  If you want to be off the reviewer list, also email us.
> 
> Responses should be made by Friday, Apr 29 17:00 UTC.  Anything received after
> that time, might be too late.
> 
> thanks,
> 
> the -stable release team
> 

Wanna take some buffer fixes?

-- 
SUSE Labs, Novell Inc.

Re: [00/07] -stable review

[Chris Wright]

* Nick Piggin (nickpiggin@yahoo.com.au) wrote:
> Wanna take some buffer fixes?

Do they meet the -stable criteria?  If so, please send 'em over.

thanks,
-chris

Re: [00/07] -stable review

[Nick Piggin]

Chris Wright wrote:
> * Nick Piggin (nickpiggin@yahoo.com.au) wrote:
> 
>>Wanna take some buffer fixes?
> 
> 
> Do they meet the -stable criteria?  If so, please send 'em over.
> 

Where do I find the -stable criteria?

They are a little bit tested, reviewed by Andrew Morton.

To me they seem pretty important. But maybe they should wait until
they have at least seen an -mm release.

The first fix I think closes potential access to stale kernel memory
if you care about that sort of thing.

-- 
SUSE Labs, Novell Inc.

Rules about the -stable tree

[Greg KH]

On Thu, Apr 28, 2005 at 11:43:17AM +1000, Nick Piggin wrote:
> Chris Wright wrote:
> >* Nick Piggin (nickpiggin@yahoo.com.au) wrote:
> >
> >>Wanna take some buffer fixes?
> >
> >
> >Do they meet the -stable criteria?  If so, please send 'em over.
> >
> 
> Where do I find the -stable criteria?

Here they are again, I will send a patch that adds them to the kernel
tree.

thanks,

greg k-h

------

Everything you ever wanted to know about Linux 2.6 -stable releases.

Rules on what kind of patches are accepted, and what ones are not, into
the "-stable" tree:

 - It must be obviously correct and tested.
 - It can not bigger than 100 lines, with context.
 - It must fix only one thing.
 - It must fix a real bug that bothers people (not a, "This could be a
   problem..." type thing.)
 - It must fix a problem that causes a build error (but not for things
   marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
   security issue, or some "oh, that's not good" issue.  In short,
   something critical.
 - No "theoretical race condition" issues, unless an explanation of how
   the race can be exploited.
 - It can not contain any "trivial" fixes in it (spelling changes,
   whitespace cleanups, etc.)
 - It must be accepted by the relevant subsystem maintainer.
 - It must be accepted to mainline, or the accepted mainline patch be
   deemed too complex or risky to backport and thus a simple obvious
   alternative fix applied to stable ONLY.
 - It must follow Documentation/SubmittingPatches rules.

Procedure for submitting patches to the -stable tree:

 - Send the patch, after verifying that it follows the above rules, to
   stable@kernel.org.
 - The sender will receive an ack when the patch has been accepted into
   the queue, or a nak if the patch is rejected.  This response might
   take a few days, according to the developer's schedules.
 - If accepted, the patch will be added to the -stable queue, for review
   by other developers.
 - Security patches should not be sent to this alias, but instead to the
   documented security@kernel.org.  
   
Review cycle:

 - When the -stable maintainers decide for a review cycle, the patches
   will be sent to the review committee, and the maintainer of the
   affected area of the patch (unless the submitter is the maintainer of
   the area) and CC: to the linux-kernel mailing list.
 - The review committee has 48 hours in which to ack or nak the patch.
 - If the patch is rejected by a member of the committee, or linux-kernel
   members object to the patch, bringing up issues that the maintainers
   and members did not realize, the patch will be dropped from the
   queue.
 - At the end of the review cycle, the acked patches will be added to
   the latest -stable release, and a new -stable release will happen.
 - Security patches will be accepted into the -stable tree directly from
   the security kernel team, and not go through the normal review cycle.
   Contact the kernel security team for more details on this procedure.

Review committe:

 - This will be made up of a number of kernel developers who have
   volunteered for this task, and a few that haven't.

Re: [00/07] -stable review

[Zwane Mwaikambo]

On Wed, 27 Apr 2005, Chris Wright wrote:

> * Nick Piggin (nickpiggin@yahoo.com.au) wrote:
> > Wanna take some buffer fixes?
> 
> Do they meet the -stable criteria?  If so, please send 'em over.

Shouldn't they see testing time in a tree first?

Re: [00/07] -stable review

[Nick Piggin]

Zwane Mwaikambo wrote:
> On Wed, 27 Apr 2005, Chris Wright wrote:
> 
> 
>>* Nick Piggin (nickpiggin@yahoo.com.au) wrote:
>>
>>>Wanna take some buffer fixes?
>>
>>Do they meet the -stable criteria?  If so, please send 'em over.
> 
> 
> Shouldn't they see testing time in a tree first?
> 

Yes they should.

-- 
SUSE Labs, Novell Inc.

Re: [00/07] -stable review

[Justin M. Forbes]

On Wed, Apr 27, 2005 at 07:51:35PM -0600, Zwane Mwaikambo wrote:
> On Wed, 27 Apr 2005, Chris Wright wrote:
> 
> > * Nick Piggin (nickpiggin@yahoo.com.au) wrote:
> > > Wanna take some buffer fixes?
> > 
> > Do they meet the -stable criteria?  If so, please send 'em over.
> 
> Shouldn't they see testing time in a tree first?

I would say that if they meet the stable criteria, testing time in another
tree is not really necessary.  Stable should be simple bug fixes, easy to
test.  In this case, the fact that Nick seems to think they might need a
run in mm first would tell me that at least some of them probably should
not be in the stable tree at this point.

Justin

Re: [00/07] -stable review

[Gregor Jasny]

Hi Greg, hi Takashi,

I would suggest these two patches for inclusion into the stable tree. They 
both fix a keyboard lockup when unplugging USB audio hardware.

With the first one applied I can plug / unplug my webcam without losing my 
keyboard. I couldn't test the second one, but both patches are in ALSA CVS.

http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/usb/usbaudio.c?r1=1.119&r2=1.120
http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/usb/usx2y/usbusx2y.c?r1=1.9&r2=1.10

Cheers,
Gregor

Re: [stable] Re: [00/07] -stable review

[Greg KH]

On Thu, Apr 28, 2005 at 08:49:53AM +0200, Gregor Jasny wrote:
> Hi Greg, hi Takashi,
> 
> I would suggest these two patches for inclusion into the stable tree. They 
> both fix a keyboard lockup when unplugging USB audio hardware.
> 
> With the first one applied I can plug / unplug my webcam without losing my 
> keyboard. I couldn't test the second one, but both patches are in ALSA CVS.
> 
> http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/usb/usbaudio.c?r1=1.119&r2=1.120
> http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/usb/usx2y/usbusx2y.c?r1=1.9&r2=1.10

Are they in the mainline kernel tree already?

Care to send them individually to the stable@ address, along with full
changelog information and signed-off-by lines?

thanks,

greg k-h