-stable review

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 [email protected] 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

-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.

---

 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
@@ -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,

_

-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

thanks,
-chris

-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

OK, let's drop it.

thanks,
-chris

-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Dropped.

thanks,

greg k-h

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

-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.

@@ -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)

-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?

@@ -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)

@@ -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

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

@@ -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

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

Dmitry

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

Dmitry

-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 <[email protected]>

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.

---

===== fs/partitions/msdos.c 1.26 vs 1.27 =====

@@ -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)) {

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

Am Mittwoch, den 27.04.2005, 22:34 +0200 schrieb Andries Brouwer:

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.

Yes, please do.

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

Andries

Hi!

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

...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         

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

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

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 <[email protected]>

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.

---

 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
@@ -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 */

_

-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.

diff -Naru a/drivers/scsi/st.c b/drivers/scsi/st.c
@@ -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:

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

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

thanks,

greg k-h

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

Valid complaint.

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.

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).

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

Ok thats the bit I needed to know

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.

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

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

thanks,

greg k-h

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

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

thanks,

greg k-h

Yes. Using CAP_SYS_ADMIN here was wrong.

Kai

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

thanks,

greg k-h

...

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

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...

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

-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).

---

 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
@@ -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
@@ -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
@@ -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
[email protected]
http://linux.kernel.org/mailman/listinfo/stable

-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

-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.

---

===== arch/sparc64/kernel/signal32.c 1.52 vs edited =====

@@ -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:

-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" <[email protected]>

---

===== arch/sparc64/kernel/systbls.S 1.69 vs edited =====

@@ -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 */

-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" <[email protected]>

---

===== arch/sparc/kernel/ptrace.c 1.22 vs edited =====

@@ -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 =====

@@ -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);

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

Alan

Wanna take some buffer fixes?

SUSE Labs, Novell Inc.

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

thanks,
-chris

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.

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 [email protected].
- 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 [email protected].

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.

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

Yes they should.

SUSE Labs, Novell Inc.

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

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

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