Ptrace hole / Linux 2.2.25

Ptrace hole / Linux 2.2.25

[Alan Cox]

Vulnerability: CAN-2003-0127

The Linux 2.2 and Linux 2.4 kernels have a flaw in ptrace. This hole allows
local users to obtain full privileges. Remote exploitation of this hole is
not possible. Linux 2.5 is not believed to be vulnerable.

Linux 2.2.25 has been released to correct Linux 2.2. It contains no other
changes. The bug fixes that would have been in 2.2.5pre1 will now appear in
2.2.26pre1. The patch will apply directly to most older 2.2 releases.

A patch for Linux 2.4.20/Linux 2.4.21pre is attached. The patch also
subtly changes the PR_SET_DUMPABLE prctl. We believe this is neccessary and 
that it will not affect any software. The functionality change is specific 
to unusual debugging situations.

We would like to thank Andrzej Szombierski who found the problem, and
wrote an initial patch. Seth Arnold cleaned up the 2.2 change. Arjan van
de Ven and Ben LaHaise identified additional problems with the original 
fix.

Alan

diff -purN linux.orig/arch/alpha/kernel/entry.S linux/arch/alpha/kernel/entry.S
--- linux.orig/arch/alpha/kernel/entry.S	Thu Mar 13 12:01:46 2003
+++ linux/arch/alpha/kernel/entry.S	Thu Mar 13 13:28:49 2003
@@ -231,12 +231,12 @@ kernel_clone:
 .end	kernel_clone
 
 /*
- * kernel_thread(fn, arg, clone_flags)
+ * arch_kernel_thread(fn, arg, clone_flags)
  */
 .align 3
 .globl	kernel_thread
 .ent	kernel_thread
-kernel_thread:
+arch_kernel_thread:
 	ldgp	$29,0($27)	/* we can be called from a module */
 	.frame $30, 4*8, $26
 	subq	$30,4*8,$30
diff -purN linux.orig/arch/arm/kernel/process.c linux/arch/arm/kernel/process.c
--- linux.orig/arch/arm/kernel/process.c	Thu Mar 13 12:01:29 2003
+++ linux/arch/arm/kernel/process.c	Thu Mar 13 13:25:56 2003
@@ -366,7 +366,7 @@ void dump_thread(struct pt_regs * regs, 
  * a system call from a "real" process, but the process memory space will
  * not be free'd until both the parent and the child have exited.
  */
-pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
+pid_t arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
 {
 	pid_t __ret;
 
diff -purN linux.orig/arch/cris/kernel/entry.S linux/arch/cris/kernel/entry.S
--- linux.orig/arch/cris/kernel/entry.S	Thu Mar 13 12:01:29 2003
+++ linux/arch/cris/kernel/entry.S	Thu Mar 13 13:30:30 2003
@@ -736,12 +736,12 @@ hw_bp_trig_ptr:
  * the grosser the code, at least with the gcc version in cris-dist-1.13.
  */
 
-/* int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags) */
+/* int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags) */
 /*                   r10                r11         r12  */
 
 	.text
-	.global kernel_thread
-kernel_thread:
+	.global arch_kernel_thread
+arch_kernel_thread:
 
 	/* Save ARG for later.  */
 	move.d $r11, $r13
diff -purN linux.orig/arch/i386/kernel/process.c linux/arch/i386/kernel/process.c
--- linux.orig/arch/i386/kernel/process.c	Thu Mar 13 12:01:57 2003
+++ linux/arch/i386/kernel/process.c	Thu Mar 13 13:26:08 2003
@@ -495,7 +495,7 @@ void release_segments(struct mm_struct *
 /*
  * Create a kernel thread
  */
-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
 	long retval, d0;
 
@@ -518,6 +518,7 @@ int kernel_thread(int (*fn)(void *), voi
 		 "r" (arg), "r" (fn),
 		 "b" (flags | CLONE_VM)
 		: "memory");
+
 	return retval;
 }
 
diff -purN linux.orig/arch/ia64/kernel/process.c linux/arch/ia64/kernel/process.c
--- linux.orig/arch/ia64/kernel/process.c	Thu Mar 13 12:01:29 2003
+++ linux/arch/ia64/kernel/process.c	Thu Mar 13 13:26:15 2003
@@ -220,7 +220,7 @@ ia64_load_extra (struct task_struct *tas
  *	|                     | <-- sp (lowest addr)
  *	+---------------------+
  *
- * Note: if we get called through kernel_thread() then the memory
+ * Note: if we get called through arch_kernel_thread() then the memory
  * above "(highest addr)" is valid kernel stack memory that needs to
  * be copied as well.
  *
@@ -469,7 +469,7 @@ ia64_set_personality (struct elf64_hdr *
 }
 
 pid_t
-kernel_thread (int (*fn)(void *), void *arg, unsigned long flags)
+arch_kernel_thread (int (*fn)(void *), void *arg, unsigned long flags)
 {
 	struct task_struct *parent = current;
 	int result, tid;
diff -purN linux.orig/arch/m68k/kernel/process.c linux/arch/m68k/kernel/process.c
--- linux.orig/arch/m68k/kernel/process.c	Thu Mar 13 12:01:29 2003
+++ linux/arch/m68k/kernel/process.c	Thu Mar 13 13:26:18 2003
@@ -124,7 +124,7 @@ void show_regs(struct pt_regs * regs)
 /*
  * Create a kernel thread
  */
-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
 	int pid;
 	mm_segment_t fs;
diff -purN linux.orig/arch/mips/kernel/process.c linux/arch/mips/kernel/process.c
--- linux.orig/arch/mips/kernel/process.c	Thu Mar 13 12:01:29 2003
+++ linux/arch/mips/kernel/process.c	Thu Mar 13 13:26:28 2003
@@ -155,7 +155,7 @@ void dump_thread(struct pt_regs *regs, s
 /*
  * Create a kernel thread
  */
-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
 	long retval;
 
diff -purN linux.orig/arch/mips64/kernel/process.c linux/arch/mips64/kernel/process.c
--- linux.orig/arch/mips64/kernel/process.c	Thu Mar 13 12:01:29 2003
+++ linux/arch/mips64/kernel/process.c	Thu Mar 13 13:26:23 2003
@@ -152,7 +152,7 @@ void dump_thread(struct pt_regs *regs, s
 /*
  * Create a kernel thread
  */
-int kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
 {
 	int retval;
 
diff -purN linux.orig/arch/parisc/kernel/process.c linux/arch/parisc/kernel/process.c
--- linux.orig/arch/parisc/kernel/process.c	Fri Feb  9 14:29:44 2001
+++ linux/arch/parisc/kernel/process.c	Thu Mar 13 13:26:36 2003
@@ -118,7 +118,7 @@ void machine_heartbeat(void)
  */
 
 extern pid_t __kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
-pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
+pid_t arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
 {
 
 	/*
diff -purN linux.orig/arch/ppc/kernel/misc.S linux/arch/ppc/kernel/misc.S
--- linux.orig/arch/ppc/kernel/misc.S	Thu Mar 13 12:01:29 2003
+++ linux/arch/ppc/kernel/misc.S	Thu Mar 13 13:32:21 2003
@@ -899,9 +899,9 @@ _GLOBAL(cvt_df)
 
 /*
  * Create a kernel thread
- *   kernel_thread(fn, arg, flags)
+ *   arch_kernel_thread(fn, arg, flags)
  */
-_GLOBAL(kernel_thread)
+_GLOBAL(arch_kernel_thread)
 	mr	r6,r3		/* function */
 	ori	r3,r5,CLONE_VM	/* flags */
 	li	r0,__NR_clone
diff -purN linux.orig/arch/ppc64/kernel/misc.S linux/arch/ppc64/kernel/misc.S
--- linux.orig/arch/ppc64/kernel/misc.S	Thu Mar 13 12:01:30 2003
+++ linux/arch/ppc64/kernel/misc.S	Thu Mar 13 13:29:42 2003
@@ -493,9 +493,9 @@ _GLOBAL(cvt_df)
 
 /*
  * Create a kernel thread
- *   kernel_thread(fn, arg, flags)
+ *   arch_kernel_thread(fn, arg, flags)
  */
-_GLOBAL(kernel_thread)
+_GLOBAL(arch_kernel_thread)
 	mr	r6,r3		/* function */
 	ori	r3,r5,CLONE_VM	/* flags */
 	li	r0,__NR_clone
diff -purN linux.orig/arch/s390/kernel/process.c linux/arch/s390/kernel/process.c
--- linux.orig/arch/s390/kernel/process.c	Thu Mar 13 12:01:30 2003
+++ linux/arch/s390/kernel/process.c	Thu Mar 13 13:26:43 2003
@@ -105,7 +105,7 @@ void show_regs(struct pt_regs *regs)
 		show_trace((unsigned long *) regs->gprs[15]);
 }
 
-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
         int clone_arg = flags | CLONE_VM;
         int retval;
diff -purN linux.orig/arch/s390x/kernel/process.c linux/arch/s390x/kernel/process.c
--- linux.orig/arch/s390x/kernel/process.c	Thu Mar 13 12:01:30 2003
+++ linux/arch/s390x/kernel/process.c	Thu Mar 13 13:26:46 2003
@@ -102,7 +102,7 @@ void show_regs(struct pt_regs *regs)
 		show_trace((unsigned long *) regs->gprs[15]);
 }
 
-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
         int clone_arg = flags | CLONE_VM;
         int retval;
diff -purN linux.orig/arch/sh/kernel/process.c linux/arch/sh/kernel/process.c
--- linux.orig/arch/sh/kernel/process.c	Mon Oct 15 16:36:48 2001
+++ linux/arch/sh/kernel/process.c	Thu Mar 13 13:26:49 2003
@@ -118,7 +118,7 @@ void free_task_struct(struct task_struct
  * This is the mechanism for creating a new kernel thread.
  *
  */
-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {	/* Don't use this in BL=1(cli).  Or else, CPU resets! */
 	register unsigned long __sc0 __asm__ ("r0");
 	register unsigned long __sc3 __asm__ ("r3") = __NR_clone;
diff -purN linux.orig/arch/sparc/kernel/process.c linux/arch/sparc/kernel/process.c
--- linux.orig/arch/sparc/kernel/process.c	Thu Mar 13 12:01:30 2003
+++ linux/arch/sparc/kernel/process.c	Thu Mar 13 13:26:58 2003
@@ -676,7 +676,7 @@ out:
  * a system call from a "real" process, but the process memory space will
  * not be free'd until both the parent and the child have exited.
  */
-pid_t kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+pid_t arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
 	long retval;
 
diff -purN linux.orig/arch/sparc64/kernel/process.c linux/arch/sparc64/kernel/process.c
--- linux.orig/arch/sparc64/kernel/process.c	Thu Mar 13 12:01:30 2003
+++ linux/arch/sparc64/kernel/process.c	Thu Mar 13 13:26:54 2003
@@ -658,7 +658,7 @@ int copy_thread(int nr, unsigned long cl
  * a system call from a "real" process, but the process memory space will
  * not be free'd until both the parent and the child have exited.
  */
-pid_t kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+pid_t arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
 	long retval;
 
diff -purN linux.orig/arch/um/kernel/process_kern.c linux/arch/um/kernel/process_kern.c
--- linux.orig/arch/um/kernel/process_kern.c	Thu Mar 13 12:01:48 2003
+++ linux/arch/um/kernel/process_kern.c	Thu Mar 13 13:27:37 2003
@@ -171,14 +171,14 @@ static int new_thread_proc(void *stack)
 	os_usr1_process(os_getpid());
 }
 
-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
 	int pid;
 
 	current->thread.request.u.thread.proc = fn;
 	current->thread.request.u.thread.arg = arg;
 	pid = do_fork(CLONE_VM | flags, 0, NULL, 0);
-	if(pid < 0) panic("do_fork failed in kernel_thread");
+	if(pid < 0) panic("do_fork failed in arch_kernel_thread");
 	return(pid);
 }
 
diff -purN linux.orig/fs/exec.c linux/fs/exec.c
--- linux.orig/fs/exec.c	Thu Mar 13 12:01:46 2003
+++ linux/fs/exec.c	Thu Mar 13 14:19:08 2003
@@ -559,8 +559,10 @@ int flush_old_exec(struct linux_binprm *
 
 	current->sas_ss_sp = current->sas_ss_size = 0;
 
-	if (current->euid == current->uid && current->egid == current->gid)
+	if (current->euid == current->uid && current->egid == current->gid) {
 		current->mm->dumpable = 1;
+		current->task_dumpable = 1;
+	}
 	name = bprm->filename;
 	for (i=0; (ch = *(name++)) != '\0';) {
 		if (ch == '/')
@@ -952,7 +954,7 @@ int do_coredump(long signr, struct pt_re
 	binfmt = current->binfmt;
 	if (!binfmt || !binfmt->core_dump)
 		goto fail;
-	if (!current->mm->dumpable)
+	if (!is_dumpable(current))
 		goto fail;
 	current->mm->dumpable = 0;
 	if (current->rlim[RLIMIT_CORE].rlim_cur < binfmt->min_coredump)
diff -purN linux.orig/include/asm-alpha/processor.h linux/include/asm-alpha/processor.h
--- linux.orig/include/asm-alpha/processor.h	Fri Oct  5 15:11:05 2001
+++ linux/include/asm-alpha/processor.h	Thu Mar 13 13:35:18 2003
@@ -119,7 +119,7 @@ struct task_struct;
 extern void release_thread(struct task_struct *);
 
 /* Create a kernel thread without removing it from tasklists.  */
-extern long kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
+extern long arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
 
 #define copy_segments(tsk, mm)		do { } while (0)
 #define release_segments(mm)		do { } while (0)
diff -purN linux.orig/include/asm-arm/processor.h linux/include/asm-arm/processor.h
--- linux.orig/include/asm-arm/processor.h	Thu Mar 13 12:01:35 2003
+++ linux/include/asm-arm/processor.h	Thu Mar 13 13:35:18 2003
@@ -117,7 +117,7 @@ extern void __free_task_struct(struct ta
 /*
  * Create a new kernel thread
  */
-extern int kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
 
 #endif
 
diff -purN linux.orig/include/asm-cris/processor.h linux/include/asm-cris/processor.h
--- linux.orig/include/asm-cris/processor.h	Thu Mar 13 12:01:35 2003
+++ linux/include/asm-cris/processor.h	Thu Mar 13 13:35:18 2003
@@ -81,7 +81,7 @@ struct thread_struct {
 #define INIT_THREAD  { \
    0, 0, 0x20 }  /* ccr = int enable, nothing else */
 
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 /* give the thread a program location
  * set user-mode (The 'U' flag (User mode flag) is CCR/DCCR bit 8) 
diff -purN linux.orig/include/asm-i386/processor.h linux/include/asm-i386/processor.h
--- linux.orig/include/asm-i386/processor.h	Thu Mar 13 12:01:57 2003
+++ linux/include/asm-i386/processor.h	Thu Mar 13 13:51:02 2003
@@ -433,7 +433,7 @@ extern void release_thread(struct task_s
 /*
  * create a kernel thread without removing it from tasklists
  */
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 /* Copy and release all segment info associated with a VM */
 extern void copy_segments(struct task_struct *p, struct mm_struct * mm);
diff -purN linux.orig/include/asm-ia64/processor.h linux/include/asm-ia64/processor.h
--- linux.orig/include/asm-ia64/processor.h	Thu Mar 13 12:01:35 2003
+++ linux/include/asm-ia64/processor.h	Thu Mar 13 13:35:18 2003
@@ -476,7 +476,7 @@ struct task_struct;
  * do_basic_setup() and the timing is such that free_initmem() has
  * been called already.
  */
-extern int kernel_thread (int (*fn)(void *), void *arg, unsigned long flags);
+extern int arch_kernel_thread (int (*fn)(void *), void *arg, unsigned long flags);
 
 /* Copy and release all segment info associated with a VM */
 #define copy_segments(tsk, mm)			do { } while (0)
diff -purN linux.orig/include/asm-m68k/processor.h linux/include/asm-m68k/processor.h
--- linux.orig/include/asm-m68k/processor.h	Fri Oct  5 15:11:05 2001
+++ linux/include/asm-m68k/processor.h	Thu Mar 13 13:35:18 2003
@@ -105,7 +105,7 @@ static inline void release_thread(struct
 {
 }
 
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 #define copy_segments(tsk, mm)		do { } while (0)
 #define release_segments(mm)		do { } while (0)
diff -purN linux.orig/include/asm-mips/processor.h linux/include/asm-mips/processor.h
--- linux.orig/include/asm-mips/processor.h	Thu Mar 13 12:01:36 2003
+++ linux/include/asm-mips/processor.h	Thu Mar 13 13:35:18 2003
@@ -186,7 +186,7 @@ struct thread_struct {
 /* Free all resources held by a thread. */
 #define release_thread(thread) do { } while(0)
 
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 /* Copy and release all segment info associated with a VM */
 #define copy_segments(p, mm) do { } while(0)
diff -purN linux.orig/include/asm-mips64/processor.h linux/include/asm-mips64/processor.h
--- linux.orig/include/asm-mips64/processor.h	Thu Mar 13 12:01:36 2003
+++ linux/include/asm-mips64/processor.h	Thu Mar 13 13:35:18 2003
@@ -245,7 +245,7 @@ struct thread_struct {
 /* Free all resources held by a thread. */
 #define release_thread(thread) do { } while(0)
 
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 /* Copy and release all segment info associated with a VM */
 #define copy_segments(p, mm) do { } while(0)
diff -purN linux.orig/include/asm-parisc/processor.h linux/include/asm-parisc/processor.h
--- linux.orig/include/asm-parisc/processor.h	Fri Oct  5 15:11:05 2001
+++ linux/include/asm-parisc/processor.h	Thu Mar 13 13:35:18 2003
@@ -305,7 +305,7 @@ struct task_struct;
 
 /* Free all resources held by a thread. */
 extern void release_thread(struct task_struct *);
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 #define copy_segments(tsk, mm)	do { } while (0)
 #define release_segments(mm)	do { } while (0)
diff -purN linux.orig/include/asm-ppc/processor.h linux/include/asm-ppc/processor.h
--- linux.orig/include/asm-ppc/processor.h	Thu Mar 13 12:01:36 2003
+++ linux/include/asm-ppc/processor.h	Thu Mar 13 13:35:18 2003
@@ -593,7 +593,7 @@ void release_thread(struct task_struct *
 /*
  * Create a new kernel thread.
  */
-extern long kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
+extern long arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
 
 /*
  * Bus types
diff -purN linux.orig/include/asm-ppc64/processor.h linux/include/asm-ppc64/processor.h
--- linux.orig/include/asm-ppc64/processor.h	Thu Mar 13 12:01:36 2003
+++ linux/include/asm-ppc64/processor.h	Thu Mar 13 13:35:18 2003
@@ -609,7 +609,7 @@ void release_thread(struct task_struct *
 /*
  * Create a new kernel thread.
  */
-extern long kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
+extern long arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
 
 /*
  * Bus types
diff -purN linux.orig/include/asm-s390/processor.h linux/include/asm-s390/processor.h
--- linux.orig/include/asm-s390/processor.h	Thu Mar 13 12:01:36 2003
+++ linux/include/asm-s390/processor.h	Thu Mar 13 13:35:18 2003
@@ -113,7 +113,7 @@ struct mm_struct;
 
 /* Free all resources held by a thread. */
 extern void release_thread(struct task_struct *);
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 /* Copy and release all segment info associated with a VM */
 #define copy_segments(nr, mm)           do { } while (0)
diff -purN linux.orig/include/asm-s390x/processor.h linux/include/asm-s390x/processor.h
--- linux.orig/include/asm-s390x/processor.h	Thu Mar 13 12:01:36 2003
+++ linux/include/asm-s390x/processor.h	Thu Mar 13 13:35:18 2003
@@ -127,7 +127,7 @@ struct mm_struct;
 
 /* Free all resources held by a thread. */
 extern void release_thread(struct task_struct *);
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 /* Copy and release all segment info associated with a VM */
 #define copy_segments(nr, mm)           do { } while (0)
diff -purN linux.orig/include/asm-sh/processor.h linux/include/asm-sh/processor.h
--- linux.orig/include/asm-sh/processor.h	Fri Oct  5 15:11:05 2001
+++ linux/include/asm-sh/processor.h	Thu Mar 13 13:35:18 2003
@@ -137,7 +137,7 @@ extern void release_thread(struct task_s
 /*
  * create a kernel thread without removing it from tasklists
  */
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 /*
  * Bus types
diff -purN linux.orig/include/asm-sparc/processor.h linux/include/asm-sparc/processor.h
--- linux.orig/include/asm-sparc/processor.h	Thu Oct 11 02:42:47 2001
+++ linux/include/asm-sparc/processor.h	Thu Mar 13 13:35:18 2003
@@ -146,7 +146,7 @@ extern __inline__ void start_thread(stru
 
 /* Free all resources held by a thread. */
 #define release_thread(tsk)		do { } while(0)
-extern pid_t kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern pid_t arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 
 #define copy_segments(tsk, mm)		do { } while (0)
diff -purN linux.orig/include/asm-sparc64/processor.h linux/include/asm-sparc64/processor.h
--- linux.orig/include/asm-sparc64/processor.h	Thu Mar 13 12:01:36 2003
+++ linux/include/asm-sparc64/processor.h	Thu Mar 13 13:35:18 2003
@@ -270,7 +270,7 @@ do { \
 /* Free all resources held by a thread. */
 #define release_thread(tsk)		do { } while(0)
 
-extern pid_t kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern pid_t arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 #define copy_segments(tsk, mm)		do { } while (0)
 #define release_segments(mm)		do { } while (0)
diff -purN linux.orig/include/linux/sched.h linux/include/linux/sched.h
--- linux.orig/include/linux/sched.h	Thu Mar 13 12:01:57 2003
+++ linux/include/linux/sched.h	Thu Mar 13 13:54:05 2003
@@ -362,6 +362,7 @@ struct task_struct {
 	/* ??? */
 	unsigned long personality;
 	int did_exec:1;
+	unsigned task_dumpable:1;
 	pid_t pid;
 	pid_t pgrp;
 	pid_t tty_old_pgrp;
@@ -485,6 +486,8 @@ struct task_struct {
 #define PT_TRACESYSGOOD	0x00000008
 #define PT_PTRACE_CAP	0x00000010	/* ptracer can follow suid-exec */
 
+#define is_dumpable(tsk)	((tsk)->task_dumpable && (tsk)->mm->dumpable)
+
 /*
  * Limit the stack by to some sane default: root can always
  * increase this limit if needed..  8MB seems reasonable.
@@ -848,6 +851,8 @@ extern void FASTCALL(remove_wait_queue(w
 
 extern void wait_task_inactive(task_t * p);
 extern void kick_if_running(task_t * p);
+extern long kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+
 
 #define __wait_event(wq, condition) 					\
 do {									\
diff -purN linux.orig/kernel/fork.c linux/kernel/fork.c
--- linux.orig/kernel/fork.c	Thu Mar 13 12:01:57 2003
+++ linux/kernel/fork.c	Thu Mar 13 13:51:24 2003
@@ -28,6 +28,7 @@
 #include <asm/pgalloc.h>
 #include <asm/uaccess.h>
 #include <asm/mmu_context.h>
+#include <asm/processor.h>
 
 /* The idle threads do not count.. */
 int nr_threads;
@@ -575,6 +576,31 @@ static inline void copy_flags(unsigned l
 	p->flags = new_flags;
 }
 
+long kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+{
+	struct task_struct *task = current;
+	unsigned old_task_dumpable;
+	long ret;
+
+	/* lock out any potential ptracer */
+	task_lock(task);
+	if (task->ptrace) {
+		task_unlock(task);
+		return -EPERM;
+	}
+
+	old_task_dumpable = task->task_dumpable;
+	task->task_dumpable = 0;
+	task_unlock(task);
+
+	ret = arch_kernel_thread(fn, arg, flags);
+
+	/* never reached in child process, only in parent */
+	current->task_dumpable = old_task_dumpable;
+
+	return ret;
+}
+
 /*
  *  Ok, this is the main fork-routine. It copies the system process
  * information (task[nr]) and sets up the necessary registers. It also
diff -purN linux.orig/kernel/ptrace.c linux/kernel/ptrace.c
--- linux.orig/kernel/ptrace.c	Thu Mar 13 12:01:46 2003
+++ linux/kernel/ptrace.c	Thu Mar 13 13:47:16 2003
@@ -21,6 +21,10 @@
  */
 int ptrace_check_attach(struct task_struct *child, int kill)
 {
+	mb();
+	if (!is_dumpable(child))
+		return -EPERM;
+
 	if (!(child->ptrace & PT_PTRACED))
 		return -ESRCH;
 
@@ -57,7 +61,7 @@ int ptrace_attach(struct task_struct *ta
  	    (current->gid != task->gid)) && !capable(CAP_SYS_PTRACE))
 		goto bad;
 	rmb();
-	if (!task->mm->dumpable && !capable(CAP_SYS_PTRACE))
+	if (!is_dumpable(task) && !capable(CAP_SYS_PTRACE))
 		goto bad;
 	/* the same process cannot be attached many times */
 	if (task->ptrace & PT_PTRACED)
@@ -123,6 +127,8 @@ int access_process_vm(struct task_struct
 	/* Worry about races with exit() */
 	task_lock(tsk);
 	mm = tsk->mm;
+	if (!is_dumpable(tsk) || (&init_mm == mm))
+		mm = NULL;
 	if (mm)
 		atomic_inc(&mm->mm_users);
 	task_unlock(tsk);
diff -purN linux.orig/kernel/sys.c linux/kernel/sys.c
--- linux.orig/kernel/sys.c	Thu Mar 13 12:01:57 2003
+++ linux/kernel/sys.c	Thu Mar 13 13:41:25 2003
@@ -1286,7 +1286,7 @@ asmlinkage long sys_prctl(int option, un
 			error = put_user(current->pdeath_signal, (int *)arg2);
 			break;
 		case PR_GET_DUMPABLE:
-			if (current->mm->dumpable)
+			if (is_dumpable(current))
 				error = 1;
 			break;
 		case PR_SET_DUMPABLE:
@@ -1294,7 +1294,8 @@ asmlinkage long sys_prctl(int option, un
 				error = -EINVAL;
 				break;
 			}
-			current->mm->dumpable = arg2;
+			if (is_dumpable(current))
+				current->mm->dumpable = arg2;
 			break;
 	        case PR_SET_UNALIGN:
 #ifdef SET_UNALIGN_CTL

Re: Ptrace hole / Linux 2.2.25

[Arjan van de Ven]

[-- Attachment #1.1: Type: text/plain, Size: 849 bytes --]

On Mon, 2003-03-17 at 17:04, Alan Cox wrote:
> Vulnerability: CAN-2003-0127
> 
> The Linux 2.2 and Linux 2.4 kernels have a flaw in ptrace. This hole allows
> local users to obtain full privileges. Remote exploitation of this hole is
> not possible. Linux 2.5 is not believed to be vulnerable.
> 
> Linux 2.2.25 has been released to correct Linux 2.2. It contains no other
> changes. The bug fixes that would have been in 2.2.5pre1 will now appear in
> 2.2.26pre1. The patch will apply directly to most older 2.2 releases.
> 
> A patch for Linux 2.4.20/Linux 2.4.21pre is attached. The patch also
> subtly changes the PR_SET_DUMPABLE prctl. We believe this is neccessary and 
> that it will not affect any software. The functionality change is specific 
> to unusual debugging situations.

I've attached a patch against 2.4.21pre5 

[-- Attachment #1.2: ptrace.patch --]
[-- Type: text/x-patch, Size: 25066 bytes --]

diff -urN linux-2.4.21-pre5/arch/alpha/kernel/entry.S linux-2.4.21-pre5.ptrace/arch/alpha/kernel/entry.S
--- linux-2.4.21-pre5/arch/alpha/kernel/entry.S	2002-08-03 02:39:42.000000000 +0200
+++ linux-2.4.21-pre5.ptrace/arch/alpha/kernel/entry.S	2003-03-17 18:52:52.000000000 +0100
@@ -231,12 +231,12 @@
 .end	kernel_clone
 
 /*
- * kernel_thread(fn, arg, clone_flags)
+ * arch_kernel_thread(fn, arg, clone_flags)
  */
 .align 3
 .globl	kernel_thread
 .ent	kernel_thread
-kernel_thread:
+arch_kernel_thread:
 	ldgp	$29,0($27)	/* we can be called from a module */
 	.frame $30, 4*8, $26
 	subq	$30,4*8,$30
diff -urN linux-2.4.21-pre5/arch/arm/kernel/process.c linux-2.4.21-pre5.ptrace/arch/arm/kernel/process.c
--- linux-2.4.21-pre5/arch/arm/kernel/process.c	2002-08-03 02:39:42.000000000 +0200
+++ linux-2.4.21-pre5.ptrace/arch/arm/kernel/process.c	2003-03-17 18:52:52.000000000 +0100
@@ -366,7 +366,7 @@
  * a system call from a "real" process, but the process memory space will
  * not be free'd until both the parent and the child have exited.
  */
-pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
+pid_t arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
 {
 	pid_t __ret;
 
diff -urN linux-2.4.21-pre5/arch/cris/kernel/entry.S linux-2.4.21-pre5.ptrace/arch/cris/kernel/entry.S
--- linux-2.4.21-pre5/arch/cris/kernel/entry.S	2003-03-17 18:51:45.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/arch/cris/kernel/entry.S	2003-03-17 18:52:52.000000000 +0100
@@ -739,12 +739,12 @@
  * the grosser the code, at least with the gcc version in cris-dist-1.13.
  */
 
-/* int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags) */
+/* int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags) */
 /*                   r10                r11         r12  */
 
 	.text
-	.global kernel_thread
-kernel_thread:
+	.global arch_kernel_thread
+arch_kernel_thread:
 
 	/* Save ARG for later.  */
 	move.d $r11, $r13
diff -urN linux-2.4.21-pre5/arch/i386/kernel/process.c linux-2.4.21-pre5.ptrace/arch/i386/kernel/process.c
--- linux-2.4.21-pre5/arch/i386/kernel/process.c	2002-08-03 02:39:42.000000000 +0200
+++ linux-2.4.21-pre5.ptrace/arch/i386/kernel/process.c	2003-03-17 18:52:52.000000000 +0100
@@ -485,7 +485,7 @@
 /*
  * Create a kernel thread
  */
-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
 	long retval, d0;
 
diff -urN linux-2.4.21-pre5/arch/ia64/kernel/process.c linux-2.4.21-pre5.ptrace/arch/ia64/kernel/process.c
--- linux-2.4.21-pre5/arch/ia64/kernel/process.c	2003-03-17 18:51:45.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/arch/ia64/kernel/process.c	2003-03-17 18:52:52.000000000 +0100
@@ -230,7 +230,7 @@
  *	|                     | <-- sp (lowest addr)
  *	+---------------------+
  *
- * Note: if we get called through kernel_thread() then the memory
+ * Note: if we get called through arch_kernel_thread() then the memory
  * above "(highest addr)" is valid kernel stack memory that needs to
  * be copied as well.
  *
@@ -485,7 +485,7 @@
 }
 
 pid_t
-kernel_thread (int (*fn)(void *), void *arg, unsigned long flags)
+arch_kernel_thread (int (*fn)(void *), void *arg, unsigned long flags)
 {
 	struct task_struct *parent = current;
 	int result, tid;
diff -urN linux-2.4.21-pre5/arch/m68k/kernel/process.c linux-2.4.21-pre5.ptrace/arch/m68k/kernel/process.c
--- linux-2.4.21-pre5/arch/m68k/kernel/process.c	2002-08-03 02:39:43.000000000 +0200
+++ linux-2.4.21-pre5.ptrace/arch/m68k/kernel/process.c	2003-03-17 18:52:52.000000000 +0100
@@ -124,7 +124,7 @@
 /*
  * Create a kernel thread
  */
-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
 	int pid;
 	mm_segment_t fs;
diff -urN linux-2.4.21-pre5/arch/mips/kernel/process.c linux-2.4.21-pre5.ptrace/arch/mips/kernel/process.c
--- linux-2.4.21-pre5/arch/mips/kernel/process.c	2002-11-29 00:53:10.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/arch/mips/kernel/process.c	2003-03-17 18:52:52.000000000 +0100
@@ -152,7 +152,7 @@
 /*
  * Create a kernel thread
  */
-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
 	long retval;
 
diff -urN linux-2.4.21-pre5/arch/mips64/kernel/process.c linux-2.4.21-pre5.ptrace/arch/mips64/kernel/process.c
--- linux-2.4.21-pre5/arch/mips64/kernel/process.c	2002-11-29 00:53:10.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/arch/mips64/kernel/process.c	2003-03-17 18:52:52.000000000 +0100
@@ -151,7 +151,7 @@
 /*
  * Create a kernel thread
  */
-int kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
 {
 	int retval;
 
diff -urN linux-2.4.21-pre5/arch/parisc/kernel/process.c linux-2.4.21-pre5.ptrace/arch/parisc/kernel/process.c
--- linux-2.4.21-pre5/arch/parisc/kernel/process.c	2003-03-17 18:51:45.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/arch/parisc/kernel/process.c	2003-03-17 18:52:52.000000000 +0100
@@ -169,7 +169,7 @@
  */
 
 extern pid_t __kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
-pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
+pid_t arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
 {
 
 	/*
diff -urN linux-2.4.21-pre5/arch/ppc/kernel/misc.S linux-2.4.21-pre5.ptrace/arch/ppc/kernel/misc.S
--- linux-2.4.21-pre5/arch/ppc/kernel/misc.S	2003-03-17 18:51:45.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/arch/ppc/kernel/misc.S	2003-03-17 18:52:52.000000000 +0100
@@ -899,9 +899,9 @@
 
 /*
  * Create a kernel thread
- *   kernel_thread(fn, arg, flags)
+ *   arch_kernel_thread(fn, arg, flags)
  */
-_GLOBAL(kernel_thread)
+_GLOBAL(arch_kernel_thread)
 	mr	r6,r3		/* function */
 	ori	r3,r5,CLONE_VM	/* flags */
 	li	r0,__NR_clone
diff -urN linux-2.4.21-pre5/arch/ppc64/kernel/misc.S linux-2.4.21-pre5.ptrace/arch/ppc64/kernel/misc.S
--- linux-2.4.21-pre5/arch/ppc64/kernel/misc.S	2003-03-17 18:51:45.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/arch/ppc64/kernel/misc.S	2003-03-17 18:52:52.000000000 +0100
@@ -481,9 +481,9 @@
 
 /*
  * Create a kernel thread
- *   kernel_thread(fn, arg, flags)
+ *   arch_kernel_thread(fn, arg, flags)
  */
-_GLOBAL(kernel_thread)
+_GLOBAL(arch_kernel_thread)
 	mr	r6,r3		/* function */
 	ori	r3,r5,CLONE_VM	/* flags */
 	li	r0,__NR_clone
diff -urN linux-2.4.21-pre5/arch/s390/kernel/process.c linux-2.4.21-pre5.ptrace/arch/s390/kernel/process.c
--- linux-2.4.21-pre5/arch/s390/kernel/process.c	2003-03-17 18:51:45.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/arch/s390/kernel/process.c	2003-03-17 18:52:52.000000000 +0100
@@ -105,7 +105,7 @@
 		show_trace((unsigned long *) regs->gprs[15]);
 }
 
-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
         int clone_arg = flags | CLONE_VM;
         int retval;
diff -urN linux-2.4.21-pre5/arch/s390x/kernel/process.c linux-2.4.21-pre5.ptrace/arch/s390x/kernel/process.c
--- linux-2.4.21-pre5/arch/s390x/kernel/process.c	2003-03-17 18:51:45.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/arch/s390x/kernel/process.c	2003-03-17 18:52:52.000000000 +0100
@@ -102,7 +102,7 @@
 		show_trace((unsigned long *) regs->gprs[15]);
 }
 
-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
         int clone_arg = flags | CLONE_VM;
         int retval;
diff -urN linux-2.4.21-pre5/arch/sh/kernel/process.c linux-2.4.21-pre5.ptrace/arch/sh/kernel/process.c
--- linux-2.4.21-pre5/arch/sh/kernel/process.c	2001-10-15 22:36:48.000000000 +0200
+++ linux-2.4.21-pre5.ptrace/arch/sh/kernel/process.c	2003-03-17 18:52:52.000000000 +0100
@@ -118,7 +118,7 @@
  * This is the mechanism for creating a new kernel thread.
  *
  */
-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {	/* Don't use this in BL=1(cli).  Or else, CPU resets! */
 	register unsigned long __sc0 __asm__ ("r0");
 	register unsigned long __sc3 __asm__ ("r3") = __NR_clone;
diff -urN linux-2.4.21-pre5/arch/sparc/kernel/process.c linux-2.4.21-pre5.ptrace/arch/sparc/kernel/process.c
--- linux-2.4.21-pre5/arch/sparc/kernel/process.c	2002-08-03 02:39:43.000000000 +0200
+++ linux-2.4.21-pre5.ptrace/arch/sparc/kernel/process.c	2003-03-17 18:52:52.000000000 +0100
@@ -676,7 +676,7 @@
  * a system call from a "real" process, but the process memory space will
  * not be free'd until both the parent and the child have exited.
  */
-pid_t kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+pid_t arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
 	long retval;
 
diff -urN linux-2.4.21-pre5/arch/sparc64/kernel/process.c linux-2.4.21-pre5.ptrace/arch/sparc64/kernel/process.c
--- linux-2.4.21-pre5/arch/sparc64/kernel/process.c	2002-11-29 00:53:12.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/arch/sparc64/kernel/process.c	2003-03-17 18:52:52.000000000 +0100
@@ -673,7 +673,7 @@
  * a system call from a "real" process, but the process memory space will
  * not be free'd until both the parent and the child have exited.
  */
-pid_t kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+pid_t arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
 	long retval;
 
diff -urN linux-2.4.21-pre5/fs/exec.c linux-2.4.21-pre5.ptrace/fs/exec.c
--- linux-2.4.21-pre5/fs/exec.c	2003-03-17 18:52:03.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/fs/exec.c	2003-03-17 18:52:54.000000000 +0100
@@ -576,8 +576,10 @@
 
 	current->sas_ss_sp = current->sas_ss_size = 0;
 
-	if (current->euid == current->uid && current->egid == current->gid)
+	if (current->euid == current->uid && current->egid == current->gid) {
 		current->mm->dumpable = 1;
+		current->task_dumpable = 1;
+	}
 	name = bprm->filename;
 	for (i=0; (ch = *(name++)) != '\0';) {
 		if (ch == '/')
@@ -1085,7 +1087,7 @@
 	binfmt = current->binfmt;
 	if (!binfmt || !binfmt->core_dump)
 		goto fail;
-	if (!current->mm->dumpable)
+	if (!is_dumpable(current))
 		goto fail;
 	current->mm->dumpable = 0;
 	if (current->rlim[RLIMIT_CORE].rlim_cur < binfmt->min_coredump)
diff -urN linux-2.4.21-pre5/include/asm-alpha/processor.h linux-2.4.21-pre5.ptrace/include/asm-alpha/processor.h
--- linux-2.4.21-pre5/include/asm-alpha/processor.h	2001-10-05 21:11:05.000000000 +0200
+++ linux-2.4.21-pre5.ptrace/include/asm-alpha/processor.h	2003-03-17 18:52:58.000000000 +0100
@@ -119,7 +119,7 @@
 extern void release_thread(struct task_struct *);
 
 /* Create a kernel thread without removing it from tasklists.  */
-extern long kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
+extern long arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
 
 #define copy_segments(tsk, mm)		do { } while (0)
 #define release_segments(mm)		do { } while (0)
diff -urN linux-2.4.21-pre5/include/asm-arm/processor.h linux-2.4.21-pre5.ptrace/include/asm-arm/processor.h
--- linux-2.4.21-pre5/include/asm-arm/processor.h	2002-08-03 02:39:45.000000000 +0200
+++ linux-2.4.21-pre5.ptrace/include/asm-arm/processor.h	2003-03-17 18:52:58.000000000 +0100
@@ -117,7 +117,7 @@
 /*
  * Create a new kernel thread
  */
-extern int kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
 
 #endif
 
diff -urN linux-2.4.21-pre5/include/asm-cris/processor.h linux-2.4.21-pre5.ptrace/include/asm-cris/processor.h
--- linux-2.4.21-pre5/include/asm-cris/processor.h	2003-03-17 18:52:04.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/include/asm-cris/processor.h	2003-03-17 18:52:58.000000000 +0100
@@ -81,7 +81,7 @@
 #define INIT_THREAD  { \
    0, 0, 0x20 }  /* ccr = int enable, nothing else */
 
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 /* give the thread a program location
  * set user-mode (The 'U' flag (User mode flag) is CCR/DCCR bit 8) 
diff -urN linux-2.4.21-pre5/include/asm-i386/processor.h linux-2.4.21-pre5.ptrace/include/asm-i386/processor.h
--- linux-2.4.21-pre5/include/asm-i386/processor.h	2002-08-03 02:39:45.000000000 +0200
+++ linux-2.4.21-pre5.ptrace/include/asm-i386/processor.h	2003-03-17 18:52:58.000000000 +0100
@@ -433,7 +433,7 @@
 /*
  * create a kernel thread without removing it from tasklists
  */
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 /* Copy and release all segment info associated with a VM */
 extern void copy_segments(struct task_struct *p, struct mm_struct * mm);
diff -urN linux-2.4.21-pre5/include/asm-ia64/processor.h linux-2.4.21-pre5.ptrace/include/asm-ia64/processor.h
--- linux-2.4.21-pre5/include/asm-ia64/processor.h	2003-03-17 18:52:05.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/include/asm-ia64/processor.h	2003-03-17 18:52:58.000000000 +0100
@@ -372,7 +372,7 @@
  * do_basic_setup() and the timing is such that free_initmem() has
  * been called already.
  */
-extern int kernel_thread (int (*fn)(void *), void *arg, unsigned long flags);
+extern int arch_kernel_thread (int (*fn)(void *), void *arg, unsigned long flags);
 
 /* Copy and release all segment info associated with a VM */
 #define copy_segments(tsk, mm)			do { } while (0)
diff -urN linux-2.4.21-pre5/include/asm-m68k/processor.h linux-2.4.21-pre5.ptrace/include/asm-m68k/processor.h
--- linux-2.4.21-pre5/include/asm-m68k/processor.h	2001-10-05 21:11:05.000000000 +0200
+++ linux-2.4.21-pre5.ptrace/include/asm-m68k/processor.h	2003-03-17 18:52:58.000000000 +0100
@@ -105,7 +105,7 @@
 {
 }
 
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 #define copy_segments(tsk, mm)		do { } while (0)
 #define release_segments(mm)		do { } while (0)
diff -urN linux-2.4.21-pre5/include/asm-mips/processor.h linux-2.4.21-pre5.ptrace/include/asm-mips/processor.h
--- linux-2.4.21-pre5/include/asm-mips/processor.h	2002-11-29 00:53:15.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/include/asm-mips/processor.h	2003-03-17 18:52:58.000000000 +0100
@@ -188,7 +188,7 @@
 /* Free all resources held by a thread. */
 #define release_thread(thread) do { } while(0)
 
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 /* Copy and release all segment info associated with a VM */
 #define copy_segments(p, mm) do { } while(0)
diff -urN linux-2.4.21-pre5/include/asm-mips64/processor.h linux-2.4.21-pre5.ptrace/include/asm-mips64/processor.h
--- linux-2.4.21-pre5/include/asm-mips64/processor.h	2002-11-29 00:53:15.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/include/asm-mips64/processor.h	2003-03-17 18:52:58.000000000 +0100
@@ -231,7 +231,7 @@
 /* Free all resources held by a thread. */
 #define release_thread(thread) do { } while(0)
 
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 /* Copy and release all segment info associated with a VM */
 #define copy_segments(p, mm) do { } while(0)
diff -urN linux-2.4.21-pre5/include/asm-parisc/processor.h linux-2.4.21-pre5.ptrace/include/asm-parisc/processor.h
--- linux-2.4.21-pre5/include/asm-parisc/processor.h	2003-03-17 18:52:05.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/include/asm-parisc/processor.h	2003-03-17 18:52:58.000000000 +0100
@@ -292,7 +292,7 @@
 
 /* Free all resources held by a thread. */
 extern void release_thread(struct task_struct *);
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 extern void map_hpux_gateway_page(struct task_struct *tsk, struct mm_struct *mm);
 
diff -urN linux-2.4.21-pre5/include/asm-ppc/processor.h linux-2.4.21-pre5.ptrace/include/asm-ppc/processor.h
--- linux-2.4.21-pre5/include/asm-ppc/processor.h	2003-03-17 18:52:05.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/include/asm-ppc/processor.h	2003-03-17 18:52:58.000000000 +0100
@@ -622,7 +622,7 @@
 /*
  * Create a new kernel thread.
  */
-extern long kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
+extern long arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
 
 /*
  * Bus types
diff -urN linux-2.4.21-pre5/include/asm-ppc64/processor.h linux-2.4.21-pre5.ptrace/include/asm-ppc64/processor.h
--- linux-2.4.21-pre5/include/asm-ppc64/processor.h	2003-03-17 18:52:06.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/include/asm-ppc64/processor.h	2003-03-17 18:52:58.000000000 +0100
@@ -602,7 +602,7 @@
 /*
  * Create a new kernel thread.
  */
-extern long kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
+extern long arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
 
 /*
  * Bus types
diff -urN linux-2.4.21-pre5/include/asm-s390/processor.h linux-2.4.21-pre5.ptrace/include/asm-s390/processor.h
--- linux-2.4.21-pre5/include/asm-s390/processor.h	2002-08-03 02:39:45.000000000 +0200
+++ linux-2.4.21-pre5.ptrace/include/asm-s390/processor.h	2003-03-17 18:52:58.000000000 +0100
@@ -113,7 +113,7 @@
 
 /* Free all resources held by a thread. */
 extern void release_thread(struct task_struct *);
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 /* Copy and release all segment info associated with a VM */
 #define copy_segments(nr, mm)           do { } while (0)
diff -urN linux-2.4.21-pre5/include/asm-s390x/processor.h linux-2.4.21-pre5.ptrace/include/asm-s390x/processor.h
--- linux-2.4.21-pre5/include/asm-s390x/processor.h	2002-11-29 00:53:15.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/include/asm-s390x/processor.h	2003-03-17 18:52:58.000000000 +0100
@@ -128,7 +128,7 @@
 
 /* Free all resources held by a thread. */
 extern void release_thread(struct task_struct *);
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 /* Copy and release all segment info associated with a VM */
 #define copy_segments(nr, mm)           do { } while (0)
diff -urN linux-2.4.21-pre5/include/asm-sh/processor.h linux-2.4.21-pre5.ptrace/include/asm-sh/processor.h
--- linux-2.4.21-pre5/include/asm-sh/processor.h	2001-10-05 21:11:05.000000000 +0200
+++ linux-2.4.21-pre5.ptrace/include/asm-sh/processor.h	2003-03-17 18:52:58.000000000 +0100
@@ -137,7 +137,7 @@
 /*
  * create a kernel thread without removing it from tasklists
  */
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 /*
  * Bus types
diff -urN linux-2.4.21-pre5/include/asm-sparc/processor.h linux-2.4.21-pre5.ptrace/include/asm-sparc/processor.h
--- linux-2.4.21-pre5/include/asm-sparc/processor.h	2001-10-11 08:42:47.000000000 +0200
+++ linux-2.4.21-pre5.ptrace/include/asm-sparc/processor.h	2003-03-17 18:52:58.000000000 +0100
@@ -146,7 +146,7 @@
 
 /* Free all resources held by a thread. */
 #define release_thread(tsk)		do { } while(0)
-extern pid_t kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern pid_t arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 
 #define copy_segments(tsk, mm)		do { } while (0)
diff -urN linux-2.4.21-pre5/include/asm-sparc64/processor.h linux-2.4.21-pre5.ptrace/include/asm-sparc64/processor.h
--- linux-2.4.21-pre5/include/asm-sparc64/processor.h	2002-08-03 02:39:45.000000000 +0200
+++ linux-2.4.21-pre5.ptrace/include/asm-sparc64/processor.h	2003-03-17 18:52:58.000000000 +0100
@@ -270,7 +270,7 @@
 /* Free all resources held by a thread. */
 #define release_thread(tsk)		do { } while(0)
 
-extern pid_t kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern pid_t arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 #define copy_segments(tsk, mm)		do { } while (0)
 #define release_segments(mm)		do { } while (0)
diff -urN linux-2.4.21-pre5/include/linux/sched.h linux-2.4.21-pre5.ptrace/include/linux/sched.h
--- linux-2.4.21-pre5/include/linux/sched.h	2003-03-17 18:52:08.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/include/linux/sched.h	2003-03-17 18:53:26.000000000 +0100
@@ -162,6 +162,7 @@
 extern void flush_scheduled_tasks(void);
 extern int start_context_thread(void);
 extern int current_is_keventd(void);
+extern long kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 #if CONFIG_SMP
 extern void set_cpus_allowed(struct task_struct *p, unsigned long new_mask);
@@ -345,6 +346,7 @@
 	/* ??? */
 	unsigned long personality;
 	int did_exec:1;
+	unsigned task_dumpable:1;
 	pid_t pid;
 	pid_t pgrp;
 	pid_t tty_old_pgrp;
@@ -454,6 +456,8 @@
 #define PT_TRACESYSGOOD	0x00000008
 #define PT_PTRACE_CAP	0x00000010	/* ptracer can follow suid-exec */
 
+#define is_dumpable(tsk)	((tsk)->task_dumpable && (tsk)->mm->dumpable)
+
 /*
  * Limit the stack by to some sane default: root can always
  * increase this limit if needed..  8MB seems reasonable.
diff -urN linux-2.4.21-pre5/kernel/fork.c linux-2.4.21-pre5.ptrace/kernel/fork.c
--- linux-2.4.21-pre5/kernel/fork.c	2002-11-29 00:53:15.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/kernel/fork.c	2003-03-17 18:52:58.000000000 +0100
@@ -27,6 +27,7 @@
 #include <asm/pgalloc.h>
 #include <asm/uaccess.h>
 #include <asm/mmu_context.h>
+#include <asm/processor.h>
 
 /* The idle threads do not count.. */
 int nr_threads;
@@ -565,6 +566,31 @@
 	p->flags = new_flags;
 }
 
+long kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+{
+	struct task_struct *task = current;
+	unsigned old_task_dumpable;
+	long ret;
+
+	/* lock out any potential ptracer */
+	task_lock(task);
+	if (task->ptrace) {
+		task_unlock(task);
+		return -EPERM;
+	}
+
+	old_task_dumpable = task->task_dumpable;
+	task->task_dumpable = 0;
+	task_unlock(task);
+
+	ret = arch_kernel_thread(fn, arg, flags);
+
+	/* never reached in child process, only in parent */
+	current->task_dumpable = old_task_dumpable;
+
+	return ret;
+}
+
 /*
  *  Ok, this is the main fork-routine. It copies the system process
  * information (task[nr]) and sets up the necessary registers. It also
diff -urN linux-2.4.21-pre5/kernel/ptrace.c linux-2.4.21-pre5.ptrace/kernel/ptrace.c
--- linux-2.4.21-pre5/kernel/ptrace.c	2002-08-03 02:39:46.000000000 +0200
+++ linux-2.4.21-pre5.ptrace/kernel/ptrace.c	2003-03-17 18:52:58.000000000 +0100
@@ -21,6 +21,10 @@
  */
 int ptrace_check_attach(struct task_struct *child, int kill)
 {
+	mb();
+	if (!is_dumpable(child))
+		return -EPERM;
+
 	if (!(child->ptrace & PT_PTRACED))
 		return -ESRCH;
 
@@ -70,7 +74,7 @@
  	    (current->gid != task->gid)) && !capable(CAP_SYS_PTRACE))
 		goto bad;
 	rmb();
-	if (!task->mm->dumpable && !capable(CAP_SYS_PTRACE))
+	if (!is_dumpable(task) && !capable(CAP_SYS_PTRACE))
 		goto bad;
 	/* the same process cannot be attached many times */
 	if (task->ptrace & PT_PTRACED)
@@ -136,6 +140,8 @@
 	/* Worry about races with exit() */
 	task_lock(tsk);
 	mm = tsk->mm;
+	if (!is_dumpable(tsk) || (&init_mm == mm))
+		mm = NULL;
 	if (mm)
 		atomic_inc(&mm->mm_users);
 	task_unlock(tsk);
diff -urN linux-2.4.21-pre5/kernel/sys.c linux-2.4.21-pre5.ptrace/kernel/sys.c
--- linux-2.4.21-pre5/kernel/sys.c	2003-03-17 18:52:08.000000000 +0100
+++ linux-2.4.21-pre5.ptrace/kernel/sys.c	2003-03-17 18:52:58.000000000 +0100
@@ -1238,7 +1238,7 @@
 			error = put_user(current->pdeath_signal, (int *)arg2);
 			break;
 		case PR_GET_DUMPABLE:
-			if (current->mm->dumpable)
+			if (is_dumpable(current))
 				error = 1;
 			break;
 		case PR_SET_DUMPABLE:
@@ -1246,7 +1246,8 @@
 				error = -EINVAL;
 				break;
 			}
-			current->mm->dumpable = arg2;
+			if (is_dumpable(current))
+				current->mm->dumpable = arg2;
 			break;
 
 	        case PR_SET_UNALIGN:

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

re: Ptrace hole / Linux 2.2.25

[Tomas Szepe]

> [arjanv@redhat.com]
> 
> I've attached a patch against 2.4.21pre5.

So what happens now?

Is this critical enough for 2.4.21 to go out?  Or can it wait like
some other fairly serious stuff such as the ext3 fixes?  What about
the current state of IDE?

Would it make sense to repackage 2.4.20 into something like 2.4.20-p1
or 2.4.20.1 with only the critical stuff applied?

-- 
Tomas Szepe <szepe@pinerecords.com>

re: Ptrace hole / Linux 2.2.25

[James Bourne]

On Mon, 17 Mar 2003, Tomas Szepe wrote:

> > [arjanv@redhat.com]
> > 
> > I've attached a patch against 2.4.21pre5.
> 
> So what happens now?
> 
> Is this critical enough for 2.4.21 to go out?  Or can it wait like
> some other fairly serious stuff such as the ext3 fixes?  What about
> the current state of IDE?
> 
> Would it make sense to repackage 2.4.20 into something like 2.4.20-p1
> or 2.4.20.1 with only the critical stuff applied?

FYI, I am currently testing Alans patch (cleaned up, the original does not
patch cleanly) against 2.4.20 proper.

I can make this available if requested once I know it compiles and boots...

Regards
James Bourne

-- 
James Bourne, Supervisor Data Centre Operations
Mount Royal College, Calgary, AB, CA
www.mtroyal.ab.ca

******************************************************************************
This communication is intended for the use of the recipient to which it is
addressed, and may contain confidential, personal, and or privileged
information. Please contact the sender immediately if you are not the
intended recipient of this communication, and do not copy, distribute, or
take action relying on it. Any communication received in error, or
subsequent reply, should be deleted or destroyed.
******************************************************************************


"There are only 10 types of people in this world: those who
understand binary and those who don't."

Re: Ptrace hole / Linux 2.2.25

[Jeff Garzik]

On Mon, Mar 17, 2003 at 07:20:40PM +0100, Tomas Szepe wrote:
> > [arjanv@redhat.com]
> > 
> > I've attached a patch against 2.4.21pre5.
> 
> So what happens now?
> 
> Is this critical enough for 2.4.21 to go out?  Or can it wait like
> some other fairly serious stuff such as the ext3 fixes?  What about
> the current state of IDE?
> 
> Would it make sense to repackage 2.4.20 into something like 2.4.20-p1
> or 2.4.20.1 with only the critical stuff applied?

There shouldn't be a huge need to rush 2.4.21 as-is, really.  If you
want an immediate update, get the fix from your vendor.

Plus, it's a local root hole, and there are still tons of those left
out there to squash.

	Jeff

Re: Ptrace hole / Linux 2.2.25

[Pavel Machek]

Hi!

> > Would it make sense to repackage 2.4.20 into something like 2.4.20-p1
> > or 2.4.20.1 with only the critical stuff applied?
> 
> There shouldn't be a huge need to rush 2.4.21 as-is, really.  If you
> want an immediate update, get the fix from your vendor.

Many people are using self-compiled
kernels and it would be better to have
2.4.21 out than having each person
apply slightly different patch...

> Plus, it's a local root hole, and there are still tons of those left
> out there to squash.

Really? Care to name a few?
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...

Re: Ptrace hole / Linux 2.2.25

[Stephan von Krawczynski]

On Fri, 21 Mar 2003 22:17:08 +0100
Pavel Machek <pavel@ucw.cz> wrote:

> Hi!
> 
> > > Would it make sense to repackage 2.4.20 into something like 2.4.20-p1
> > > or 2.4.20.1 with only the critical stuff applied?
> > 
> > There shouldn't be a huge need to rush 2.4.21 as-is, really.  If you
> > want an immediate update, get the fix from your vendor.

Sorry Jeff,

this comment must obviously be flagged with a big community-buh. It is very
likely that most readers of LKML read/write here _not_ because they are
looking for a _vendor_ specific thing, but because they feel to a certain
extent as part of a linux-community and (partly) want to give something back
for the good things they got from it.
It is no hot news over here that linux does _not_ live because of 5 different
(or more?) "vendor"-kernels, but solely because there is _the_ official
kernel.org kernel (releases). 
For me personally I must say there is nothing I care less about than a
vendor-kernel - not because I think they are doing a bad job _in general_, but
because they are expected to be _less_ tested than "official" releases.
My favourite vendor (which I won't name here) managed to create a kernel that
does not even completely boot on about 8 of 10 of my test-beds. And guess what:
replacing the patched-to-death vendor kernel with kernel.org release makes all
of them work (at least boot correctly).

So IMHO: if there is a-known-to-work patch for the discussed exploit it should
be released as _some_ (pre-)release for 2.4 quickly, and thanks must go to alan
for taking quick approach on 2.2.

-- 
Regards,
Stephan

Re: Ptrace hole / Linux 2.2.25

[Jeff Garzik]

Stephan von Krawczynski wrote:
> On Fri, 21 Mar 2003 22:17:08 +0100
> Pavel Machek <pavel@ucw.cz> wrote:
> 
> 
>>Hi!
>>
>>
>>>>Would it make sense to repackage 2.4.20 into something like 2.4.20-p1
>>>>or 2.4.20.1 with only the critical stuff applied?
>>>
>>>There shouldn't be a huge need to rush 2.4.21 as-is, really.  If you
>>>want an immediate update, get the fix from your vendor.
> 
> 
> Sorry Jeff,
> 
> this comment must obviously be flagged with a big community-buh. It is very
> likely that most readers of LKML read/write here _not_ because they are
> looking for a _vendor_ specific thing, but because they feel to a certain
> extent as part of a linux-community and (partly) want to give something back
> for the good things they got from it.
> It is no hot news over here that linux does _not_ live because of 5 different
> (or more?) "vendor"-kernels, but solely because there is _the_ official
> kernel.org kernel (releases). 
[...]
> So IMHO: if there is a-known-to-work patch for the discussed exploit it should
> be released as _some_ (pre-)release for 2.4 quickly, and thanks must go to alan
> for taking quick approach on 2.2.


I think you misunderstand my point:  there was a patch posted which 
fixes the ptrace issue.  If you want to fix your kernel, there are two 
options:  either you are capable enough apply that patch yourself, 
otherwise get a kernel update from a vendor.  Marcelo is under no 
obligation to provide hot-fix kernels...

As for Alan, his task was easier:  Guess how many patches are in 2.2.25? 
  One.  ;-)

	Jeff

Re: Ptrace hole / Linux 2.2.25

[Petr Baudis]

Dear diary, on Sun, Mar 23, 2003 at 02:41:47PM CET, I got a letter,
where Jeff Garzik <jgarzik@pobox.com> told me, that...
> Stephan von Krawczynski wrote:
> >On Fri, 21 Mar 2003 22:17:08 +0100
> >Pavel Machek <pavel@ucw.cz> wrote:
> >
> >
> >>Hi!
> >>
> >>
> >>>>Would it make sense to repackage 2.4.20 into something like 2.4.20-p1
> >>>>or 2.4.20.1 with only the critical stuff applied?
> >>>
> >>>There shouldn't be a huge need to rush 2.4.21 as-is, really.  If you
> >>>want an immediate update, get the fix from your vendor.
> >
> >
> >Sorry Jeff,
> >
> >this comment must obviously be flagged with a big community-buh. It is very
> >likely that most readers of LKML read/write here _not_ because they are
> >looking for a _vendor_ specific thing, but because they feel to a certain
> >extent as part of a linux-community and (partly) want to give something 
> >back
> >for the good things they got from it.
> >It is no hot news over here that linux does _not_ live because of 5 
> >different
> >(or more?) "vendor"-kernels, but solely because there is _the_ official
> >kernel.org kernel (releases). 
> [...]
> >So IMHO: if there is a-known-to-work patch for the discussed exploit it 
> >should
> >be released as _some_ (pre-)release for 2.4 quickly, and thanks must go to 
> >alan
> >for taking quick approach on 2.2.
> 
> 
> I think you misunderstand my point:  there was a patch posted which 
> fixes the ptrace issue.  If you want to fix your kernel, there are two 
> options:  either you are capable enough apply that patch yourself, 
> otherwise get a kernel update from a vendor.  Marcelo is under no 
> obligation to provide hot-fix kernels...

Just out of curiosity, Marcelo, when could we see 2.4.21-rc1 ? What is yet
expected to go in before rc, and how long it could take to have 2.4.21 final
out given that no other critical bugs would be discovered?

The release cycle is probably getting indeed kind of ... long; that could be ok
for ie. 2.2, but it would be nice to have shorter development cycle for the
pair of latest two development lines. Sure that the larger changes need to get
enough of testing, but then we could maybe spend the months rather between the
-rc releases than both -pre and -rc releases...?

Thanks in advance,

-- 
 
				Petr "Pasky" Baudis
.
The pure and simple truth is rarely pure and never simple.
		-- Oscar Wilde
.
Stuff: http://pasky.ji.cz/

Re: Ptrace hole / Linux 2.2.25

[Martin Mares]

Hi Jeff!

> I think you misunderstand my point:  there was a patch posted which 
> fixes the ptrace issue.  If you want to fix your kernel, there are two 
> options:  either you are capable enough apply that patch yourself, 
> otherwise get a kernel update from a vendor.

Sorry, but you seem to forget that a significant amount of people use
kernel.org kernels, but don't monitor LKML nor are able to choose from
the various patches floating there the most appropriate fix.

If 2.4.21 were expected in a few days, it would make sense to delay the
fix, but this doesn't seem to be the case, so I think that a hot-fix
really should be released quickly (either as 2.4.20.1 or 2.4.21)

> As for Alan, his task was easier:  Guess how many patches are in 2.2.25? 
>  One.  ;-)

And why couldn't it be the same for 2.4.21?

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
The better the better, the better the bet.

Re: Ptrace hole / Linux 2.2.25

[Alan Cox]

> Sorry, but you seem to forget that a significant amount of people use
> kernel.org kernels, but don't monitor LKML nor are able to choose from
> the various patches floating there the most appropriate fix.

Thats not my problem is it. There are vendors, there are free
distributions too. 

Alan

Re: Ptrace hole / Linux 2.2.25

[Martin Mares]

> Thats not my problem is it.

It probably isn't -- my mail was a reply to Jeff :-)

> There are vendors, there are free distributions too. 

Yes, but that's pretty irrelevant. People should not depend on such
sources to get security fixes. Anything so critical should be included
in the official kernel as soon as possible -- any reasons against?

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Not all rumors are as misleading as this one.

Re: Ptrace hole / Linux 2.2.25

[Alan Cox]

> Yes, but that's pretty irrelevant. People should not depend on such
> sources to get security fixes. Anything so critical should be included
> in the official kernel as soon as possible -- any reasons against?

Several
-	We aren't about to release an official kernel right now afaik,
	there are bugs left to sort out first
-	Anyone can apply the patch themselves
-	Anyone can go and get a vendor kernel
-	Anyone can go and release their own 2.4.20.1 or 2.4.20-sec or
	whatever if they feel strongly about it

Just go do it. If someone wants to be a contact point for build existing
base kernels + published security fix trees I'm pretty sure kernel.org
would host them too.

Alan

Re: Ptrace hole / Linux 2.2.25

[Martin Mares]

Hi Alan!

> Several
> -	We aren't about to release an official kernel right now afaik,
> 	there are bugs left to sort out first

But these patches can be easily postponed to the next release and now
we can release just the bug fix as you did in the 2.2 series.

> -	Anyone can apply the patch themselves
> -	Anyone can go and get a vendor kernel
> -	Anyone can go and release their own 2.4.20.1 or 2.4.20-sec or
> 	whatever if they feel strongly about it

No, I asked you for reasons against, you gave me (except for the first
point) just reasons why it won't hurt too much.

Do you really think that "People should either use vendor kernels or
read LKML and be able to gather the fixes from there themselves" is a
good strategy?

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Next lecture on time travel will be held on previous Monday.

Re: Ptrace hole / Linux 2.2.25

[Robert Love]

On Sun, 2003-03-23 at 14:44, Martin Mares wrote:

> Do you really think that "People should either use vendor kernels or
> read LKML and be able to gather the fixes from there themselves" is a
> good strategy?

Yes, I suspect he does as do most people here.

If you do not use a vendor kernel then you assume the responsibility of
doing this stuff yourself.  If you do not want to worry about these
things, use a vendor kernel.

	Robert Love

Re: Ptrace hole / Linux 2.2.25

[Henrik Persson]

On 23 Mar 2003 14:47:19 -0500
Robert Love <rml@tech9.net> wrote:

> If you do not use a vendor kernel then you assume the responsibility of
> doing this stuff yourself.  If you do not want to worry about these
> things, use a vendor kernel.

Almost all of the people I know who are running Linux are compiling their
own kernels fetched from kernel.org and very few of them are tracking
LKML, so even if they should, they aren't.

Would it really hurt that much to release 2.4.21 with the ptracefix(es)?

If it hurts that much, can kernel.org put out a brief message and a link
to the relevant patches somewhere so that people who doesn't follow LKML
can find the patches without browsing the ML-archives?

-- 
Henrik Persson  nix@socialism.nu  http://nix.badanka.com
PGP-key: http://nix.badanka.com/pgp  PGP-KeyID: 0x43B68116  

Re: Ptrace hole / Linux 2.2.25

[Robert Love]

On Sun, 2003-03-23 at 14:55, Henrik Persson wrote:

> Would it really hurt that much to release 2.4.21 with the
> ptracefix(es)?

No, it would not.  But the point is Marcelo does not need to.  If he and
other kernel developers feel this course of action is better warranted,
then that is fine.

Users should rely on their vendors if they cannot rely on themselves.

Note that personally, I probably would of released a 2.4.21 with just
the ptrace security fix applied, as Alan did for 2.2.  But I am neither
Alan nor Marcelo, and the actions they both picked are OK.

	Robert Love

Re: Ptrace hole / Linux 2.2.25

[Henrik Persson]

On Sun, 23 Mar 2003 20:55:31 +0100
Henrik Persson <nix@socialism.nu> wrote:

> Would it really hurt that much to release 2.4.21 with the ptracefix(es)?

Or would it hurt to release -pre6 like..right now with the fixes in it?

This combined with a small notice on kernel.org would most certainly
satisfy me, but as for now I had to browse trough the archives cause I
deleted the mail with the patch by accident, and that's not very optimal,
is it?

-- 
Henrik Persson  nix@socialism.nu  http://nix.badanka.com
PGP-key: http://nix.badanka.com/pgp  PGP-KeyID: 0x43B68116  

Re: Ptrace hole / Linux 2.2.25

[Martin Mares]

Hello!

> Yes, I suspect he does as do most people here.
> 
> If you do not use a vendor kernel then you assume the responsibility of
> doing this stuff yourself.  If you do not want to worry about these
> things, use a vendor kernel.

But if you assume this, what are the official releases for anyway?

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"God doesn't play dice."    -- Albert Einstein

Re: Ptrace hole / Linux 2.2.25

[Russell King]

On Sun, Mar 23, 2003 at 08:56:06PM +0100, Martin Mares wrote:
> > Yes, I suspect he does as do most people here.
> > 
> > If you do not use a vendor kernel then you assume the responsibility of
> > doing this stuff yourself.  If you do not want to worry about these
> > things, use a vendor kernel.
> 
> But if you assume this, what are the official releases for anyway?

It is the way Linux is heading - becoming less free.  Lock-in to
distribution vendors.  And soon you'll need to pay distributions
to (timely) get the fixes.

To give an instance, because I don't work for a distribution, I don't
have access to the security lists.  Yet, I'm the guy who produces the
ARM patches which the ARM community at large use.

This situation caused HP to shut down their public ARM boxen while I
worked on integrating the security fix into the ARM tree.  Unfortunately,
this could only happen _after_ the problem was publically announced,
which means some of HPs systems were vulnerable to attack for a few
days.

If you think Linux today is about something "free"...

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Ptrace hole / Linux 2.2.25

[Alan Cox]

On Sun, 2003-03-23 at 20:08, Russell King wrote:
> To give an instance, because I don't work for a distribution, I don't
> have access to the security lists.  Yet, I'm the guy who produces the
> ARM patches which the ARM community at large use.

So apply to join vendor-sec.

Alan

Re: Ptrace hole / Linux 2.2.25

[Robert Love]

On Sun, 2003-03-23 at 14:56, Martin Mares wrote:

> But if you assume this, what are the official releases for anyway?

Well, official releases have always been sort of arbitrary for the
kernel... just labeled releases along the course of development. 
Although with the recent addition of the -rc patches, they tend to
ensure the latest round of development at least resulted in a stable
release.  But look at all the major vendors - their 2.4.18 release, for
example, may include whatever the latest pre-patch was at the time.

Anyhow, to answer your question: the official releases are labels along
the course of development for use by vendors, developers, and users who
(as Alan described) can manage their own kernels.

Do not get me wrong, I think users can and should compile their own
kernel if they want.  And as kernel developers, we should facilitate
that.  But if someone requires handholding and instant or controlled
releases of bug fixes, they either need to be able to rely on their own
ability to get them or their vendor.  We have vendors for a reason,
after all.

	Robert Love

Re: Ptrace hole / Linux 2.2.25

[Martin J. Bligh]

>> But if you assume this, what are the official releases for anyway?
> 
> Well, official releases have always been sort of arbitrary for the
> kernel... just labeled releases along the course of development. 
> Although with the recent addition of the -rc patches, they tend to
> ensure the latest round of development at least resulted in a stable
> release.  But look at all the major vendors - their 2.4.18 release, for
> example, may include whatever the latest pre-patch was at the time.

I don't agree that's always been true by any means. It may currently
be true, but that's far from a good thing. The current state of divergance
the distros have from mainline 2.4 is IMHO the biggest problem Linux has
today.

The distros inherently have a conflict of interest getting changes merged
back into mainline ... it's time consuming to do, it provides them no real
benefit (they have to maintain their huge trees anyway), and it actively
damages the "value add" they provide.
 
> Anyhow, to answer your question: the official releases are labels along
> the course of development for use by vendors, developers, and users who
> (as Alan described) can manage their own kernels.
> 
> Do not get me wrong, I think users can and should compile their own
> kernel if they want.  And as kernel developers, we should facilitate
> that.  But if someone requires handholding and instant or controlled
> releases of bug fixes, they either need to be able to rely on their own
> ability to get them or their vendor.  We have vendors for a reason,
> after all.

If that's people's attitude ("you should use a vendor"), then we need a 
2.4-fixed tree to be run by somebody with an interest in providing 
critical bugfixes to the community with no distro ties. People may be
perfectly capable of finding, applying, and collecting their own patches,
but that's no reason to make it difficult.

M.

Re: Ptrace hole / Linux 2.2.25

[Pavel Machek]

Hi!

> > Do not get me wrong, I think users can and should compile their own
> > kernel if they want.  And as kernel developers, we should facilitate
> > that.  But if someone requires handholding and instant or controlled
> > releases of bug fixes, they either need to be able to rely on their own
> > ability to get them or their vendor.  We have vendors for a reason,
> > after all.
> 
> If that's people's attitude ("you should use a vendor"), then we
> need a 

I believe sentence "you should use a vendor kernel" schould be banned
on this list ;-).

How badly would releasing 2.4.21 which does not have 2.4.20-preX as a
parent mess version control systems?  
								Pavel
-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.

Re: Ptrace hole / Linux 2.2.25

[Martin Hermanowski]

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

On Sun, Mar 23, 2003 at 09:36:28PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > Do not get me wrong, I think users can and should compile their own
> > > kernel if they want.  And as kernel developers, we should facilitate
> > > that.  But if someone requires handholding and instant or controlled
> > > releases of bug fixes, they either need to be able to rely on their own
> > > ability to get them or their vendor.  We have vendors for a reason,
> > > after all.
> > 
> > If that's people's attitude ("you should use a vendor"), then we
> > need a 
> 
> I believe sentence "you should use a vendor kernel" schould be banned
> on this list ;-).

ACK ;-)

> How badly would releasing 2.4.21 which does not have 2.4.20-preX as a
> parent mess version control systems?  

I guess this would make problems with the incremental patches.

I think putting an official patch for 2.4.20 closing the ptrace hole on
www.kernel.org should be no problem, and people compiling the kernel
themselves could easily use a correctly patched kernel. The main problem
(IMHO) is finding the correct patch. Even a link to the mail in the
archive might be sufficient.

(I hope this has not been suggested before, I was unsubsribed to lkml
for some days)

Regards,
Martin

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Ptrace hole / Linux 2.2.25

[James Bourne]

On Sun, 23 Mar 2003, Pavel Machek wrote:

> Hi!
> 
...
> > If that's people's attitude ("you should use a vendor"), then we
> > need a 
> 
> I believe sentence "you should use a vendor kernel" schould be banned
> on this list ;-).
> 
> How badly would releasing 2.4.21 which does not have 2.4.20-preX as a
> parent mess version control systems?  

I shouldn't step in this but I am going to anyway.  BTW, the first 2 bits is
my opinion and can be discarded or whatever, not directed at anyone in
particular.

<subjectiveopinion>
First, I do agree with Alan, it's not his (or Marcelos'/Linus'/pick
your favorite kernel maintainer) problem if you choose not to go
with a vendor kernel.  I choose not to go with vendor kernels, primarily
because since days long past, when I started admining Linux
systems, the vendor kernels were not the most stable ones...  Times change
but habits are more difficult to.  That is why you can download the ptrace
patch from my personal website (http://www.hardrock.org/kernel/2.4.20/).
If you can't do it, or are not willing to stick your neck out to do it,
then use a vendor kernel and don't complain about the release cycle...

Second, the current patch isn't quite right.  It blocks even root from
tracing a process if needed and breaks chroot'ing from what I hear.
Including this as a release for 2.4.21 would be the "Wrong Thing" to do.
Could you imagine releasing something that breaks applications which require
these things to work as a "release" kernel?  Bad karma there...
</subjectiveopinion>

I do already host patches for current kernels which I use at work.  What
about just keeping a combined security and fixup patch set for the current
tree available for people to download and apply with instructions on doing
so and an index of what the patch contains and why? 

Given that the patches come from reputable sources (for example the ext3
patches for 2.4.20 and the ptrace patch) they can be
included without too much thought and some testing.  I could
maintain this, and it could be available either on kernel.org or just from
my website, no matter either way.  As I said, I'm already doing this so it
wouldn't be a huge bother anyway.

If anyone wants this to happen, let me know as it will then happen... 
Otherwise I'll continue to do it as I am now anyway, and everyone
is welcome to use this source for patches to the current tree.

Regards,
James Bourne



> 								Pavel

-- 
James Bourne, Supervisor Data Centre Operations
Mount Royal College, Calgary, AB, CA
www.mtroyal.ab.ca

"There are only 10 types of people in this world: those who
understand binary and those who don't."

Re: Ptrace hole / Linux 2.2.25

[Martin J. Bligh]

> I do already host patches for current kernels which I use at work.  What
> about just keeping a combined security and fixup patch set for the current
> tree available for people to download and apply with instructions on doing
> so and an index of what the patch contains and why? 
> 
> Given that the patches come from reputable sources (for example the ext3
> patches for 2.4.20 and the ptrace patch) they can be
> included without too much thought and some testing.  I could
> maintain this, and it could be available either on kernel.org or just from
> my website, no matter either way.  As I said, I'm already doing this so it
> wouldn't be a huge bother anyway.
> 
> If anyone wants this to happen, let me know as it will then happen... 
> Otherwise I'll continue to do it as I am now anyway, and everyone
> is welcome to use this source for patches to the current tree.

I think this would be valuable .. the other thing that really needs to
be present is a "common vendor" kernel where changes that are common
to most distros are merged (eg O(1) scheduler, etc). Personally, I think 
that's what mainline should be doing ... but if other people disagree,
then I, at least, would see value in a separate tree to do this.

M.

Re: Ptrace hole / Linux 2.2.25

[Jeff Garzik]

Martin J. Bligh wrote:
> I think this would be valuable .. the other thing that really needs to
> be present is a "common vendor" kernel where changes that are common
> to most distros are merged (eg O(1) scheduler, etc). Personally, I think 
> that's what mainline should be doing ... but if other people disagree,
> then I, at least, would see value in a separate tree to do this.



akpm has suggested something like this in the past.  I respectfully 
disagree.

The 2.4 kernel will not benefit from constant churn of backporting core 
kernel changes like a new scheduler.  We need to let it settle, simply 
get it stable, and concentrate on fixing key problems in 2.6.  Otherwise 
you will never have a stable 2.4 tree, and it will look suspiciously 
more and more like 2.6 as time goes by.  Constantly breaking working 
configurations and changing core behaviors is _not_ the way to go for 2.4.

I see 2.4 O(1) scheduler and similar features as _pain_ brought on the 
vendors by themselves (and their customers).

Surely it is better to concentrate developer time and mindshare on 
making 2.6 sane?

	Jeff

Re: Ptrace hole / Linux 2.2.25

[James Bourne]

On Sun, 23 Mar 2003, Jeff Garzik wrote:

> Martin J. Bligh wrote:
> > I think this would be valuable .. the other thing that really needs to
> > be present is a "common vendor" kernel where changes that are common
> > to most distros are merged (eg O(1) scheduler, etc). Personally, I think 
> > that's what mainline should be doing ... but if other people disagree,
> > then I, at least, would see value in a separate tree to do this.
> 
> akpm has suggested something like this in the past.  I respectfully 
> disagree.

I also disagree.  Although it would be nice, it's not practical.  What
people want is strictly fixes and security related patches, and that
is ALL I propose to want to include.  Perhaps if the vendors
want a "common vendor" patch they could maintain it? ;)

So, to that end, I have made available:
(URL is http://www.hardrock.org/kernel/current-updates/)

linux-2.4.20-updates.patch: Contains all three patches below.  For the 
        primary fixes needed in the current release kernel.

Individual patches:
linux-2.4.20-ext3.patch: Fixes for ext3 data=journal umount patch, sync-fix
        patch, and use-after-free patch from Andrew Morton <akpm@digeo.com>.

linux-2.4.20-ptrace.patch: Alan Cox relased a patch against 2.4.20 which
        did not apply cleanly (perhaps it was his -ac tree).  This will
        apply cleanly and compile under i386 to the clean 2.4.20 source
        tree.

linux-2.4.20-tg3.patch: Jeff Garzik and David S. Millers tg3 1.4c
        driver for 2.4.20.

Enjoy!

Regards
James Bourne


> 	Jeff

-- 
James Bourne, Supervisor Data Centre Operations
Mount Royal College, Calgary, AB, CA
www.mtroyal.ab.ca

******************************************************************************
This communication is intended for the use of the recipient to which it is
addressed, and may contain confidential, personal, and or privileged
information. Please contact the sender immediately if you are not the
intended recipient of this communication, and do not copy, distribute, or
take action relying on it. Any communication received in error, or
subsequent reply, should be deleted or destroyed.
******************************************************************************


"There are only 10 types of people in this world: those who
understand binary and those who don't."

Re: Ptrace hole / Linux 2.2.25

[Martin J. Bligh]

>> akpm has suggested something like this in the past.  I respectfully 
>> disagree.
> 
> I also disagree.  Although it would be nice, it's not practical.  What
> people want is strictly fixes and security related patches, and that
> is ALL I propose to want to include.  Perhaps if the vendors
> want a "common vendor" patch they could maintain it? ;)

I still think the common vendor kernel is valuable, but different ;-)
A straight fixes tree is valuable too ... thanks.

M.

Re: Ptrace hole / Linux 2.2.25

[James Bourne]

On Sun, 23 Mar 2003, Martin J. Bligh wrote:

> > is ALL I propose to want to include.  Perhaps if the vendors
> > want a "common vendor" patch they could maintain it? ;)
> 
> I still think the common vendor kernel is valuable, but different ;-)
> A straight fixes tree is valuable too ... thanks.

I do agree that it would be valuable, just not my bag.

Regards
James Bourne (different email address due to disclaimer chaos)

> M.

-- 
James Bourne                  | Email:            jbourne@hardrock.org          
Unix Systems Administrator    | WWW:           http://www.hardrock.org
Custom Unix Programming       | Linux:  The choice of a GNU generation
----------------------------------------------------------------------
 "All you need's an occasional kick in the philosophy." Frank Herbert  

Re: Ptrace hole / Linux 2.2.25

[Felipe Alfaro Solana]

On Sun, 2003-03-23 at 23:21, Jeff Garzik wrote:
> akpm has suggested something like this in the past.  I respectfully 
> disagree.
> 
> The 2.4 kernel will not benefit from constant churn of backporting core 
> kernel changes like a new scheduler.  We need to let it settle, simply 
> get it stable, and concentrate on fixing key problems in 2.6.  Otherwise 
> you will never have a stable 2.4 tree, and it will look suspiciously 
> more and more like 2.6 as time goes by.  Constantly breaking working 
> configurations and changing core behaviors is _not_ the way to go for 2.4.
> 
> I see 2.4 O(1) scheduler and similar features as _pain_ brought on the 
> vendors by themselves (and their customers).
> 
> Surely it is better to concentrate developer time and mindshare on 
> making 2.6 sane?

I'm no hardcore kernel hacker, but I fully agree with you.
2.4 is pretty stable... Introducing new code (VM, IDE, etc) is just a
bit risky, more even when current 2.4 is 2.4.21 (I would say mature
enough).

________________________________________________________________________
        Felipe Alfaro Solana
   Linux Registered User #287198
http://counter.li.org

Re: Ptrace hole / Linux 2.2.25

[Martin J. Bligh]

> akpm has suggested something like this in the past.  I respectfully
> disagree.
> 
> The 2.4 kernel will not benefit from constant churn of backporting core
> kernel changes like a new scheduler.  We need to let it settle, simply
> get it stable, and concentrate on fixing key problems in 2.6.  Otherwise
> you will never have a stable 2.4 tree, and it will look suspiciously more
> and more like 2.6 as time goes by.  Constantly breaking working
> configurations and changing core behaviors is _not_ the way to go for 2.4.
> 
> I see 2.4 O(1) scheduler and similar features as _pain_ brought on the
> vendors by themselves (and their customers).

O(1) sched may be a bad example ... how about the fact that mainline VM
is totally unstable? Witness, for instance, the buffer_head stuff. Fixes
for that have been around for ages. 

The real philosophical question is "what is mainline 2.4 _for_"?
 
> Surely it is better to concentrate developer time and mindshare on making
> 2.6 sane?

Agreed, but all we're doing now is burning lots of time on backporting
stuff from 2.5 into each separate distro base, and each distro fixing
things independantly in their own tree (eg O(1) scheduler). I don't
see that as constructive ... customers will not stagnate, and I don't
see the point in 2.4 mainline doing that either. 

It's now got to the point where the testing people don't even bother
testing mainline 2.4 because they know it's horribly broken, and is not
getting fixed, so there's no point. I think that's sad. Instead, we test
umpteen different vendor kernels, and try to apply the same fixes to each
of those, which is a pain in the butt, becasue they won't merge cleanly
because the trees are so far diverged. People running non-vendor kernels
are generally running 2.4-aa or 2.4-ac, etc, etc. All burnt thrash time.

Yes, the real answer is to get 2.6 out the door, and move people onto it.
But that will take a little while ... would be nice to get some way to
alleviate the pain in the meantime.

M.

Re: Ptrace hole / Linux 2.2.25

[Alan Cox]

> O(1) sched may be a bad example ... how about the fact that mainline VM
> is totally unstable? Witness, for instance, the buffer_head stuff. Fixes
> for that have been around for ages. 

On normal computers 2.4.21pre VM is very stable, in fact I dumped the
rmap vm from -ac because its far better at the moment

Most people don't care about 32 way scaling of 16Gb boxes running EVMS.

Re: Ptrace hole / Linux 2.2.25

[Martin J. Bligh]

>> O(1) sched may be a bad example ... how about the fact that mainline VM
>> is totally unstable? Witness, for instance, the buffer_head stuff. Fixes
>> for that have been around for ages. 
> 
> On normal computers 2.4.21pre VM is very stable, in fact I dumped the
> rmap vm from -ac because its far better at the moment

Cool - I gave up on 2.4 before that. Perhaps it's getting sorted out now
... is the buffer_head stuff fixed now? If 2.4 VM was more or less the same
across distros, that would get rid of a whole bunch of pain.

> Most people don't care about 32 way scaling of 16Gb boxes running EVMS.

That wasn't what I meant ... but I think there's a place for a tree
of common vendor 2.4 fixes & features, a separate one for the workstation
and server stuff if you will. All the current duplication of effort seems
rather silly.

M.

Re: Ptrace hole / Linux 2.2.25

[Andrea Arcangeli]

Hi,

On Sun, Mar 23, 2003 at 06:19:52PM -0500, Alan Cox wrote:
> > O(1) sched may be a bad example ... how about the fact that mainline VM
> > is totally unstable? Witness, for instance, the buffer_head stuff. Fixes
> > for that have been around for ages. 
> 
> On normal computers 2.4.21pre VM is very stable, in fact I dumped the
> rmap vm from -ac because its far better at the moment

If you want to go in full sync with the other vm fixes and improvements
in my tree I can send you the other remaining patches to apply (not
before the end of next week though), they works so well that I don't get
a single vm report for several months and I would like if they could
reach mainline too infact since they are over-time-refinement only,
nothing I would call major or very significant. Maybe if you merge them,
then Marcelo will merge them too?  most of them are easily mergeable by
just checking my ftp area, most start with 05_vm_ and they shouldn't be
very controversial. Andrew blessed them too, when he splitted them (he
only giveup on the "-rest" patch so that one is still very monolithic
sorry ;).

Andrea

Re: Ptrace hole / Linux 2.2.25

[Andrea Arcangeli]

On Sun, Mar 23, 2003 at 10:35:05PM -0500, Andrea Arcangeli wrote:
> nothing I would call major or very significant. Maybe if you merge them,

woops, re-reading I said the above plain wrong sorry, I really meant
they're not going to give you major or very significant problems in
merging (at least IMHO but I may be biased ;), for the big iron
_end_users_ they are definitely significant this is why I'm recommending
their merging and various other people is pushing for their merging in
mainline too.

Andrea

Re: Ptrace hole / Linux 2.2.25

[Christoph Hellwig]

On Sun, Mar 23, 2003 at 10:35:05PM -0500, Andrea Arcangeli wrote:
> very controversial. Andrew blessed them too, when he splitted them (he
> only giveup on the "-rest" patch so that one is still very monolithic
> sorry ;).

For the -rest stuff (and very few other split patches) there's still no
evidence that it needs to go into mainline.  But having the other stuff
in would certainly help to not only make mainline useable under higher loads
on not-lowend heardware and has the additional benefit that later patches
form -aa might just apply instead of people like me needing to spend some
time on merging them over just to not get them applied anyway..

Re: Ptrace hole / Linux 2.2.25

[Alan Cox]

> nothing I would call major or very significant. Maybe if you merge them,
> then Marcelo will merge them too?  most of them are easily mergeable by
> just checking my ftp area, most start with 05_vm_ and they shouldn't be
> very controversial. Andrew blessed them too, when he splitted them (he
> only giveup on the "-rest" patch so that one is still very monolithic
> sorry ;).

I'm wary of mixing them with IDE but I will take a look. In the 2.2 case
it certainly worked out well

Re: Ptrace hole / Linux 2.2.25

[Jeff Garzik]

Martin J. Bligh wrote:
>>akpm has suggested something like this in the past.  I respectfully
>>disagree.
>>
>>The 2.4 kernel will not benefit from constant churn of backporting core
>>kernel changes like a new scheduler.  We need to let it settle, simply
>>get it stable, and concentrate on fixing key problems in 2.6.  Otherwise
>>you will never have a stable 2.4 tree, and it will look suspiciously more
>>and more like 2.6 as time goes by.  Constantly breaking working
>>configurations and changing core behaviors is _not_ the way to go for 2.4.
>>
>>I see 2.4 O(1) scheduler and similar features as _pain_ brought on the
>>vendors by themselves (and their customers).
> 
> 
> O(1) sched may be a bad example ... how about the fact that mainline VM
> is totally unstable? Witness, for instance, the buffer_head stuff. Fixes
> for that have been around for ages. 

"totally unstable" being defined as:  My computers don't crash, and my 
100%-mainline test kernels pass various Cerberus/LTP/crashme runs.

Of course, I am not totally focused on multi-million-dollar computers, 
so maybe my perspective is skewed...  ;-)


> The real philosophical question is "what is mainline 2.4 _for_"?

It's the 2.4 tree that's missing all the vendor junk unacceptable for 
mainline.


> Yes, the real answer is to get 2.6 out the door, and move people onto it.
> But that will take a little while ... would be nice to get some way to
> alleviate the pain in the meantime.

Fixes should be applied to 2.4-mainline, certainly.  Anything else just 
wastes developer brain cycles and slows the move to 2.6.

	Jeff

Re: Ptrace hole / Linux 2.2.25

[Martin J. Bligh]

>> O(1) sched may be a bad example ... how about the fact that mainline VM
>> is totally unstable? Witness, for instance, the buffer_head stuff. Fixes
>> for that have been around for ages. 
> 
> "totally unstable" being defined as:  My computers don't crash, and my
> 100%-mainline test kernels pass various Cerberus/LTP/crashme runs.
> 
> Of course, I am not totally focused on multi-million-dollar computers, so
> maybe my perspective is skewed...  ;-)

Last time I checked, a 2x machine with 4Gb of RAM didn't cost millions of
dollars ;-)

> Fixes should be applied to 2.4-mainline, certainly.  Anything else just
> wastes developer brain cycles and slows the move to 2.6.

Common vendor _features_ is maybe better done in a separate tree, I'd
accept ... I'm just frustrated with the current lack of commonality between
distros, I guess.

M.

Re: Ptrace hole / Linux 2.2.25

[J.A. Magallon]

On 03.24, Martin J. Bligh wrote:
> >> O(1) sched may be a bad example ... how about the fact that mainline VM
> >> is totally unstable? Witness, for instance, the buffer_head stuff. Fixes
> >> for that have been around for ages. 
> > 
> > "totally unstable" being defined as:  My computers don't crash, and my
> > 100%-mainline test kernels pass various Cerberus/LTP/crashme runs.
> > 
> > Of course, I am not totally focused on multi-million-dollar computers, so
> > maybe my perspective is skewed...  ;-)
> 
> Last time I checked, a 2x machine with 4Gb of RAM didn't cost millions of
> dollars ;-)
> 
> > Fixes should be applied to 2.4-mainline, certainly.  Anything else just
> > wastes developer brain cycles and slows the move to 2.6.
> 
> Common vendor _features_ is maybe better done in a separate tree, I'd
> accept ... I'm just frustrated with the current lack of commonality between
> distros, I guess.
> 

You will never get distros to follow that. A 'featured-kernel-for-distro'...
Just take RH and SuSE (correct me if I'm wrong...)
RH ships -ac. SuSE ships -aa. At least both (-ac and -aa) have O(1) scheduler
now. -ac ships rmap, -aa ships -aa (;)). That means O(1) goes in your kernel,
but how about the VM subsystem ? 

But now that -ac does not include rmap, perhaps the VM can be chosen as the
one from Andrea...

(BTW, I have been runnin plan -pres for a couple of weeks, and now that I run
-aa again, my computer looks like a new one...)

-- 
J.A. Magallon <jamagallon@able.es>      \                 Software is like sex:
werewolf.able.es                         \           It's better when it's free
Mandrake Linux release 9.1 (Bamboo) for i586
Linux 2.4.21-pre5-jam1 (gcc 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk))

Re: Ptrace hole / Linux 2.2.25

[Christoph Hellwig]

On Mon, Mar 24, 2003 at 01:07:13AM +0100, J.A. Magallon wrote:
> You will never get distros to follow that. A 'featured-kernel-for-distro'...
> Just take RH and SuSE (correct me if I'm wrong...)
> RH ships -ac. SuSE ships -aa. At least both (-ac and -aa) have O(1) scheduler
> now. -ac ships rmap, -aa ships -aa (;)). That means O(1) goes in your kernel,
> but how about the VM subsystem ? 

Mainline needs VM updates and as the -aa VM is the actual fixes for the
2.4.10+ VM it needs to be merged (at least partially).  It's sad that this
happened after akpm and other spent lots of time on splitting up and
documenting it.

Re: Ptrace hole / Linux 2.2.25

[Christian Axelsson]

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

On Sun, 23 Mar 2003 15:45:38 -0800
"Martin J. Bligh" <mbligh@aracnet.com> wrote:

<snip>
> Common vendor _features_ is maybe better done in a separate tree, I'd
> accept ... I'm just frustrated with the current lack of commonality between
> distros, I guess.
</snip>

Excuse me for breaking in, but after reading this thread for a while I have a
suggestion to make: if you feel that a 2.4.xx-extrafeatures is needed try to get
a couple of guys together and start up your own branch of patches :)
I would be one that's willing to try it out.

-- 
Christan Axelsson
smiler@lanil.mine.nu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Ptrace hole / Linux 2.2.25

[aradorlinux]

On Sun, 23 Mar 2003 14:54:40 -0800
"Martin J. Bligh" <mbligh@aracnet.com> wrote:


> O(1) sched may be a bad example ... how about the fact that mainline VM

I guess alsa is even a better example. It's one of the very few things
that really have sense (IMHO) to have in 2.4.
After all, they're drivers; and many people has to use them to get support.

(I remember in a interview somewhere where Marcelo said he wasn't going to
merge them, but it'd be nice anyway....)


Diego Calleja

Re: Ptrace hole / Linux 2.2.25

[Arjan van de Ven]

On Sun, Mar 23, 2003 at 12:30:43PM -0800, Martin J. Bligh wrote:

> The distros inherently have a conflict of interest getting changes merged
> back into mainline ... it's time consuming to do, it provides them no real
> benefit (they have to maintain their huge trees anyway), and it actively
> damages the "value add" they provide.

I take a strong objection to this. I can't speak for all distros, but I
know that Red Hat has a strong preference to get things merged upstream as
soon as possible. I think you are absolutely wrong about the "no
real benefit" part and that you totally misunderstand what value add
distributions provide.

> If that's people's attitude ("you should use a vendor"), then we need a 
> 2.4-fixed tree to be run by somebody with an interest in providing 
> critical bugfixes to the community with no distro ties.

this is not about distros or vendors (yes IBM is a linux vendor too). at
all. Marcelo is in a tough position; either he releases an emergency
kernel with a patch applied that seems to have a few corner case issues,
or he starts to rush out 2.4.21 based on the current
2.4.21-pre codebase. Given that there are other bugs in 2.4.20
that makes people say "but THIS needs to be in too", I can see
that becoming a very fuzzy thing pretty quick. Apparantly Marcelo decided
to go for the "get 2.4.21 out soon" approach..... 

Greetings, 
    Arjan van de Ven

Re: Ptrace hole / Linux 2.2.25

[Martin J. Bligh]

>> The distros inherently have a conflict of interest getting changes merged
>> back into mainline ... it's time consuming to do, it provides them no real
>> benefit (they have to maintain their huge trees anyway), and it actively
>> damages the "value add" they provide.
> 
> I take a strong objection to this. I can't speak for all distros, but I
> know that Red Hat has a strong preference to get things merged upstream as
> soon as possible. I think you are absolutely wrong about the "no
> real benefit" part and that you totally misunderstand what value add
> distributions provide.

Well, that is a minefield of subjective opinions. Yes, the distros merge
stuff back ... but there's not enough of it going on. RHAS and UL are
*massively* diverged. There are also changes that are in just about every
distro that aren't back in mainline. I fail to see the point of that ...
people complain about problems with things like O(1) scheduler, and yet
the distros all distribute it ... very odd.

The question of "what is mainline 2.4 for anyway" is becoming increasingly
interesting, especially as fewer people are using it. If there was more
of a common base between the distros, there would be IMHO less duplicated
work.

>> If that's people's attitude ("you should use a vendor"), then we need a 
>> 2.4-fixed tree to be run by somebody with an interest in providing 
>> critical bugfixes to the community with no distro ties.
> 
> this is not about distros or vendors (yes IBM is a linux vendor too). at
> all. Marcelo is in a tough position; either he releases an emergency
> kernel with a patch applied that seems to have a few corner case issues,
> or he starts to rush out 2.4.21 based on the current
> 2.4.21-pre codebase. Given that there are other bugs in 2.4.20
> that makes people say "but THIS needs to be in too", I can see
> that becoming a very fuzzy thing pretty quick. Apparantly Marcelo decided
> to go for the "get 2.4.21 out soon" approach..... 

I'm not so worried about what Marcelo chooses to do with this particular
issue - that's his call. However, I'm extremely concerned by the general
"you should be using a vendor kernel" attitude.

M.

Re: Ptrace hole / Linux 2.2.25

[Juan Quintela]

>>>>> "martin" == Martin J Bligh <mbligh@aracnet.com> writes:

Hi

martin> Well, that is a minefield of subjective opinions. Yes, the distros merge
martin> stuff back ... but there's not enough of it going on. RHAS and UL are
martin> *massively* diverged. There are also changes that are in just about every
martin> distro that aren't back in mainline. I fail to see the point of that ...
martin> people complain about problems with things like O(1) scheduler, and yet
martin> the distros all distribute it ... very odd.

Problem is the same than ever.  Full major kernel releases take 2
years.  That means that we need to force things in the _stable_ branch
that should be in next branch.  2.4 should be in maintenance mode (aka
something similar to what happens in 2.2 just now), but as 2.6 is not
ready (and will not in at least several months yet), we have to live
with big changes like the big IDE merge.

About the reasons for having lots of patches in a vendor kernel.  It
is just a pain in the ass :(  I completely agree with Arjan on that.
Problem is that getting patches back merged upstream sometimes is not
easy either :(  For instance, users test the distro when they are in
release candidate, and when you found that problems and you got fixes
for that, it is posible that kernel code base has already changed,
what makes merging your fixes difficult.  And not, merging code for
mainline during a release candidate cycle is Just a Bad Idea (tm).

martin> The question of "what is mainline 2.4 for anyway" is becoming
martin> increasingly interesting, especially as fewer people are using
martin> it. If there was more of a common base between the distros,
martin> there would be IMHO less duplicated work.

Will be basically the same work.  Somebody needs to be in charge of
that branch.  And if you get <somebody> to pass your changes, then you
have also the same posibilities to pass the patch Marcelo :)

martin> I'm not so worried about what Marcelo chooses to do with this particular
martin> issue - that's his call. However, I'm extremely concerned by the general
martin> "you should be using a vendor kernel" attitude.

Here, I completely agree with Pavel, you should never tell that
sentence in that list :)  You should use a vendor kernel only if:
- you don't know how to compile your own, and you are not interested
  in learn how to do it.
- you are lazy, and think that it is _easier_ for you to use a vendor
  kernel.

Later, Juan "who knows what is the pain of having lots of patches"

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: Ptrace hole / Linux 2.2.25

[Brian Tinsley]

Juan Quintela wrote:

>Here, I completely agree with Pavel, you should never tell that
>sentence in that list :)  You should use a vendor kernel only if:
>- you don't know how to compile your own, and you are not interested
>  in learn how to do it.
>- you are lazy, and think that it is _easier_ for you to use a vendor
>  kernel.
>
>
>  
>
OR :

- you work for people that absolutely freak out because you compile 
and/or patch your own kernel (yet you continue to torture them by doing 
so - hehe)

- you spend 80 hours a week on your job and don't have time to mess with 
building and maintaining your own kernels (where's the laziness here?)

- you are subject to certain rules and regulations that require a 
"vendor" to stand behind the various pieces of software that comprise 
your system (yeah I know, really lame, but a reality)

Re: Ptrace hole / Linux 2.2.25

[Robert Love]

On Sun, 2003-03-23 at 15:30, Martin J. Bligh wrote:

> I don't agree that's always been true by any means. It may currently
> be true, but that's far from a good thing. The current state of divergance
> the distros have from mainline 2.4 is IMHO the biggest problem Linux has
> today.

What part of my statement are you disagreeing with, here?

I agree distribution divergence is a big issue.  It may be a mostly
insolvable one, too.  It is partially a result of having a long
development cycle.  But even if we had a shorter development cycle,
different distributions have different priorities.  It is a hard
problem.

> The distros inherently have a conflict of interest getting changes merged
> back into mainline ... it's time consuming to do, it provides them no real
> benefit (they have to maintain their huge trees anyway), and it actively
> damages the "value add" they provide.

I do not disagree.

Although, I think there is incentive to get work merged.  It _does_
reduce maintenance.  I think you can see Red Hat merging stuff back.  I
know my employer encourages everything I do to be done openly and get it
merged.  Its a huge benefit to maintenance and QA to get stuff merged.

> If that's people's attitude ("you should use a vendor"), then we need a 
> 2.4-fixed tree to be run by somebody with an interest in providing 
> critical bugfixes to the community with no distro ties. People may be
> perfectly capable of finding, applying, and collecting their own patches,
> but that's no reason to make it difficult.

No where above did I say "you should use a vendor"

In fact, what I did say is "I think users can and should compile their
own kernel if they want.  And as kernel developers, we should facilitate
that."

I merely suggest that users should not expect anything if they go it
there own.  They need to follow the lists and be informed.  Its like me
assuming I can maintain my car without a mechanic and then freaking out
when I did not hear about a service defect.  Actually, a better analogy
may include me knowing nothing about cars, too :)

Marcelo is in a tough spot.  I think Arjan's email (just sent) sums it
up well.  It is not so clear cut.  Personally, I think the ext3 bugs in
2.4.20 are worse than this local ptrace problem (there are other local
issues, too).  I also think some people are skeptical over the
correctness of this patch.

Anyhow, what exactly are we arguing over?

	Robert Love

Re: Ptrace hole / Linux 2.2.25

[Martin J. Bligh]

>> The distros inherently have a conflict of interest getting changes merged
>> back into mainline ... it's time consuming to do, it provides them no real
>> benefit (they have to maintain their huge trees anyway), and it actively
>> damages the "value add" they provide.
> 
> I do not disagree.
> 
> Although, I think there is incentive to get work merged.  It _does_
> reduce maintenance.  I think you can see Red Hat merging stuff back.  I
> know my employer encourages everything I do to be done openly and get it
> merged.  Its a huge benefit to maintenance and QA to get stuff merged.

Yeah, I think it happens on the whole, despite the conflict of interest;
but frustratingly slowly. There's two sides to that equation though.
 
>> If that's people's attitude ("you should use a vendor"), then we need a 
>> 2.4-fixed tree to be run by somebody with an interest in providing 
>> critical bugfixes to the community with no distro ties. People may be
>> perfectly capable of finding, applying, and collecting their own patches,
>> but that's no reason to make it difficult.
> 
> No where above did I say "you should use a vendor"
> 
> In fact, what I did say is "I think users can and should compile their
> own kernel if they want.  And as kernel developers, we should facilitate
> that."

Right. I just think mainline should provide that facilitation role. 
If it doesn't, then if someone can gather the patches together, it'd
help a lot. Applying the patches less of a problem than finding out what
to apply ... following LKML isn't feasible for most people.
 
> I merely suggest that users should not expect anything if they go it
> there own.  They need to follow the lists and be informed.  Its like me
> assuming I can maintain my car without a mechanic and then freaking out
> when I did not hear about a service defect.  Actually, a better analogy
> may include me knowing nothing about cars, too :)

yeah, but it's more like "should we have someone list the service defects
together on a website where you can find them easily", or leave them in 
a darkened basment where the lights are out with "beware of the leapord"
stuck on the door ;-) Or should I have to service my car at the dealer?

Some people may chose the dealer ... I'd prefer the website to the 
basement ;-)

> Anyhow, what exactly are we arguing over?

Not a lot ;-)

M.

Re: Ptrace hole / Linux 2.2.25

[Jeff Garzik]

Martin J. Bligh wrote:
>>>But if you assume this, what are the official releases for anyway?
>>
>>Well, official releases have always been sort of arbitrary for the
>>kernel... just labeled releases along the course of development. 
>>Although with the recent addition of the -rc patches, they tend to
>>ensure the latest round of development at least resulted in a stable
>>release.  But look at all the major vendors - their 2.4.18 release, for
>>example, may include whatever the latest pre-patch was at the time.
> 
> 
> I don't agree that's always been true by any means. It may currently
> be true, but that's far from a good thing. The current state of divergance
> the distros have from mainline 2.4 is IMHO the biggest problem Linux has
> today.
> 
> The distros inherently have a conflict of interest getting changes merged
> back into mainline ... it's time consuming to do, it provides them no real
> benefit (they have to maintain their huge trees anyway), and it actively
> damages the "value add" they provide.


Just to underscore Arjan's point:  non-mainline patches are very 
actively discouraged at Red Hat.  As time progresses the maintenance 
cost of EACH non-mainline patch increases.  Non-mainline patches do not 
get the benefits of wide community testing, review, and feedback. 
Further, Red Hat employees in my experience typically land patches in 
the community _first_ -- witness my netdriver work (goes me -> Marcelo 
-> RH), DaveM's net stack work, and Alan's -ac tree.

	Jeff

Re: Ptrace hole / Linux 2.2.25

[Martin J. Bligh]

>> I don't agree that's always been true by any means. It may currently
>> be true, but that's far from a good thing. The current state of divergance
>> the distros have from mainline 2.4 is IMHO the biggest problem Linux has
>> today.
>> 
>> The distros inherently have a conflict of interest getting changes merged
>> back into mainline ... it's time consuming to do, it provides them no real
>> benefit (they have to maintain their huge trees anyway), and it actively
>> damages the "value add" they provide.
> 
> Just to underscore Arjan's point:  non-mainline patches are very actively 
> discouraged at Red Hat.  As time progresses the maintenance cost of EACH 
> non-mainline patch increases.  Non-mainline patches do not get the 
> benefits of wide community testing, review, and feedback. Further, 
> Red Hat employees in my experience typically land patches in the community 
> _first_ -- witness my netdriver work (goes me -> Marcelo -> RH), DaveM's 
> net stack work, and Alan's -ac tree.

Right ... people seem to have taken more than I meant from this, and taken
it more personally than it was intended. I do believe there is at least
some conflict of interest ... but that doesn't mean people are controlled 
by it.

After some other side conversations, perhaps it would be useful to clarify 
that the appearance of a problem is more that we don't *see* patches getting 
submitted or accepted very often. That doesn't necessarily mean they aren't
getting submitted.

But the divergance of 2.4 is still a massive issue ... whatever the 
underlying causes are.

M.

Re: Ptrace hole / Linux 2.2.25

[Jeff Garzik]

Martin J. Bligh wrote:
>>>I don't agree that's always been true by any means. It may currently
>>>be true, but that's far from a good thing. The current state of divergance
>>>the distros have from mainline 2.4 is IMHO the biggest problem Linux has
>>>today.
>>>
>>>The distros inherently have a conflict of interest getting changes merged
>>>back into mainline ... it's time consuming to do, it provides them no real
>>>benefit (they have to maintain their huge trees anyway), and it actively
>>>damages the "value add" they provide.
>>
>>Just to underscore Arjan's point:  non-mainline patches are very actively 
>>discouraged at Red Hat.  As time progresses the maintenance cost of EACH 
>>non-mainline patch increases.  Non-mainline patches do not get the 
>>benefits of wide community testing, review, and feedback. Further, 
>>Red Hat employees in my experience typically land patches in the community 
>>_first_ -- witness my netdriver work (goes me -> Marcelo -> RH), DaveM's 
>>net stack work, and Alan's -ac tree.
> 
> 
> Right ... people seem to have taken more than I meant from this, and taken
> it more personally than it was intended. I do believe there is at least
> some conflict of interest ... but that doesn't mean people are controlled 
> by it.
> 
> After some other side conversations, perhaps it would be useful to clarify 
> that the appearance of a problem is more that we don't *see* patches getting 
> submitted or accepted very often. That doesn't necessarily mean they aren't
> getting submitted.


I see a lot of new Red Hat work getting discussed, landing in the 2.5 
tree, and then getting backported as a value-add 2.4 feature for an RH 
kernel.  Other stuff is "hack it into stability, but it's ugly and 
should not go to Marcelo."

IMNSHO this perception is more a not-looking-hard-enough issue rather 
than reality.

I have no idea about UnitedLinux kernel, but for RHAS I wager there is 
next to _nil_ patches you would actually want to submit to Marcelo, for 
three main reasons:  it's a 2.5 backport, or, it's a 2.4.2X backport, 
or, its an ugly-hack-for-stability that should not be in a mainline 
kernel without cleaning anyway.


> But the divergance of 2.4 is still a massive issue ... whatever the 
> underlying causes are.


Can you actually quantify this divergance?

 From actually _looking_ at RHAS for submittable patches, it seems to me 
like mostly 2.5-backport patches in 2.4, or, bandaid-until-2.5 fixes 
that don't belong in mainline.

	Jeff

Re: Ptrace hole / Linux 2.2.25

[Martin J. Bligh]

> I see a lot of new Red Hat work getting discussed, landing in the 2.5
> tree, and then getting backported as a value-add 2.4 feature for an RH
> kernel.  Other stuff is "hack it into stability, but it's ugly and should
> not go to Marcelo."
> 
> IMNSHO this perception is more a not-looking-hard-enough issue rather
> than reality.

Well ... or we had different meanings ;-) yes, lots of stuff is in 2.5
but I was meaning 2.4. If there's stuff that's in both RH and UL kernels,
and it's stable enough for them both to ship as their product, it sounds
mergeable to me.

> I have no idea about UnitedLinux kernel, but for RHAS I wager there is
> next to _nil_ patches you would actually want to submit to Marcelo, for
> three main reasons:  it's a 2.5 backport, or, it's a 2.4.2X backport, or,
> its an ugly-hack-for-stability that should not be in a mainline kernel
> without cleaning anyway.

I don't see what's wrong with putting 2.5 backports into 2.4 once they're
stable. And I'd rather have an ugly-hack-for-stability than an unstable
kernel ... 2.5 is the place for cleanliness ... 2.4 is a dead end that
just needs to work.

> Can you actually quantify this divergance?
> 
>  From actually _looking_ at RHAS for submittable patches, it seems to me
> like mostly 2.5-backport patches in 2.4, or, bandaid-until-2.5 fixes that
> don't belong in mainline.

Right ... I think we're agreeing about what's the difference. Just
disagreeing about what should be in mainline 2.4. If most others think it
shouldn't go either, than I guess we need a separate tree for a 2.4 that
works, not a 2.4 that's pretty ...

M.

Re: Ptrace hole / Linux 2.2.25

[Henning P. Schmiedehausen]

"Martin J. Bligh" <mbligh@aracnet.com> writes:

>The distros inherently have a conflict of interest getting changes merged
>back into mainline ... it's time consuming to do, it provides them no real
>benefit (they have to maintain their huge trees anyway), and it actively
>damages the "value add" they provide.

Well, I hope that the fragmentation of Unix in the 80'ies with the
resulting rise of an unified OS to be marked leader ("DOS", then
"Windows") should've learned that lesson with the vendors.

Linux ATM is heading exactly in the same direction as Unix went when
Sun/HP/IBM/DEC decided not to keep an unified Unix base. It isn't
heading that fast, mainly because the vendors must keep open source
trees and they work from a central baseline ("Linus kernels") but we
already have various distributions which sell "Linux" with a hugely
different kernel. Think e.g.  VM or devfs. Or supported file systems.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

Re: Ptrace hole / Linux 2.2.25

[Henning P. Schmiedehausen]

"Martin J. Bligh" <mbligh@aracnet.com> writes:

>If that's people's attitude ("you should use a vendor"), then we need a 
>2.4-fixed tree to be run by somebody with an interest in providing 
>critical bugfixes to the community with no distro ties. People may be
>perfectly capable of finding, applying, and collecting their own patches,
>but that's no reason to make it difficult.

Get the vendors to pay someone equally for it. That's much more likely
to succeed. The current 2.4 model is already doomed, IMHO. 

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

re: Ptrace hole / Linux 2.2.25

[Tomas Szepe]

> [rml@tech9.net]
> 
> Yes, I suspect he does as do most people here.

This sentence is ambiguous and one of its possible meanings is
"Most people do and Robert Love suspects Alan Cox does, too," which
is also probably what you meant.  A bit strong a statement, don't you
think?  How can you know the opinion of most people here?

As a sidenote, I consider it important to note that it's obvious
that if Alan were the 2.4 maintainer, we would likely have a 2.4.21
with the critical (and possibly other) fixes out and all the fancy
new stuff rescheduled for 2.4.22.

-- 
Tomas Szepe <szepe@pinerecords.com>

re: Ptrace hole / Linux 2.2.25

[Robert Love]

On Sun, 2003-03-23 at 15:09, Tomas Szepe wrote:

> This sentence is ambiguous and one of its possible meanings is
> "Most people do and Robert Love suspects Alan Cox does, too," which
> is also probably what you meant.  A bit strong a statement, don't you
> think?  How can you know the opinion of most people here?

Yes, sorry, ambiguous.

I meant "I suspect most people agree with Alan"

I do not presume to know what most people think.  I presume to think I
know, hence "I suspect ..."

Anyhow, all I am saying is, if people _require_ support or bug fixes or
instant updates they should use a vendor kernel.  This does not mean we
should not facilitate users who do make their own kernel.

This thread is getting off-topic...

> As a sidenote, I consider it important to note that it's obvious
> that if Alan were the 2.4 maintainer, we would likely have a 2.4.21
> with the critical (and possibly other) fixes out and all the fancy
> new stuff rescheduled for 2.4.22.

I would of released a 2.4.21, too.

	Robert Love

Re: Ptrace hole / Linux 2.2.25

[Jeff Garzik]

Tomas Szepe wrote:
> As a sidenote, I consider it important to note that it's obvious
> that if Alan were the 2.4 maintainer, we would likely have a 2.4.21
> with the critical (and possibly other) fixes out and all the fancy
> new stuff rescheduled for 2.4.22.


Now we're speaking for Marcelo _and_ Alan?

	Jeff

Re: Ptrace hole / Linux 2.2.25

[Alan Cox]

On Sun, 2003-03-23 at 20:49, Jeff Garzik wrote:
> Tomas Szepe wrote:
> > As a sidenote, I consider it important to note that it's obvious
> > that if Alan were the 2.4 maintainer, we would likely have a 2.4.21
> > with the critical (and possibly other) fixes out and all the fancy
> > new stuff rescheduled for 2.4.22.
> 
> 
> Now we're speaking for Marcelo _and_ Alan?

He's wrong too as past 2.2 history will show

Re: Ptrace hole / Linux 2.2.25

[Jeff Garzik]

Martin Mares wrote:
> Do you really think that "People should either use vendor kernels or
> read LKML and be able to gather the fixes from there themselves" is a
> good strategy?


Maybe I can make the point another way...
TANSTAAFL:  There Ain't No Such Thing As A Free Lunch.

Marcelo is a volunteer, and maintaining the 2.4 kernel is not his full 
time job.  Marcelo isn't beholden to people demanding a kernel release 
NOW NOW NOW.  If you want that type of support, you have to pay for it.

I consider my personal obligation as "do my best as time and sanity 
allows."  Demanding of people what they already give freely is a poor 
way to motivate.

	Jeff

Re: Ptrace hole / Linux 2.2.25

[Arjan van de Ven]

On Sun, Mar 23, 2003 at 04:56:14PM -0500, Jeff Garzik wrote:
> Martin Mares wrote:
> > Do you really think that "People should either use vendor kernels or
> > read LKML and be able to gather the fixes from there themselves" is a
> > good strategy?
> 
> 
> Maybe I can make the point another way...
> TANSTAAFL:  There Ain't No Such Thing As A Free Lunch.
> 
> Marcelo is a volunteer, and maintaining the 2.4 kernel is not his full 
> time job.  Marcelo isn't beholden to people demanding a kernel release 
> NOW NOW NOW.  If you want that type of support, you have to pay for it.

I know this can sound a bit "the wrong way".

There's another thing though; Marcelo needs to merge the RIGHT fix. And he
did merge it; he just hasn't finished releasing -pre6 yet

Re: Ptrace hole / Linux 2.2.25

[jlnance]

On Sun, Mar 23, 2003 at 08:44:23PM +0100, Martin Mares wrote:

> Do you really think that "People should either use vendor kernels or
> read LKML and be able to gather the fixes from there themselves" is a
> good strategy?

Hi Martin,
    I must say that I think it is an excellent strategy.  I will admit
though, that I have voiced this opinion several times in the past and
it seems that most people disagree with me.
    I think we do a disservice to people by encouraging them to believe
that the kernels they download from kernel.org can be depended on to
work.  Kernel.org kernels are effectivly a way for people to participate
in the development process and to help with QA.  If you dont want to
be involved with these activities, you really do not want to use those
kernels.
    We could try and make that guarantee if we wanted to, but it would
be a lot of work and the vendors are already doing it.  So why not
leverage their work?

Thanks,

Jim

Re: Ptrace hole / Linux 2.2.25

[Jörn Engel]

On Sun, 23 March 2003 14:38:10 -0500, Alan Cox wrote:
>
> -	Anyone can go and release their own 2.4.20.1 or 2.4.20-sec or
> 	whatever if they feel strongly about it
> 
> Just go do it. If someone wants to be a contact point for build existing
> base kernels + published security fix trees I'm pretty sure kernel.org
> would host them too.

Sounds like a good idea. Ideal would be a person with a lottle
knowledge about security or at least, about this particular patch.

I would volunteer, if noone else does. But just about anyone would be
closer to that ideal person, so consider me to be the last resort.

Jörn

-- 
Simplicity is prerequisite for reliability.
-- Edsger W. Dijkstra

Re: Ptrace hole / Linux 2.2.25

[Sven Schuster]

Jörn Engel wrote:

>On Sun, 23 March 2003 14:38:10 -0500, Alan Cox wrote:
>  
>
>>-	Anyone can go and release their own 2.4.20.1 or 2.4.20-sec or
>>	whatever if they feel strongly about it
>>
>>Just go do it. If someone wants to be a contact point for build existing
>>base kernels + published security fix trees I'm pretty sure kernel.org
>>would host them too.
>>    
>>
>
>Sounds like a good idea. Ideal would be a person with a lottle
>knowledge about security or at least, about this particular patch.
>
>I would volunteer, if noone else does. But just about anyone would be
>closer to that ideal person, so consider me to be the last resort.
>
>Jörn
>  
>

I think a solution like this would be best, having a "-fix" tree or 
similar for
the latest stable kernel maintained by a volunteer and hosted by kernel.org.

Optionally or alternatively there could/should be a mailinglist (yes, 
one more
:-) where all critical fixes like sec + fs fixes, etc. are posted to, for
people building their own kernels (and interested in staying up-to-date) 
but
not willing/having the time/able to dig through the tons of emails 
brought by
lkml.
Cause I think if you're not an active kernel developer or having some 
issues
with running a kernel, or like me, just interested and still learning to
understand linux kernel programming in the far future ;-) you shouldn't have
to read lkml just for building and maintaining your own, none-vendor 
kernel.
Btw, if you had to, I think there might even be the danger of loosing some
critical fixes in the loads of emails.

Sven
   

Re: Ptrace hole / Linux 2.2.25

[James Bourne]

On Mon, 24 Mar 2003, Sven Schuster wrote:

> Jörn Engel wrote:
> 
> >On Sun, 23 March 2003 14:38:10 -0500, Alan Cox wrote:
> >  
> >
> >>-	Anyone can go and release their own 2.4.20.1 or 2.4.20-sec or
> >>	whatever if they feel strongly about it
> >>
> >>Just go do it. If someone wants to be a contact point for build existing
> >>base kernels + published security fix trees I'm pretty sure kernel.org
> >>would host them too.
> >>    
> >>
> >
> >Sounds like a good idea. Ideal would be a person with a lottle
> >knowledge about security or at least, about this particular patch.
> >
> >I would volunteer, if noone else does. But just about anyone would be
> >closer to that ideal person, so consider me to be the last resort.
> >
> >Jörn
> >  
> >
> 
> I think a solution like this would be best, having a "-fix" tree or 
> similar for
> the latest stable kernel maintained by a volunteer and hosted by kernel.org.
> 
> Optionally or alternatively there could/should be a mailinglist (yes, one
> more :-) where all critical fixes like sec + fs fixes, etc. are posted to,
> for people building their own kernels (and interested in staying
> up-to-date) but not willing/having the time/able to dig through the tons
> of emails brought by lkml. Cause I think if you're not an active kernel
> developer or having some issues with running a kernel, or like me, just
> interested and still learning to understand linux kernel programming in
> the far future ;-) you shouldn't have to read lkml just for building and
> maintaining your own, none-vendor kernel. Btw, if you had to, I think
> there might even be the danger of loosing some critical fixes in the loads
> of emails.

Hi,
In an earlier email I posted a URL to an updates directory containing
strictly updates for the current 2.4 kernel tree.  The URL is
http://www.hardrock.org/kernel/current-updates/

Currently there is the ext3 patch, tg3 patch and ptrace patch.  Also is one
single patch with all three patches include.

Regards
James Bourne 

> Sven

-- 
James Bourne                  | Email:            jbourne@hardrock.org          
Unix Systems Administrator    | WWW:           http://www.hardrock.org
Custom Unix Programming       | Linux:  The choice of a GNU generation
----------------------------------------------------------------------
 "All you need's an occasional kick in the philosophy." Frank Herbert  

Re: Ptrace hole / Linux 2.2.25

[Sven Schuster]

James Bourne wrote:

 >Hi,
 >In an earlier email I posted a URL to an updates directory containing
 >strictly updates for the current 2.4 kernel tree.  The URL is
 >http://www.hardrock.org/kernel/current-updates/
 >
 >Currently there is the ext3 patch, tg3 patch and ptrace patch.  Also 
is one
 >single patch with all three patches include.
 >
 >
It's not about me, I myself had the ext3+tg3 patches applied since...well,
don't remember exactly, but it's been a while now. I'm reading lkml. This
was just meant as a suggestion to provide a kindof "help" or "support" to
people not reading lkml but building their own kernel. A mailinglist or
central place where they can get all the urgent fixes for the latest stable
kernel (here 2.4.20).

Sven

 >Regards
 >James Bourne
 >

Re: Ptrace hole / Linux 2.2.25

[James Bourne]

On Mon, 24 Mar 2003, Sven Schuster wrote:

> It's not about me, I myself had the ext3+tg3 patches applied since...well,
> don't remember exactly, but it's been a while now. I'm reading lkml. This
> was just meant as a suggestion to provide a kindof "help" or "support" to
> people not reading lkml but building their own kernel. A mailinglist or
> central place where they can get all the urgent fixes for the latest stable
> kernel (here 2.4.20).

Hi,
Thanks for the clarification.  I did propose to provide a central location
for the patches, as I do this for work already.  I could also put together a
place for that kind of help document or at least host it if someone else is
going to do this, that's a great idea as well...

Regards
James

> 
> Sven

-- 
James Bourne                  | Email:            jbourne@hardrock.org          
Unix Systems Administrator    | WWW:           http://www.hardrock.org
Custom Unix Programming       | Linux:  The choice of a GNU generation
----------------------------------------------------------------------
 "All you need's an occasional kick in the philosophy." Frank Herbert  

Re: Ptrace hole / Linux 2.2.25

[Jörn Engel]

On Sun, 23 March 2003 17:20:21 -0700, James Bourne wrote:
> 
> In an earlier email I posted a URL to an updates directory containing
> strictly updates for the current 2.4 kernel tree.  The URL is
> http://www.hardrock.org/kernel/current-updates/
> 
> Currently there is the ext3 patch, tg3 patch and ptrace patch.  Also is one
> single patch with all three patches include.

Looks good. Now all that is missing is a link from www.kernel.org,
maybe. Peter, what do you think?

Jörn

-- 
Ninety percent of everything is crap.
-- Sturgeon's Law

Re: Ptrace hole / Linux 2.2.25

[H. Peter Anvin]

Jörn Engel wrote:
> On Sun, 23 March 2003 17:20:21 -0700, James Bourne wrote:
> 
>>In an earlier email I posted a URL to an updates directory containing
>>strictly updates for the current 2.4 kernel tree.  The URL is
>>http://www.hardrock.org/kernel/current-updates/
>>
>>Currently there is the ext3 patch, tg3 patch and ptrace patch.  Also is one
>>single patch with all three patches include.
> 
> 
> Looks good. Now all that is missing is a link from www.kernel.org,
> maybe. Peter, what do you think?
> 

I'd rather keep the collection itself on kernel.org.

	-hpa

Re: Ptrace hole / Linux 2.2.25

[James Bourne]

On Sun, 23 Mar 2003, H. Peter Anvin wrote:

> Jörn Engel wrote:
> > On Sun, 23 March 2003 17:20:21 -0700, James Bourne wrote:
> > 
> >>In an earlier email I posted a URL to an updates directory containing
> >>strictly updates for the current 2.4 kernel tree.  The URL is
> >>http://www.hardrock.org/kernel/current-updates/
> >>
> >>Currently there is the ext3 patch, tg3 patch and ptrace patch.  Also is
> >>one single patch with all three patches include.
> > 
> > 
> > Looks good. Now all that is missing is a link from www.kernel.org,
> > maybe. Peter, what do you think?
> > 
> 
> I'd rather keep the collection itself on kernel.org.

No problem.  Let me know where.

Regards
James Bourne

> 
> 	-hpa
> 
> 

-- 
James Bourne                  | Email:            jbourne@hardrock.org          
Unix Systems Administrator    | WWW:           http://www.hardrock.org
Custom Unix Programming       | Linux:  The choice of a GNU generation
----------------------------------------------------------------------
 "All you need's an occasional kick in the philosophy." Frank Herbert  

Re: Ptrace hole / Linux 2.2.25

[H. Peter Anvin]

James Bourne wrote:
> On Sun, 23 Mar 2003, H. Peter Anvin wrote:
> 
> 
>>Jörn Engel wrote:
>>
>>>On Sun, 23 March 2003 17:20:21 -0700, James Bourne wrote:
>>>
>>>
>>>>In an earlier email I posted a URL to an updates directory containing
>>>>strictly updates for the current 2.4 kernel tree.  The URL is
>>>>http://www.hardrock.org/kernel/current-updates/
>>>>
>>>>Currently there is the ext3 patch, tg3 patch and ptrace patch.  Also is
>>>>one single patch with all three patches include.
>>>
>>>
>>>Looks good. Now all that is missing is a link from www.kernel.org,
>>>maybe. Peter, what do you think?
>>>
>>
>>I'd rather keep the collection itself on kernel.org.
> 
> 
> No problem.  Let me know where.
> 

Do you have a kernel.org account already?  If not, please send a GPG key 
to ftpadmin@kernel.org and put a brief reason for the request ("2.4 
critical patches archive").

	-hpa

Re: Ptrace hole / Linux 2.2.25

[Dave Jones]

On Sun, Mar 23, 2003 at 06:54:37PM -0800, H. Peter Anvin wrote:
 > >Looks good. Now all that is missing is a link from www.kernel.org,
 > >maybe. Peter, what do you think?
 > I'd rather keep the collection itself on kernel.org.

Another possibility just occured to me.
It'd be useful to add a feature that adds a check to the
build process..

"Download post-release errata ? [Y/n]"

and have it wget patches from k.o, verify signatures and auto-apply them,
which removes the "admin didnt even know there were patches
that needed to be applied" possibility.

		Dave

Re: Ptrace hole / Linux 2.2.25

[Pavel Machek]

Hi!

>  > >maybe. Peter, what do you think?
>  > I'd rather keep the collection itself on kernel.org.
> 
> Another possibility just occured to me.
> It'd be useful to add a feature that adds a check to the
> build process..
> 
> "Download post-release errata ? [Y/n]"
> 
> and have it wget patches from k.o, verify signatures and auto-apply them,
> which removes the "admin didnt even know there were patches
> that needed to be applied" possibility.
> 

That looks like ugly can of worms to me.
"what kernel do you have?"
"2.4.25 and it did two downloads; I was
compiling it on the friday night"

				Pavel
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...

Re: Ptrace hole / Linux 2.2.25

[Dave Jones]

On Thu, Mar 27, 2003 at 08:47:27AM +0100, Pavel Machek wrote:

 > > and have it wget patches from k.o, verify signatures and auto-apply them,
 > > which removes the "admin didnt even know there were patches
 > > that needed to be applied" possibility.
 > 
 > That looks like ugly can of worms to me.
 > "what kernel do you have?"
 > "2.4.25 and it did two downloads; I was
 > compiling it on the friday night"

So make one of the patches change extra-version to -errataN or the like.

		Dave

Re: Ptrace hole / Linux 2.2.25

[H. Peter Anvin]

Dave Jones wrote:
> On Thu, Mar 27, 2003 at 08:47:27AM +0100, Pavel Machek wrote:
> 
>  > > and have it wget patches from k.o, verify signatures and auto-apply them,
>  > > which removes the "admin didnt even know there were patches
>  > > that needed to be applied" possibility.
>  > 
>  > That looks like ugly can of worms to me.
>  > "what kernel do you have?"
>  > "2.4.25 and it did two downloads; I was
>  > compiling it on the friday night"
> 
> So make one of the patches change extra-version to -errataN or the like.
> 

Basically what we're talking about now is someone to maintain an "errata
tree" -- someone to maintain sub-point releases (2.4.25.1, .2, etc.) and
to decide what those are.

The other option would be to have it called something like
2.4.25-ep36-ep42-ep96 if errata patches 36, 42 and 96 were applied.

I think sub-point releases are better, since it at least cuts down the
number of possible combinations.

	-hpa

Re: Ptrace hole / Linux 2.2.25

[Jörn Engel]

On Wed, 26 March 2003 12:41:35 -0800, H. Peter Anvin wrote:
> >  > 
> >  > That looks like ugly can of worms to me.
> >  > "what kernel do you have?"
> >  > "2.4.25 and it did two downloads; I was
> >  > compiling it on the friday night"

It look like a good thing to me, iff done right. iff.

> > So make one of the patches change extra-version to -errataN or the like.

And the script doing the automatic downloads should refuse to apply
any patch that doesn't change extra-version. When something like this
happens to -ac2, people download it manually and know, it is in fact
-ac3. But here...

> Basically what we're talking about now is someone to maintain an "errata
> tree" -- someone to maintain sub-point releases (2.4.25.1, .2, etc.) and
> to decide what those are.
> 
> The other option would be to have it called something like
> 2.4.25-ep36-ep42-ep96 if errata patches 36, 42 and 96 were applied.
> 
> I think sub-point releases are better, since it at least cuts down the
> number of possible combinations.

I agree. There should be no point in finer granularity than sub-point
releases.  Even those should be kept as small as possible, completely
empty if possible.

Jörn

-- 
Homo Sapiens is a goal, not a description.
-- unknown

Re: Ptrace hole / Linux 2.2.25

[James Bourne]

On Wed, 26 Mar 2003, H. Peter Anvin wrote:

> Dave Jones wrote:
> > On Thu, Mar 27, 2003 at 08:47:27AM +0100, Pavel Machek wrote:
> > 
> >  > > and have it wget patches from k.o, verify signatures and auto-apply them,
> >  > > which removes the "admin didnt even know there were patches
> >  > > that needed to be applied" possibility.
> >  > 
> >  > That looks like ugly can of worms to me.
> >  > "what kernel do you have?"
> >  > "2.4.25 and it did two downloads; I was
> >  > compiling it on the friday night"
> > 
> > So make one of the patches change extra-version to -errataN or the like.
> > 
> 
> Basically what we're talking about now is someone to maintain an "errata
> tree" -- someone to maintain sub-point releases (2.4.25.1, .2, etc.) and
> to decide what those are.

I agree with this format vs. the ep* format as it would be far easier to
find the latest cumulative errata patch...  Wouldn't the sub-point release
be a part of the errata patch?  I think it might get out of hand if there
are too many different bits to deal with, the errata tree and sub-point
release being seperate I mean..  IE if someone grabs the errata patches they
should then be running the most secure and stable version of the current
kernel available...  This also prevents having multiple trees around that
require sync, as there would be no errata patches required for a kernel with
no urgent patch releases (either bugfix or security related).  2.4.25 would
basically be 2.4.25.0 and until someone finds a show stopping problem there
wouldn't be the need for any additional patches...

Regards
James Bourne


> 
> The other option would be to have it called something like
> 2.4.25-ep36-ep42-ep96 if errata patches 36, 42 and 96 were applied.
> 
> I think sub-point releases are better, since it at least cuts down the
> number of possible combinations.
> 
> 	-hpa
> 
> 

-- 
James Bourne                  | Email:            jbourne@hardrock.org          
Unix Systems Administrator    | WWW:           http://www.hardrock.org
Custom Unix Programming       | Linux:  The choice of a GNU generation
----------------------------------------------------------------------
 "All you need's an occasional kick in the philosophy." Frank Herbert  

re: Ptrace hole / Linux 2.2.25

[Tomas Szepe]

> [mj@ucw.cz]
> 
> > There are vendors, there are free distributions too. 
> 
> Yes, but that's pretty irrelevant. People should not depend on such
> sources to get security fixes. Anything so critical should be included
> in the official kernel as soon as possible -- any reasons against?

What troubles *me* is that obviously I have missed the post with
Marcelo's opinion on this.

-- 
Tomas Szepe <szepe@pinerecords.com>

re: Ptrace hole / Linux 2.2.25

[Alan Cox]

On Mon, 2003-03-17 at 18:20, Tomas Szepe wrote:
> Is this critical enough for 2.4.21 to go out?  Or can it wait like
> some other fairly serious stuff such as the ext3 fixes?  What about
> the current state of IDE?
> 
> Would it make sense to repackage 2.4.20 into something like 2.4.20-p1
> or 2.4.20.1 with only the critical stuff applied?

If you build your own kernels apply the patch, if you use vendor kernels
then you can expect vendor kernel updates to appear or have already
appeared

re: Ptrace hole / Linux 2.2.25

[Tomas Szepe]

> [alan@lxorguk.ukuu.org.uk]
> 
> On Mon, 2003-03-17 at 18:20, Tomas Szepe wrote:
> > Is this critical enough for 2.4.21 to go out?  Or can it wait like
> > some other fairly serious stuff such as the ext3 fixes?  What about
> > the current state of IDE?
> > 
> > Would it make sense to repackage 2.4.20 into something like 2.4.20-p1
> > or 2.4.20.1 with only the critical stuff applied?
> 
> If you build your own kernels apply the patch, if you use vendor kernels
> then you can expect vendor kernel updates to appear or have already
> appeared

You have avoided the question(s).  8)

-- 
Tomas Szepe <szepe@pinerecords.com>

re: Ptrace hole / Linux 2.2.25

[Neale Banks]

On Mon, 17 Mar 2003, Tomas Szepe wrote:

> > [alan@lxorguk.ukuu.org.uk]
> > 
> > On Mon, 2003-03-17 at 18:20, Tomas Szepe wrote:
> > > Is this critical enough for 2.4.21 to go out?  Or can it wait like
> > > some other fairly serious stuff such as the ext3 fixes?  What about
> > > the current state of IDE?
> > > 
> > > Would it make sense to repackage 2.4.20 into something like 2.4.20-p1
> > > or 2.4.20.1 with only the critical stuff applied?
> > 
> > If you build your own kernels apply the patch, if you use vendor kernels
> > then you can expect vendor kernel updates to appear or have already
> > appeared
> 
> You have avoided the question(s).  8)

I think Alan's trying to teach us how to fish ;-)

That said, IMVHO something like this does constitute an argument for
2.4.20-p1 (due to the amount of change that's already racked up for
2.2.21).

Regards,
Neale.

re: Ptrace hole / Linux 2.2.25

[James Bourne]

On Tue, 18 Mar 2003, Neale Banks wrote:

> On Mon, 17 Mar 2003, Tomas Szepe wrote:
> 
> > > [alan@lxorguk.ukuu.org.uk]
> > > 
> > > If you build your own kernels apply the patch, if you use vendor kernels
> > > then you can expect vendor kernel updates to appear or have already
> > > appeared
> > 
> > You have avoided the question(s).  8)
> 
> I think Alan's trying to teach us how to fish ;-)
> 
> That said, IMVHO something like this does constitute an argument for
> 2.4.20-p1 (due to the amount of change that's already racked up for
> 2.2.21).

Hi all,
There is a clean patch for 2.4.20 (taken from Alans original patch) at
http://www.hardrock.org/kernel/2.4.20/linux-2.4.20-ptrace.patch

I am currently using it on 3 production systems at work and
it seems stable. You will notice processes which are not dumpable with
this patch, as the output from ps ax will contain the process name in []
square brackets.

Regards
James Bourne

> Regards,
> Neale.

-- 
James Bourne, Supervisor Data Centre Operations
Mount Royal College, Calgary, AB, CA
www.mtroyal.ab.ca

******************************************************************************
This communication is intended for the use of the recipient to which it is
addressed, and may contain confidential, personal, and or privileged
information. Please contact the sender immediately if you are not the
intended recipient of this communication, and do not copy, distribute, or
take action relying on it. Any communication received in error, or
subsequent reply, should be deleted or destroyed.
******************************************************************************


"There are only 10 types of people in this world: those who
understand binary and those who don't."

Re: Ptrace hole / Linux 2.2.25

[Ben Pfaff]

Alan Cox <alan@redhat.com> writes:

> A patch for Linux 2.4.20/Linux 2.4.21pre is attached. The patch also
> subtly changes the PR_SET_DUMPABLE prctl. We believe this is neccessary and 
> that it will not affect any software. The functionality change is specific 
> to unusual debugging situations.

I am concerned about this change because it will break sandboxing
software that I have written, which uses prctl() to turn
dumpability back on so that it can open a file, setuid(), and
then execve() through the open file via /proc/self/fd/#.  Without
calling prctl(), the ownership of /proc/self/fd/* becomes root,
so the process cannot exec it after it drops privileges.  It uses
prctl() in other places to get the same effect in /proc, but
that's one of the most critical.
-- 
<blp@cs.stanford.edu> <pfaffben@msu.edu> <pfaffben@debian.org> <blp@gnu.org>
  Stanford Ph.D. Student - MSU Alumnus - Debian Maintainer - GNU Developer
                              www.benpfaff.org

Re: Ptrace hole / Linux 2.2.25

[Alan Cox]

On Mon, 2003-03-17 at 18:39, Ben Pfaff wrote:
> I am concerned about this change because it will break sandboxing
> software that I have written, which uses prctl() to turn
> dumpability back on so that it can open a file, setuid(), and
> then execve() through the open file via /proc/self/fd/#.  Without
> calling prctl(), the ownership of /proc/self/fd/* becomes root,
> so the process cannot exec it after it drops privileges.  It uses
> prctl() in other places to get the same effect in /proc, but
> that's one of the most critical.

The dumpability is per mm, which means that you have to consider
all the cases of a thread being created in parallel to dumpability
being enabled.

So consider a three threaded process. Thread one triggers kernel thread
creation, thread two turns dumpability back on, thread three ptraces
the new kernel thread.

Proving that is safe is non trivial so the current patch chooses not
to attempt it. For 2.4.21 proper someone can sit down and do the needed
verification if they wish

Re: Ptrace hole / Linux 2.2.25

[mlafon]

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



Alan Cox wrote:
> Vulnerability: CAN-2003-0127

> The Linux 2.2 and Linux 2.4 kernels have a flaw in ptrace. This hole allows
> local users to obtain full privileges. Remote exploitation of this hole is
> not possible. Linux 2.5 is not believed to be vulnerable.

The patch breaks /proc/<pid>/cmdline and /proc/<pid>/environ for 'non dumpable'
processes, even for root.

We need to access theses proc files for processes monitoring.

Included is a patch to restore this functionnality for root.

Any comments ?
(See attached file: cmdline_environ_fix.diff)
--
Mathieu Lafon - Arkoon Network Security

[-- Attachment #2: cmdline_environ_fix.diff --]
[-- Type: application/octet-stream, Size: 398 bytes --]

diff -u -r1.3.24.1 ptrace.c
--- linux-2.4/kernel/ptrace.c	2003/03/19 10:50:57	1.3.24.1
+++ linux-2.4/kernel/ptrace.c	2003/03/19 10:54:45
@@ -140,7 +140,7 @@
 	/* Worry about races with exit() */
 	task_lock(tsk);
 	mm = tsk->mm;
-	if (!is_dumpable(tsk) || (&init_mm == mm))
+	if ((!is_dumpable(tsk) || (&init_mm == mm)) && (current->uid != 0))
 		mm = NULL;
 	if (mm)
 		atomic_inc(&mm->mm_users);

Re: Ptrace hole / Linux 2.2.25

[Matthew Grant]

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

Mistyped linux-kernel address  %-< 

-----Forwarded Message----- 

From: Matthew Grant <grantma@anathoth.gen.nz>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Jeff Dike <jdike@karaya.com>, liinux-kerel@vger.kernel.org
Subject: Re: Ptrace hole / Linux 2.2.25
Date: 20 Mar 2003 07:55:45 +1200

Alan,

This patch really breaks UML using the skas mode of thread tracing skas3
patch on quite a significant amount of machines out there. The skas mode
is a lot more secure than the traditional UML tt mode. I guess this is
related to the below...

I am running a UML site that a lot of hospitals ad clinics in Bangldesh
depend on for there email.  It allows them to work around the corruption
and agrandidement of the ISPs over there.  The skas3 mode patch is
needed for the site to run securely.  Tracing thread mode does not cut
it.

There are also a large number of other telehoused ISP virtual hosting 
machines that use this stuff, and it is actually proving to be quite
reliable.

I have attached the skas3 patch that Jeff Dike is currently using, and
the patch that you have produced.  Could you please look into the clash
between them, and get it fixed.

Thank you - there are lots out there who will appreciate this.

Cheers,

Matthew Grant

On Mon, 2003-03-17 at 18:39, Ben Pfaff wrote:
> I am concerned about this change because it will break sandboxing
> software that I have written, which uses prctl() to turn
> dumpability back on so that it can open a file, setuid(), and
> then execve() through the open file via /proc/self/fd/#. Without
> calling prctl(), the ownership of /proc/self/fd/* becomes root,
> so the process cannot exec it after it drops privileges. It uses
> prctl() in other places to get the same effect in /proc, but
> that's one of the most critical.

The dumpability is per mm, which means that you have to consider
all the cases of a thread being created in parallel to dumpability
being enabled.

So consider a three threaded process. Thread one triggers kernel thread
creation, thread two turns dumpability back on, thread three ptraces
the new kernel thread.

Proving that is safe is non trivial so the current patch chooses not
to attempt it. For 2.4.21 proper someone can sit down and do the needed
verification if they wish 

-- 
===============================================================================
Matthew Grant	     /\	 ^/\^	grantma@anathoth.gen.nz      /~~~~\
A Linux Network Guy /~~\^/~~\_/~~~~~\_______/~~~~~~~~~~\____/******\
===GPG KeyID: 2EE20270  FingerPrint:
8C2535E1A11DF3EA5EA19125BA4E790E2EE20270==

________________________________________________________________________

diff -Naur host/arch/i386/config.in host-ptrace/arch/i386/config.in
--- host/arch/i386/config.in	Fri Aug  9 15:57:14 2002
+++ host-ptrace/arch/i386/config.in	Sun Nov 10 18:40:09 2002
@@ -291,6 +291,8 @@
    bool '    Use real mode APM BIOS call to power off' CONFIG_APM_REAL_MODE_POWER_OFF
 fi
 
+bool '/proc/mm' CONFIG_PROC_MM
+
 endmenu
 
 source drivers/mtd/Config.in
diff -Naur host/arch/i386/kernel/ldt.c host-ptrace/arch/i386/kernel/ldt.c
--- host/arch/i386/kernel/ldt.c	Fri Oct 26 00:01:41 2001
+++ host-ptrace/arch/i386/kernel/ldt.c	Sun Nov  3 18:37:48 2002
@@ -24,11 +24,12 @@
  * assured by user-space anyway. Writes are atomic, to protect
  * the security checks done on new descriptors.
  */
-static int read_ldt(void * ptr, unsigned long bytecount)
+static int read_ldt(struct task_struct *task, void * ptr, 
+		    unsigned long bytecount)
 {
 	int err;
 	unsigned long size;
-	struct mm_struct * mm = current->mm;
+	struct mm_struct * mm = task->mm;
 
 	err = 0;
 	if (!mm->context.segments)
@@ -64,9 +65,10 @@
 	return err;
 }
 
-static int write_ldt(void * ptr, unsigned long bytecount, int oldmode)
+static int write_ldt(struct task_struct *task, void * ptr, 
+		     unsigned long bytecount, int oldmode)
 {
-	struct mm_struct * mm = current->mm;
+	struct mm_struct * mm = task->mm;
 	__u32 entry_1, entry_2, *lp;
 	int error;
 	struct modify_ldt_ldt_s ldt_info;
@@ -148,23 +150,29 @@
 	return error;
 }
 
-asmlinkage int sys_modify_ldt(int func, void *ptr, unsigned long bytecount)
+int modify_ldt(struct task_struct *task, int func, void *ptr, 
+	       unsigned long bytecount)
 {
 	int ret = -ENOSYS;
 
 	switch (func) {
 	case 0:
-		ret = read_ldt(ptr, bytecount);
+		ret = read_ldt(task, ptr, bytecount);
 		break;
 	case 1:
-		ret = write_ldt(ptr, bytecount, 1);
+		ret = write_ldt(task, ptr, bytecount, 1);
 		break;
 	case 2:
 		ret = read_default_ldt(ptr, bytecount);
 		break;
 	case 0x11:
-		ret = write_ldt(ptr, bytecount, 0);
+		ret = write_ldt(task, ptr, bytecount, 0);
 		break;
 	}
 	return ret;
+}
+
+asmlinkage int sys_modify_ldt(int func, void *ptr, unsigned long bytecount)
+{
+	return(modify_ldt(current, func, ptr, bytecount));
 }
diff -Naur host/arch/i386/kernel/process.c host-ptrace/arch/i386/kernel/process.c
--- host/arch/i386/kernel/process.c	Fri Aug  9 15:57:14 2002
+++ host-ptrace/arch/i386/kernel/process.c	Wed Nov  6 22:12:45 2002
@@ -551,13 +551,11 @@
  * we do not have to muck with descriptors here, that is
  * done in switch_mm() as needed.
  */
-void copy_segments(struct task_struct *p, struct mm_struct *new_mm)
+void mm_copy_segments(struct mm_struct *old_mm, struct mm_struct *new_mm)
 {
-	struct mm_struct * old_mm;
 	void *old_ldt, *ldt;
 
 	ldt = NULL;
-	old_mm = current->mm;
 	if (old_mm && (old_ldt = old_mm->context.segments) != NULL) {
 		/*
 		 * Completely new LDT, we initialize it from the parent:
@@ -570,6 +568,16 @@
 	}
 	new_mm->context.segments = ldt;
 	new_mm->context.cpuvalid = ~0UL;	/* valid on all CPU's - they can't have stale data */
+}
+
+void copy_segments(struct task_struct *p, struct mm_struct *new_mm)
+{
+	mm_copy_segments(current->mm, new_mm);
+}
+
+void copy_task_segments(struct task_struct *from, struct mm_struct *new_mm)
+{
+	mm_copy_segments(from->mm, new_mm);
 }
 
 /*
diff -Naur host/arch/i386/kernel/ptrace.c host-ptrace/arch/i386/kernel/ptrace.c
--- host/arch/i386/kernel/ptrace.c	Fri Aug  9 15:57:14 2002
+++ host-ptrace/arch/i386/kernel/ptrace.c	Mon Nov 11 19:03:38 2002
@@ -147,6 +147,11 @@
 	put_stack_long(child, EFL_OFFSET, tmp);
 }
 
+extern int modify_ldt(struct task_struct *task, int func, void *ptr, 
+		      unsigned long bytecount);
+
+extern struct mm_struct *proc_mm_get_mm(int fd);
+
 asmlinkage int sys_ptrace(long request, long pid, long addr, long data)
 {
 	struct task_struct *child;
@@ -415,6 +420,53 @@
 			child->ptrace |= PT_TRACESYSGOOD;
 		else
 			child->ptrace &= ~PT_TRACESYSGOOD;
+		ret = 0;
+		break;
+	}
+
+	case PTRACE_FAULTINFO: {
+		struct ptrace_faultinfo fault;
+
+		fault = ((struct ptrace_faultinfo) 
+			{ .is_write	= child->thread.error_code,
+			  .addr		= child->thread.cr2 });
+		ret = copy_to_user((unsigned long *) data, &fault, 
+				   sizeof(fault));
+		if(ret)
+			break;
+		break;
+	}
+	case PTRACE_SIGPENDING:
+		ret = copy_to_user((unsigned long *) data, 
+				   &child->pending.signal,
+				   sizeof(child->pending.signal));
+		break;
+
+	case PTRACE_LDT: {
+		struct ptrace_ldt ldt;
+
+		if(copy_from_user(&ldt, (unsigned long *) data, 
+				  sizeof(ldt))){
+			ret = -EIO;
+			break;
+		}
+		ret = modify_ldt(child, ldt.func, ldt.ptr, ldt.bytecount);
+		break;
+	}
+
+	case PTRACE_SWITCH_MM: {
+		struct mm_struct *old = child->mm;
+		struct mm_struct *new = proc_mm_get_mm(data);
+
+		if(IS_ERR(new)){
+			ret = PTR_ERR(new);
+			break;
+		}
+
+		atomic_inc(&new->mm_users);
+		child->mm = new;
+		child->active_mm = new;
+		mmput(old);
 		ret = 0;
 		break;
 	}
diff -Naur host/arch/i386/kernel/sys_i386.c host-ptrace/arch/i386/kernel/sys_i386.c
--- host/arch/i386/kernel/sys_i386.c	Mon Mar 19 15:35:09 2001
+++ host-ptrace/arch/i386/kernel/sys_i386.c	Mon Nov 11 17:23:25 2002
@@ -40,7 +40,7 @@
 }
 
 /* common code for old and new mmaps */
-static inline long do_mmap2(
+long do_mmap2(struct mm_struct *mm,
 	unsigned long addr, unsigned long len,
 	unsigned long prot, unsigned long flags,
 	unsigned long fd, unsigned long pgoff)
@@ -55,9 +55,9 @@
 			goto out;
 	}
 
-	down_write(&current->mm->mmap_sem);
-	error = do_mmap_pgoff(file, addr, len, prot, flags, pgoff);
-	up_write(&current->mm->mmap_sem);
+	down_write(&mm->mmap_sem);
+	error = do_mmap_pgoff(mm, file, addr, len, prot, flags, pgoff);
+	up_write(&mm->mmap_sem);
 
 	if (file)
 		fput(file);
@@ -69,7 +69,7 @@
 	unsigned long prot, unsigned long flags,
 	unsigned long fd, unsigned long pgoff)
 {
-	return do_mmap2(addr, len, prot, flags, fd, pgoff);
+	return do_mmap2(current->mm, addr, len, prot, flags, fd, pgoff);
 }
 
 /*
@@ -100,7 +100,7 @@
 	if (a.offset & ~PAGE_MASK)
 		goto out;
 
-	err = do_mmap2(a.addr, a.len, a.prot, a.flags, a.fd, a.offset >> PAGE_SHIFT);
+	err = do_mmap2(current->mm, a.addr, a.len, a.prot, a.flags, a.fd, a.offset >> PAGE_SHIFT);
 out:
 	return err;
 }
diff -Naur host/include/asm-i386/processor.h host-ptrace/include/asm-i386/processor.h
--- host/include/asm-i386/processor.h	Sun Nov 10 18:47:37 2002
+++ host-ptrace/include/asm-i386/processor.h	Mon Nov 11 17:33:30 2002
@@ -436,6 +436,8 @@
 extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
 
 /* Copy and release all segment info associated with a VM */
+extern void mm_copy_segments(struct mm_struct *old_mm, 
+			     struct mm_struct *new_mm);
 extern void copy_segments(struct task_struct *p, struct mm_struct * mm);
 extern void release_segments(struct mm_struct * mm);
 
diff -Naur host/include/asm-i386/ptrace.h host-ptrace/include/asm-i386/ptrace.h
--- host/include/asm-i386/ptrace.h	Sun Sep 23 19:20:51 2001
+++ host-ptrace/include/asm-i386/ptrace.h	Sun Nov 10 18:36:22 2002
@@ -51,6 +51,22 @@
 
 #define PTRACE_SETOPTIONS         21
 
+struct ptrace_faultinfo {
+	int is_write;
+	unsigned long addr;
+};
+
+struct ptrace_ldt {
+	int func;
+  	void *ptr;
+	unsigned long bytecount;
+};
+
+#define PTRACE_FAULTINFO 52
+#define PTRACE_SIGPENDING 53
+#define PTRACE_LDT 54
+#define PTRACE_SWITCH_MM 55
+
 /* options set using PTRACE_SETOPTIONS */
 #define PTRACE_O_TRACESYSGOOD     0x00000001
 
diff -Naur host/include/linux/mm.h host-ptrace/include/linux/mm.h
--- host/include/linux/mm.h	Fri Aug 30 15:03:44 2002
+++ host-ptrace/include/linux/mm.h	Mon Nov 11 19:08:53 2002
@@ -492,6 +492,9 @@
 int get_user_pages(struct task_struct *tsk, struct mm_struct *mm, unsigned long start,
 		int len, int write, int force, struct page **pages, struct vm_area_struct **vmas);
 
+extern long do_mprotect(struct mm_struct *mm, unsigned long start, 
+			size_t len, unsigned long prot);
+
 /*
  * On a two-level page table, this ends up being trivial. Thus the
  * inlining and the symmetry break with pte_alloc() that does all
@@ -539,9 +542,10 @@
 
 extern unsigned long get_unmapped_area(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
 
-extern unsigned long do_mmap_pgoff(struct file *file, unsigned long addr,
-	unsigned long len, unsigned long prot,
-	unsigned long flag, unsigned long pgoff);
+extern unsigned long do_mmap_pgoff(struct mm_struct *mm, 
+				   struct file *file, unsigned long addr,
+				   unsigned long len, unsigned long prot,
+				   unsigned long flag, unsigned long pgoff);
 
 static inline unsigned long do_mmap(struct file *file, unsigned long addr,
 	unsigned long len, unsigned long prot,
@@ -551,7 +555,7 @@
 	if ((offset + PAGE_ALIGN(len)) < offset)
 		goto out;
 	if (!(offset & ~PAGE_MASK))
-		ret = do_mmap_pgoff(file, addr, len, prot, flag, offset >> PAGE_SHIFT);
+		ret = do_mmap_pgoff(current->mm, file, addr, len, prot, flag, offset >> PAGE_SHIFT);
 out:
 	return ret;
 }
diff -Naur host/include/linux/proc_mm.h host-ptrace/include/linux/proc_mm.h
--- host/include/linux/proc_mm.h	Wed Dec 31 19:00:00 1969
+++ host-ptrace/include/linux/proc_mm.h	Mon Nov 11 17:41:09 2002
@@ -0,0 +1,44 @@
+/* 
+ * Copyright (C) 2002 Jeff Dike (jdike@karaya.com)
+ * Licensed under the GPL
+ */
+
+#ifndef __PROC_MM_H
+#define __PROC_MM_H
+
+#define MM_MMAP 54
+#define MM_MUNMAP 55
+#define MM_MPROTECT 56
+#define MM_COPY_SEGMENTS 57
+
+struct mm_mmap {
+	unsigned long addr;
+	unsigned long len;
+	unsigned long prot;
+	unsigned long flags;
+	unsigned long fd;
+	unsigned long offset;
+};
+
+struct mm_munmap {
+	unsigned long addr;
+	unsigned long len;	
+};
+
+struct mm_mprotect {
+	unsigned long addr;
+	unsigned long len;
+        unsigned int prot;
+};
+
+struct proc_mm_op {
+	int op;
+	union {
+		struct mm_mmap mmap;
+		struct mm_munmap munmap;
+	        struct mm_mprotect mprotect;
+		int copy_segments;
+	} u;
+};
+
+#endif
diff -Naur host/mm/Makefile host-ptrace/mm/Makefile
--- host/mm/Makefile	Fri Aug  9 15:57:31 2002
+++ host-ptrace/mm/Makefile	Sun Nov 10 18:37:33 2002
@@ -17,5 +17,6 @@
 	    shmem.o
 
 obj-$(CONFIG_HIGHMEM) += highmem.o
+obj-$(CONFIG_PROC_MM) += proc_mm.o
 
 include $(TOPDIR)/Rules.make
diff -Naur host/mm/mmap.c host-ptrace/mm/mmap.c
--- host/mm/mmap.c	Fri Aug  9 15:57:31 2002
+++ host-ptrace/mm/mmap.c	Mon Nov 11 17:24:18 2002
@@ -390,10 +390,11 @@
 	return 0;
 }
 
-unsigned long do_mmap_pgoff(struct file * file, unsigned long addr, unsigned long len,
-	unsigned long prot, unsigned long flags, unsigned long pgoff)
+unsigned long do_mmap_pgoff(struct mm_struct *mm, struct file * file, 
+			    unsigned long addr, unsigned long len,
+			    unsigned long prot, unsigned long flags, 
+			    unsigned long pgoff)
 {
-	struct mm_struct * mm = current->mm;
 	struct vm_area_struct * vma, * prev;
 	unsigned int vm_flags;
 	int correct_wcount = 0;
diff -Naur host/mm/mprotect.c host-ptrace/mm/mprotect.c
--- host/mm/mprotect.c	Fri Aug  9 15:57:31 2002
+++ host-ptrace/mm/mprotect.c	Mon Nov 11 17:47:58 2002
@@ -264,7 +264,8 @@
 	return 0;
 }
 
-asmlinkage long sys_mprotect(unsigned long start, size_t len, unsigned long prot)
+long do_mprotect(struct mm_struct *mm, unsigned long start, size_t len, 
+		 unsigned long prot)
 {
 	unsigned long nstart, end, tmp;
 	struct vm_area_struct * vma, * next, * prev;
@@ -281,9 +282,9 @@
 	if (end == start)
 		return 0;
 
-	down_write(&current->mm->mmap_sem);
+	down_write(&mm->mmap_sem);
 
-	vma = find_vma_prev(current->mm, start, &prev);
+	vma = find_vma_prev(mm, start, &prev);
 	error = -ENOMEM;
 	if (!vma || vma->vm_start > start)
 		goto out;
@@ -332,6 +333,11 @@
 		prev->vm_mm->map_count--;
 	}
 out:
-	up_write(&current->mm->mmap_sem);
+	up_write(&mm->mmap_sem);
 	return error;
+}
+
+asmlinkage long sys_mprotect(unsigned long start, size_t len, unsigned long prot)
+{
+	return(do_mprotect(current->mm, start, len, prot));
 }
diff -Naur host/mm/proc_mm.c host-ptrace/mm/proc_mm.c
--- host/mm/proc_mm.c	Wed Dec 31 19:00:00 1969
+++ host-ptrace/mm/proc_mm.c	Mon Nov 11 19:07:52 2002
@@ -0,0 +1,173 @@
+/* 
+ * Copyright (C) 2002 Jeff Dike (jdike@karaya.com)
+ * Licensed under the GPL
+ */
+
+#include "linux/proc_fs.h"
+#include "linux/proc_mm.h"
+#include "linux/file.h"
+#include "asm/uaccess.h"
+#include "asm/mmu_context.h"
+
+static struct file_operations proc_mm_fops;
+
+struct mm_struct *proc_mm_get_mm(int fd)
+{
+	struct mm_struct *ret = ERR_PTR(-EBADF);
+	struct file *file;
+
+	file = fget(fd);
+	if (!file)
+		goto out;
+
+	ret = ERR_PTR(-EINVAL);
+	if(file->f_op != &proc_mm_fops)
+		goto out_fput;
+
+	ret = file->private_data;
+
+ out_fput:
+	fput(file);
+ out:
+	return(ret);
+}
+
+extern long do_mmap2(struct mm_struct *mm, unsigned long addr, 
+		     unsigned long len, unsigned long prot, 
+		     unsigned long flags, unsigned long fd,
+		     unsigned long pgoff);
+
+static ssize_t write_proc_mm(struct file *file, const char *buffer,
+			     size_t count, loff_t *ppos)
+{
+	struct mm_struct *mm = file->private_data;
+	struct proc_mm_op req;
+	int n, ret;
+
+	if(count > sizeof(req))
+		return(-EINVAL);
+
+	n = copy_from_user(&req, buffer, count);
+	if(n != 0)
+		return(-EFAULT);
+
+	ret = count;
+	switch(req.op){
+	case MM_MMAP: {
+		struct mm_mmap *map = &req.u.mmap;
+
+		ret = do_mmap2(mm, map->addr, map->len, map->prot, 
+			       map->flags, map->fd, map->offset >> PAGE_SHIFT);
+		if((ret & ~PAGE_MASK) == 0)
+			ret = count;
+	
+		break;
+	}
+	case MM_MUNMAP: {
+		struct mm_munmap *unmap = &req.u.munmap;
+
+		down_write(&mm->mmap_sem);
+		ret = do_munmap(mm, unmap->addr, unmap->len);
+		up_write(&mm->mmap_sem);
+
+		if(ret == 0)
+			ret = count;
+		break;
+	}
+	case MM_MPROTECT: {
+		struct mm_mprotect *protect = &req.u.mprotect;
+
+		ret = do_mprotect(mm, protect->addr, protect->len, 
+				  protect->prot);
+		if(ret == 0)
+			ret = count;
+		break;
+	}
+
+	case MM_COPY_SEGMENTS: {
+		struct mm_struct *from = proc_mm_get_mm(req.u.copy_segments);
+
+		if(IS_ERR(from)){
+			ret = PTR_ERR(from);
+			break;
+		}
+
+		mm_copy_segments(from, mm);
+		break;
+	}
+	default:
+		ret = -EINVAL;
+		break;
+	}
+
+	return(ret);
+}
+
+static int open_proc_mm(struct inode *inode, struct file *file)
+{
+	struct mm_struct *mm = mm_alloc();
+	int ret;
+
+	ret = -ENOMEM;
+	if(mm == NULL)
+		goto out_mem;
+
+	ret = init_new_context(current, mm);
+	if(ret)
+		goto out_free;
+
+	spin_lock(&mmlist_lock);
+	list_add(&mm->mmlist, &current->mm->mmlist);
+	mmlist_nr++;
+	spin_unlock(&mmlist_lock);
+
+	file->private_data = mm;
+
+	return(0);
+
+ out_free:
+	mmput(mm);
+ out_mem:
+	return(ret);
+}
+
+static int release_proc_mm(struct inode *inode, struct file *file)
+{
+	struct mm_struct *mm = file->private_data;
+
+	mmput(mm);
+	return(0);
+}
+
+static struct file_operations proc_mm_fops = {
+	.open		= open_proc_mm,
+	.release	= release_proc_mm,
+	.write		= write_proc_mm,
+};
+
+static int make_proc_mm(void)
+{
+	struct proc_dir_entry *ent;
+
+	ent = create_proc_entry("mm", 0222, &proc_root);
+	if(ent == NULL){
+		printk("make_proc_mm : Failed to register /proc/mm\n");
+		return(0);
+	}
+	ent->proc_fops = &proc_mm_fops;
+
+	return(0);
+}
+
+__initcall(make_proc_mm);
+
+/*
+ * Overrides for Emacs so that we follow Linus's tabbing style.
+ * Emacs will notice this stuff at the end of the file and automatically
+ * adjust the settings for this buffer only.  This must remain at the end
+ * of the file.
+ * ---------------------------------------------------------------------------
+ * Local variables:
+ * c-file-style: "linux"
+ * End:
+ */

________________________________________________________________________

                                                                LWN.net Logo 


                                                                Sponsored Link

   TrustCommerce

   E-Commerce & credit card processing - the Open Source way!
     ___________________________________________________________________________________________________________________________________

   You are not logged in
   Log in now
   Create an account
   Subscribe to LWN

   Recent Features

   LWN.net Weekly Edition for March 13, 2003

   A look at the SCO complaint

   LWN.net Weekly Edition for March 6, 2003

   LWN.net Weekly Edition for February 27, 2003

   LWN.net Weekly Edition for February 20, 2003

   Printable page


       Home      Weekly edition     Archives    Security  Calendar
   Distributions Penguin Gallery Kernel patches  Search   Old site
    LWN.net FAQ   Subscriptions    Advertise    Headlines Privacy

Ptrace vulnerability in 2.2 and 2.4 kernels

   From:   Alan Cox <alan@redhat.com>
   To:   editor@lwn.net, scoop@freshmeat.net, kernel@linuxtoday.com, kernel@linuxfr.org, rob@linuxberg.com, chris@linuxdev.net,
   kernel@linuxhq.com, kernel@linuxcare.com, marcelo@conectiva.com.br, ac-kernels@tonnikala.net
   Subject:   Ptrace vulnerability in Linux 2.2/2.4
   Date:   Mon, 17 Mar 2003 11:00:16 -0500 (EST)

Vulnerability: CAN-2003-0127

The Linux 2.2 and Linux 2.4 kernels have a flaw in ptrace. This hole allows
local users to obtain full privileges. Remote exploitation of this hole is
not possible. Linux 2.5 is not believed to be vulnerable.

Linux 2.2.25 has been released to correct Linux 2.2. It contains no other
changes. The bug fixes that would have been in 2.2.5pre1 will now appear in
2.2.26pre1. The patch will apply directly to most older 2.2 releases.

A patch for Linux 2.4.20/Linux 2.4.21pre is attached. The patch also
subtly changes the PR_SET_DUMPABLE prctl. We believe this is neccessary and
that it will not affect any software. The functionality change is specific
to unusual debugging situations.

We would like to thank Andrzej Szombierski who found the problem, and
wrote an initial patch. Seth Arnold cleaned up the 2.2 change. Arjan van
de Ven and Ben LaHaise identified additional problems with the original
fix.

Alan

diff -purN linux.orig/arch/alpha/kernel/entry.S linux/arch/alpha/kernel/entry.S
--- linux.orig/arch/alpha/kernel/entry.S        Thu Mar 13 12:01:46 2003
+++ linux/arch/alpha/kernel/entry.S     Thu Mar 13 13:28:49 2003
@@ -231,12 +231,12 @@ kernel_clone:
 .end   kernel_clone

 /*
- * kernel_thread(fn, arg, clone_flags)
+ * arch_kernel_thread(fn, arg, clone_flags)
  */
 .align 3
 .globl kernel_thread
 .ent   kernel_thread
-kernel_thread:
+arch_kernel_thread:
        ldgp    $29,0($27)      /* we can be called from a module */
        .frame $30, 4*8, $26
        subq    $30,4*8,$30
diff -purN linux.orig/arch/arm/kernel/process.c linux/arch/arm/kernel/process.c
--- linux.orig/arch/arm/kernel/process.c        Thu Mar 13 12:01:29 2003
+++ linux/arch/arm/kernel/process.c     Thu Mar 13 13:25:56 2003
@@ -366,7 +366,7 @@ void dump_thread(struct pt_regs * regs,
  * a system call from a "real" process, but the process memory space will
  * not be free'd until both the parent and the child have exited.
  */
-pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
+pid_t arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
 {
        pid_t __ret;

diff -purN linux.orig/arch/cris/kernel/entry.S linux/arch/cris/kernel/entry.S
--- linux.orig/arch/cris/kernel/entry.S Thu Mar 13 12:01:29 2003
+++ linux/arch/cris/kernel/entry.S      Thu Mar 13 13:30:30 2003
@@ -736,12 +736,12 @@ hw_bp_trig_ptr:
  * the grosser the code, at least with the gcc version in cris-dist-1.13.
  */

-/* int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags) */
+/* int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags) */
 /*                   r10                r11         r12  */

        .text
-       .global kernel_thread
-kernel_thread:
+       .global arch_kernel_thread
+arch_kernel_thread:

        /* Save ARG for later.  */
        move.d $r11, $r13
diff -purN linux.orig/arch/i386/kernel/process.c linux/arch/i386/kernel/process.c
--- linux.orig/arch/i386/kernel/process.c       Thu Mar 13 12:01:57 2003
+++ linux/arch/i386/kernel/process.c    Thu Mar 13 13:26:08 2003
@@ -495,7 +495,7 @@ void release_segments(struct mm_struct *
 /*
  * Create a kernel thread
  */
-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
        long retval, d0;

@@ -518,6 +518,7 @@ int kernel_thread(int (*fn)(void *), voi
                 "r" (arg), "r" (fn),
                 "b" (flags | CLONE_VM)
                : "memory");
+
        return retval;
 }

diff -purN linux.orig/arch/ia64/kernel/process.c linux/arch/ia64/kernel/process.c
--- linux.orig/arch/ia64/kernel/process.c       Thu Mar 13 12:01:29 2003
+++ linux/arch/ia64/kernel/process.c    Thu Mar 13 13:26:15 2003
@@ -220,7 +220,7 @@ ia64_load_extra (struct task_struct *tas
  *     |                     | <-- sp (lowest addr)
  *     +---------------------+
  *
- * Note: if we get called through kernel_thread() then the memory
+ * Note: if we get called through arch_kernel_thread() then the memory
  * above "(highest addr)" is valid kernel stack memory that needs to
  * be copied as well.
  *
@@ -469,7 +469,7 @@ ia64_set_personality (struct elf64_hdr *
 }

 pid_t
-kernel_thread (int (*fn)(void *), void *arg, unsigned long flags)
+arch_kernel_thread (int (*fn)(void *), void *arg, unsigned long flags)
 {
        struct task_struct *parent = current;
        int result, tid;
diff -purN linux.orig/arch/m68k/kernel/process.c linux/arch/m68k/kernel/process.c
--- linux.orig/arch/m68k/kernel/process.c       Thu Mar 13 12:01:29 2003
+++ linux/arch/m68k/kernel/process.c    Thu Mar 13 13:26:18 2003
@@ -124,7 +124,7 @@ void show_regs(struct pt_regs * regs)
 /*
  * Create a kernel thread
  */
-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
        int pid;
        mm_segment_t fs;
diff -purN linux.orig/arch/mips/kernel/process.c linux/arch/mips/kernel/process.c
--- linux.orig/arch/mips/kernel/process.c       Thu Mar 13 12:01:29 2003
+++ linux/arch/mips/kernel/process.c    Thu Mar 13 13:26:28 2003
@@ -155,7 +155,7 @@ void dump_thread(struct pt_regs *regs, s
 /*
  * Create a kernel thread
  */
-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
        long retval;

diff -purN linux.orig/arch/mips64/kernel/process.c linux/arch/mips64/kernel/process.c
--- linux.orig/arch/mips64/kernel/process.c     Thu Mar 13 12:01:29 2003
+++ linux/arch/mips64/kernel/process.c  Thu Mar 13 13:26:23 2003
@@ -152,7 +152,7 @@ void dump_thread(struct pt_regs *regs, s
 /*
  * Create a kernel thread
  */
-int kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
 {
        int retval;

diff -purN linux.orig/arch/parisc/kernel/process.c linux/arch/parisc/kernel/process.c
--- linux.orig/arch/parisc/kernel/process.c     Fri Feb  9 14:29:44 2001
+++ linux/arch/parisc/kernel/process.c  Thu Mar 13 13:26:36 2003
@@ -118,7 +118,7 @@ void machine_heartbeat(void)
  */

 extern pid_t __kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
-pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
+pid_t arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
 {

        /*
diff -purN linux.orig/arch/ppc/kernel/misc.S linux/arch/ppc/kernel/misc.S
--- linux.orig/arch/ppc/kernel/misc.S   Thu Mar 13 12:01:29 2003
+++ linux/arch/ppc/kernel/misc.S        Thu Mar 13 13:32:21 2003
@@ -899,9 +899,9 @@ _GLOBAL(cvt_df)

 /*
  * Create a kernel thread
- *   kernel_thread(fn, arg, flags)
+ *   arch_kernel_thread(fn, arg, flags)
  */
-_GLOBAL(kernel_thread)
+_GLOBAL(arch_kernel_thread)
        mr      r6,r3           /* function */
        ori     r3,r5,CLONE_VM  /* flags */
        li      r0,__NR_clone
diff -purN linux.orig/arch/ppc64/kernel/misc.S linux/arch/ppc64/kernel/misc.S
--- linux.orig/arch/ppc64/kernel/misc.S Thu Mar 13 12:01:30 2003
+++ linux/arch/ppc64/kernel/misc.S      Thu Mar 13 13:29:42 2003
@@ -493,9 +493,9 @@ _GLOBAL(cvt_df)

 /*
  * Create a kernel thread
- *   kernel_thread(fn, arg, flags)
+ *   arch_kernel_thread(fn, arg, flags)
  */
-_GLOBAL(kernel_thread)
+_GLOBAL(arch_kernel_thread)
        mr      r6,r3           /* function */
        ori     r3,r5,CLONE_VM  /* flags */
        li      r0,__NR_clone
diff -purN linux.orig/arch/s390/kernel/process.c linux/arch/s390/kernel/process.c
--- linux.orig/arch/s390/kernel/process.c       Thu Mar 13 12:01:30 2003
+++ linux/arch/s390/kernel/process.c    Thu Mar 13 13:26:43 2003
@@ -105,7 +105,7 @@ void show_regs(struct pt_regs *regs)
                show_trace((unsigned long *) regs->gprs[15]);
 }

-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
         int clone_arg = flags | CLONE_VM;
         int retval;
diff -purN linux.orig/arch/s390x/kernel/process.c linux/arch/s390x/kernel/process.c
--- linux.orig/arch/s390x/kernel/process.c      Thu Mar 13 12:01:30 2003
+++ linux/arch/s390x/kernel/process.c   Thu Mar 13 13:26:46 2003
@@ -102,7 +102,7 @@ void show_regs(struct pt_regs *regs)
                show_trace((unsigned long *) regs->gprs[15]);
 }

-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
         int clone_arg = flags | CLONE_VM;
         int retval;
diff -purN linux.orig/arch/sh/kernel/process.c linux/arch/sh/kernel/process.c
--- linux.orig/arch/sh/kernel/process.c Mon Oct 15 16:36:48 2001
+++ linux/arch/sh/kernel/process.c      Thu Mar 13 13:26:49 2003
@@ -118,7 +118,7 @@ void free_task_struct(struct task_struct
  * This is the mechanism for creating a new kernel thread.
  *
  */
-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {      /* Don't use this in BL=1(cli).  Or else, CPU resets! */
        register unsigned long __sc0 __asm__ ("r0");
        register unsigned long __sc3 __asm__ ("r3") = __NR_clone;
diff -purN linux.orig/arch/sparc/kernel/process.c linux/arch/sparc/kernel/process.c
--- linux.orig/arch/sparc/kernel/process.c      Thu Mar 13 12:01:30 2003
+++ linux/arch/sparc/kernel/process.c   Thu Mar 13 13:26:58 2003
@@ -676,7 +676,7 @@ out:
  * a system call from a "real" process, but the process memory space will
  * not be free'd until both the parent and the child have exited.
  */
-pid_t kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+pid_t arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
        long retval;

diff -purN linux.orig/arch/sparc64/kernel/process.c linux/arch/sparc64/kernel/process.c
--- linux.orig/arch/sparc64/kernel/process.c    Thu Mar 13 12:01:30 2003
+++ linux/arch/sparc64/kernel/process.c Thu Mar 13 13:26:54 2003
@@ -658,7 +658,7 @@ int copy_thread(int nr, unsigned long cl
  * a system call from a "real" process, but the process memory space will
  * not be free'd until both the parent and the child have exited.
  */
-pid_t kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+pid_t arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
        long retval;

diff -purN linux.orig/arch/um/kernel/process_kern.c linux/arch/um/kernel/process_kern.c
--- linux.orig/arch/um/kernel/process_kern.c    Thu Mar 13 12:01:48 2003
+++ linux/arch/um/kernel/process_kern.c Thu Mar 13 13:27:37 2003
@@ -171,14 +171,14 @@ static int new_thread_proc(void *stack)
        os_usr1_process(os_getpid());
 }

-int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
        int pid;

        current->thread.request.u.thread.proc = fn;
        current->thread.request.u.thread.arg = arg;
        pid = do_fork(CLONE_VM | flags, 0, NULL, 0);
-       if(pid < 0) panic("do_fork failed in kernel_thread");
+       if(pid < 0) panic("do_fork failed in arch_kernel_thread");
        return(pid);
 }

diff -purN linux.orig/fs/exec.c linux/fs/exec.c
--- linux.orig/fs/exec.c        Thu Mar 13 12:01:46 2003
+++ linux/fs/exec.c     Thu Mar 13 14:19:08 2003
@@ -559,8 +559,10 @@ int flush_old_exec(struct linux_binprm *

        current->sas_ss_sp = current->sas_ss_size = 0;

-       if (current->euid == current->uid && current->egid == current->gid)
+       if (current->euid == current->uid && current->egid == current->gid) {
                current->mm->dumpable = 1;
+               current->task_dumpable = 1;
+       }
        name = bprm->filename;
        for (i=0; (ch = *(name++)) != '\0';) {
                if (ch == '/')
@@ -952,7 +954,7 @@ int do_coredump(long signr, struct pt_re
        binfmt = current->binfmt;
        if (!binfmt || !binfmt->core_dump)
                goto fail;
-       if (!current->mm->dumpable)
+       if (!is_dumpable(current))
                goto fail;
        current->mm->dumpable = 0;
        if (current->rlim[RLIMIT_CORE].rlim_cur < binfmt->min_coredump)
diff -purN linux.orig/include/asm-alpha/processor.h linux/include/asm-alpha/processor.h
--- linux.orig/include/asm-alpha/processor.h    Fri Oct  5 15:11:05 2001
+++ linux/include/asm-alpha/processor.h Thu Mar 13 13:35:18 2003
@@ -119,7 +119,7 @@ struct task_struct;
 extern void release_thread(struct task_struct *);

 /* Create a kernel thread without removing it from tasklists.  */
-extern long kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
+extern long arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);

 #define copy_segments(tsk, mm)         do { } while (0)
 #define release_segments(mm)           do { } while (0)
diff -purN linux.orig/include/asm-arm/processor.h linux/include/asm-arm/processor.h
--- linux.orig/include/asm-arm/processor.h      Thu Mar 13 12:01:35 2003
+++ linux/include/asm-arm/processor.h   Thu Mar 13 13:35:18 2003
@@ -117,7 +117,7 @@ extern void __free_task_struct(struct ta
 /*
  * Create a new kernel thread
  */
-extern int kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);

 #endif

diff -purN linux.orig/include/asm-cris/processor.h linux/include/asm-cris/processor.h
--- linux.orig/include/asm-cris/processor.h     Thu Mar 13 12:01:35 2003
+++ linux/include/asm-cris/processor.h  Thu Mar 13 13:35:18 2003
@@ -81,7 +81,7 @@ struct thread_struct {
 #define INIT_THREAD  { \
    0, 0, 0x20 }  /* ccr = int enable, nothing else */

-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);

 /* give the thread a program location
  * set user-mode (The 'U' flag (User mode flag) is CCR/DCCR bit 8)
diff -purN linux.orig/include/asm-i386/processor.h linux/include/asm-i386/processor.h
--- linux.orig/include/asm-i386/processor.h     Thu Mar 13 12:01:57 2003
+++ linux/include/asm-i386/processor.h  Thu Mar 13 13:51:02 2003
@@ -433,7 +433,7 @@ extern void release_thread(struct task_s
 /*
  * create a kernel thread without removing it from tasklists
  */
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);

 /* Copy and release all segment info associated with a VM */
 extern void copy_segments(struct task_struct *p, struct mm_struct * mm);
diff -purN linux.orig/include/asm-ia64/processor.h linux/include/asm-ia64/processor.h
--- linux.orig/include/asm-ia64/processor.h     Thu Mar 13 12:01:35 2003
+++ linux/include/asm-ia64/processor.h  Thu Mar 13 13:35:18 2003
@@ -476,7 +476,7 @@ struct task_struct;
  * do_basic_setup() and the timing is such that free_initmem() has
  * been called already.
  */
-extern int kernel_thread (int (*fn)(void *), void *arg, unsigned long flags);
+extern int arch_kernel_thread (int (*fn)(void *), void *arg, unsigned long flags);

 /* Copy and release all segment info associated with a VM */
 #define copy_segments(tsk, mm)                 do { } while (0)
diff -purN linux.orig/include/asm-m68k/processor.h linux/include/asm-m68k/processor.h
--- linux.orig/include/asm-m68k/processor.h     Fri Oct  5 15:11:05 2001
+++ linux/include/asm-m68k/processor.h  Thu Mar 13 13:35:18 2003
@@ -105,7 +105,7 @@ static inline void release_thread(struct
 {
 }

-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);

 #define copy_segments(tsk, mm)         do { } while (0)
 #define release_segments(mm)           do { } while (0)
diff -purN linux.orig/include/asm-mips/processor.h linux/include/asm-mips/processor.h
--- linux.orig/include/asm-mips/processor.h     Thu Mar 13 12:01:36 2003
+++ linux/include/asm-mips/processor.h  Thu Mar 13 13:35:18 2003
@@ -186,7 +186,7 @@ struct thread_struct {
 /* Free all resources held by a thread. */
 #define release_thread(thread) do { } while(0)

-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);

 /* Copy and release all segment info associated with a VM */
 #define copy_segments(p, mm) do { } while(0)
diff -purN linux.orig/include/asm-mips64/processor.h linux/include/asm-mips64/processor.h
--- linux.orig/include/asm-mips64/processor.h   Thu Mar 13 12:01:36 2003
+++ linux/include/asm-mips64/processor.h        Thu Mar 13 13:35:18 2003
@@ -245,7 +245,7 @@ struct thread_struct {
 /* Free all resources held by a thread. */
 #define release_thread(thread) do { } while(0)

-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);

 /* Copy and release all segment info associated with a VM */
 #define copy_segments(p, mm) do { } while(0)
diff -purN linux.orig/include/asm-parisc/processor.h linux/include/asm-parisc/processor.h
--- linux.orig/include/asm-parisc/processor.h   Fri Oct  5 15:11:05 2001
+++ linux/include/asm-parisc/processor.h        Thu Mar 13 13:35:18 2003
@@ -305,7 +305,7 @@ struct task_struct;

 /* Free all resources held by a thread. */
 extern void release_thread(struct task_struct *);
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);

 #define copy_segments(tsk, mm) do { } while (0)
 #define release_segments(mm)   do { } while (0)
diff -purN linux.orig/include/asm-ppc/processor.h linux/include/asm-ppc/processor.h
--- linux.orig/include/asm-ppc/processor.h      Thu Mar 13 12:01:36 2003
+++ linux/include/asm-ppc/processor.h   Thu Mar 13 13:35:18 2003
@@ -593,7 +593,7 @@ void release_thread(struct task_struct *
 /*
  * Create a new kernel thread.
  */
-extern long kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
+extern long arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);

 /*
  * Bus types
diff -purN linux.orig/include/asm-ppc64/processor.h linux/include/asm-ppc64/processor.h
--- linux.orig/include/asm-ppc64/processor.h    Thu Mar 13 12:01:36 2003
+++ linux/include/asm-ppc64/processor.h Thu Mar 13 13:35:18 2003
@@ -609,7 +609,7 @@ void release_thread(struct task_struct *
 /*
  * Create a new kernel thread.
  */
-extern long kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
+extern long arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);

 /*
  * Bus types
diff -purN linux.orig/include/asm-s390/processor.h linux/include/asm-s390/processor.h
--- linux.orig/include/asm-s390/processor.h     Thu Mar 13 12:01:36 2003
+++ linux/include/asm-s390/processor.h  Thu Mar 13 13:35:18 2003
@@ -113,7 +113,7 @@ struct mm_struct;

 /* Free all resources held by a thread. */
 extern void release_thread(struct task_struct *);
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);

 /* Copy and release all segment info associated with a VM */
 #define copy_segments(nr, mm)           do { } while (0)
diff -purN linux.orig/include/asm-s390x/processor.h linux/include/asm-s390x/processor.h
--- linux.orig/include/asm-s390x/processor.h    Thu Mar 13 12:01:36 2003
+++ linux/include/asm-s390x/processor.h Thu Mar 13 13:35:18 2003
@@ -127,7 +127,7 @@ struct mm_struct;

 /* Free all resources held by a thread. */
 extern void release_thread(struct task_struct *);
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);

 /* Copy and release all segment info associated with a VM */
 #define copy_segments(nr, mm)           do { } while (0)
diff -purN linux.orig/include/asm-sh/processor.h linux/include/asm-sh/processor.h
--- linux.orig/include/asm-sh/processor.h       Fri Oct  5 15:11:05 2001
+++ linux/include/asm-sh/processor.h    Thu Mar 13 13:35:18 2003
@@ -137,7 +137,7 @@ extern void release_thread(struct task_s
 /*
  * create a kernel thread without removing it from tasklists
  */
-extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);

 /*
  * Bus types
diff -purN linux.orig/include/asm-sparc/processor.h linux/include/asm-sparc/processor.h
--- linux.orig/include/asm-sparc/processor.h    Thu Oct 11 02:42:47 2001
+++ linux/include/asm-sparc/processor.h Thu Mar 13 13:35:18 2003
@@ -146,7 +146,7 @@ extern __inline__ void start_thread(stru

 /* Free all resources held by a thread. */
 #define release_thread(tsk)            do { } while(0)
-extern pid_t kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern pid_t arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);


 #define copy_segments(tsk, mm)         do { } while (0)
diff -purN linux.orig/include/asm-sparc64/processor.h linux/include/asm-sparc64/processor.h
--- linux.orig/include/asm-sparc64/processor.h  Thu Mar 13 12:01:36 2003
+++ linux/include/asm-sparc64/processor.h       Thu Mar 13 13:35:18 2003
@@ -270,7 +270,7 @@ do { \
 /* Free all resources held by a thread. */
 #define release_thread(tsk)            do { } while(0)

-extern pid_t kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+extern pid_t arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);

 #define copy_segments(tsk, mm)         do { } while (0)
 #define release_segments(mm)           do { } while (0)
diff -purN linux.orig/include/linux/sched.h linux/include/linux/sched.h
--- linux.orig/include/linux/sched.h    Thu Mar 13 12:01:57 2003
+++ linux/include/linux/sched.h Thu Mar 13 13:54:05 2003
@@ -362,6 +362,7 @@ struct task_struct {
        /* ??? */
        unsigned long personality;
        int did_exec:1;
+       unsigned task_dumpable:1;
        pid_t pid;
        pid_t pgrp;
        pid_t tty_old_pgrp;
@@ -485,6 +486,8 @@ struct task_struct {
 #define PT_TRACESYSGOOD        0x00000008
 #define PT_PTRACE_CAP  0x00000010      /* ptracer can follow suid-exec */

+#define is_dumpable(tsk)       ((tsk)->task_dumpable && (tsk)->mm->dumpable)
+
 /*
  * Limit the stack by to some sane default: root can always
  * increase this limit if needed..  8MB seems reasonable.
@@ -848,6 +851,8 @@ extern void FASTCALL(remove_wait_queue(w

 extern void wait_task_inactive(task_t * p);
 extern void kick_if_running(task_t * p);
+extern long kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
+

 #define __wait_event(wq, condition)                                    \
 do {                                                                   \
diff -purN linux.orig/kernel/fork.c linux/kernel/fork.c
--- linux.orig/kernel/fork.c    Thu Mar 13 12:01:57 2003
+++ linux/kernel/fork.c Thu Mar 13 13:51:24 2003
@@ -28,6 +28,7 @@
 #include <asm/pgalloc.h>
 #include <asm/uaccess.h>
 #include <asm/mmu_context.h>
+#include <asm/processor.h>

 /* The idle threads do not count.. */
 int nr_threads;
@@ -575,6 +576,31 @@ static inline void copy_flags(unsigned l
        p->flags = new_flags;
 }

+long kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
+{
+       struct task_struct *task = current;
+       unsigned old_task_dumpable;
+       long ret;
+
+       /* lock out any potential ptracer */
+       task_lock(task);
+       if (task->ptrace) {
+               task_unlock(task);
+               return -EPERM;
+       }
+
+       old_task_dumpable = task->task_dumpable;
+       task->task_dumpable = 0;
+       task_unlock(task);
+
+       ret = arch_kernel_thread(fn, arg, flags);
+
+       /* never reached in child process, only in parent */
+       current->task_dumpable = old_task_dumpable;
+
+       return ret;
+}
+
 /*
  *  Ok, this is the main fork-routine. It copies the system process
  * information (task[nr]) and sets up the necessary registers. It also
diff -purN linux.orig/kernel/ptrace.c linux/kernel/ptrace.c
--- linux.orig/kernel/ptrace.c  Thu Mar 13 12:01:46 2003
+++ linux/kernel/ptrace.c       Thu Mar 13 13:47:16 2003
@@ -21,6 +21,10 @@
  */
 int ptrace_check_attach(struct task_struct *child, int kill)
 {
+       mb();
+       if (!is_dumpable(child))
+               return -EPERM;
+
        if (!(child->ptrace & PT_PTRACED))
                return -ESRCH;

@@ -57,7 +61,7 @@ int ptrace_attach(struct task_struct *ta
            (current->gid != task->gid)) && !capable(CAP_SYS_PTRACE))
                goto bad;
        rmb();
-       if (!task->mm->dumpable && !capable(CAP_SYS_PTRACE))
+       if (!is_dumpable(task) && !capable(CAP_SYS_PTRACE))
                goto bad;
        /* the same process cannot be attached many times */
        if (task->ptrace & PT_PTRACED)
@@ -123,6 +127,8 @@ int access_process_vm(struct task_struct
        /* Worry about races with exit() */
        task_lock(tsk);
        mm = tsk->mm;
+       if (!is_dumpable(tsk) || (&init_mm == mm))
+               mm = NULL;
        if (mm)
                atomic_inc(&mm->mm_users);
        task_unlock(tsk);
diff -purN linux.orig/kernel/sys.c linux/kernel/sys.c
--- linux.orig/kernel/sys.c     Thu Mar 13 12:01:57 2003
+++ linux/kernel/sys.c  Thu Mar 13 13:41:25 2003
@@ -1286,7 +1286,7 @@ asmlinkage long sys_prctl(int option, un
                        error = put_user(current->pdeath_signal, (int *)arg2);
                        break;
                case PR_GET_DUMPABLE:
-                       if (current->mm->dumpable)
+                       if (is_dumpable(current))
                                error = 1;
                        break;
                case PR_SET_DUMPABLE:
@@ -1294,7 +1294,8 @@ asmlinkage long sys_prctl(int option, un
                                error = -EINVAL;
                                break;
                        }
-                       current->mm->dumpable = arg2;
+                       if (is_dumpable(current))
+                               current->mm->dumpable = arg2;
                        break;
                case PR_SET_UNALIGN:
 #ifdef SET_UNALIGN_CTL
   _________________________________________________________________________________

   No comments have been posted. Log in to post comments.

                                                      Copyright (©) 2003, Eklektix, Inc.
                                            Linux (®) is a registered trademark of Linus Torvalds
                                                    Web hosting provided by Rackspace.com.
-- 
===============================================================================
Matthew Grant	     /\	 ^/\^	grantma@anathoth.gen.nz      /~~~~\
A Linux Network Guy /~~\^/~~\_/~~~~~\_______/~~~~~~~~~~\____/******\
===GPG KeyID: 2EE20270  FingerPrint:
8C2535E1A11DF3EA5EA19125BA4E790E2EE20270==

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

Re: Ptrace hole / Linux 2.2.25

[Matthew Grant]

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

Dear All,

The patch also breaks kill(2) on a process with signal number 0 - This
is used by a lot of monitoring programs running as one user ID to make
sure a process with another user ID is running.

This causes trouble with packages like nagios and netsaint, as well as
other stuff.

Alan, don't want to bash you around, but isn't there another fix
possible that doesn't break this function call and UML skas mode?

Cheers,

Matthew Grantal

On Thu, 2003-03-20 at 08:09, Matthew Grant wrote:
    Mistyped linux-kernel address  %-< 
    
    -----Forwarded Message----- 
    
    From: Matthew Grant <grantma@anathoth.gen.nz>
    To: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Cc: Jeff Dike <jdike@karaya.com>, liinux-kerel@vger.kernel.org
    Subject: Re: Ptrace hole / Linux 2.2.25
    Date: 20 Mar 2003 07:55:45 +1200
    
    Alan,
    
    This patch really breaks UML using the skas mode of thread tracing skas3
    patch on quite a significant amount of machines out there. The skas mode
    is a lot more secure than the traditional UML tt mode. I guess this is
    related to the below...
    
    I am running a UML site that a lot of hospitals ad clinics in Bangldesh
    depend on for there email.  It allows them to work around the corruption
    and agrandidement of the ISPs over there.  The skas3 mode patch is
    needed for the site to run securely.  Tracing thread mode does not cut
    it.
    
    There are also a large number of other telehoused ISP virtual hosting 
    machines that use this stuff, and it is actually proving to be quite
    reliable.
    
    I have attached the skas3 patch that Jeff Dike is currently using, and
    the patch that you have produced.  Could you please look into the clash
    between them, and get it fixed.
    
    Thank you - there are lots out there who will appreciate this.
    
    Cheers,
    
    Matthew Grant
    
    On Mon, 2003-03-17 at 18:39, Ben Pfaff wrote:
    > I am concerned about this change because it will break sandboxing
    > software that I have written, which uses prctl() to turn
    > dumpability back on so that it can open a file, setuid(), and
    > then execve() through the open file via /proc/self/fd/#. Without
    > calling prctl(), the ownership of /proc/self/fd/* becomes root,
    > so the process cannot exec it after it drops privileges. It uses
    > prctl() in other places to get the same effect in /proc, but
    > that's one of the most critical.
    
    The dumpability is per mm, which means that you have to consider
    all the cases of a thread being created in parallel to dumpability
    being enabled.
    
    So consider a three threaded process. Thread one triggers kernel thread
    creation, thread two turns dumpability back on, thread three ptraces
    the new kernel thread.
    
    Proving that is safe is non trivial so the current patch chooses not
    to attempt it. For 2.4.21 proper someone can sit down and do the needed
    verification if they wish 
    
    -- 
    ===============================================================================
    Matthew Grant	     /\	 ^/\^	grantma@anathoth.gen.nz      /~~~~\
    A Linux Network Guy /~~\^/~~\_/~~~~~\_______/~~~~~~~~~~\____/******\
    ===GPG KeyID: 2EE20270  FingerPrint:
    8C2535E1A11DF3EA5EA19125BA4E790E2EE20270==
    
    ________________________________________________________________________
    
    diff -Naur host/arch/i386/config.in host-ptrace/arch/i386/config.in
    --- host/arch/i386/config.in	Fri Aug  9 15:57:14 2002
    +++ host-ptrace/arch/i386/config.in	Sun Nov 10 18:40:09 2002
    @@ -291,6 +291,8 @@
        bool '    Use real mode APM BIOS call to power off' CONFIG_APM_REAL_MODE_POWER_OFF
     fi
     
    +bool '/proc/mm' CONFIG_PROC_MM
    +
     endmenu
     
     source drivers/mtd/Config.in
    diff -Naur host/arch/i386/kernel/ldt.c host-ptrace/arch/i386/kernel/ldt.c
    --- host/arch/i386/kernel/ldt.c	Fri Oct 26 00:01:41 2001
    +++ host-ptrace/arch/i386/kernel/ldt.c	Sun Nov  3 18:37:48 2002
    @@ -24,11 +24,12 @@
      * assured by user-space anyway. Writes are atomic, to protect
      * the security checks done on new descriptors.
      */
    -static int read_ldt(void * ptr, unsigned long bytecount)
    +static int read_ldt(struct task_struct *task, void * ptr, 
    +		    unsigned long bytecount)
     {
     	int err;
     	unsigned long size;
    -	struct mm_struct * mm = current->mm;
    +	struct mm_struct * mm = task->mm;
     
     	err = 0;
     	if (!mm->context.segments)
    @@ -64,9 +65,10 @@
     	return err;
     }
     
    -static int write_ldt(void * ptr, unsigned long bytecount, int oldmode)
    +static int write_ldt(struct task_struct *task, void * ptr, 
    +		     unsigned long bytecount, int oldmode)
     {
    -	struct mm_struct * mm = current->mm;
    +	struct mm_struct * mm = task->mm;
     	__u32 entry_1, entry_2, *lp;
     	int error;
     	struct modify_ldt_ldt_s ldt_info;
    @@ -148,23 +150,29 @@
     	return error;
     }
     
    -asmlinkage int sys_modify_ldt(int func, void *ptr, unsigned long bytecount)
    +int modify_ldt(struct task_struct *task, int func, void *ptr, 
    +	       unsigned long bytecount)
     {
     	int ret = -ENOSYS;
     
     	switch (func) {
     	case 0:
    -		ret = read_ldt(ptr, bytecount);
    +		ret = read_ldt(task, ptr, bytecount);
     		break;
     	case 1:
    -		ret = write_ldt(ptr, bytecount, 1);
    +		ret = write_ldt(task, ptr, bytecount, 1);
     		break;
     	case 2:
     		ret = read_default_ldt(ptr, bytecount);
     		break;
     	case 0x11:
    -		ret = write_ldt(ptr, bytecount, 0);
    +		ret = write_ldt(task, ptr, bytecount, 0);
     		break;
     	}
     	return ret;
    +}
    +
    +asmlinkage int sys_modify_ldt(int func, void *ptr, unsigned long bytecount)
    +{
    +	return(modify_ldt(current, func, ptr, bytecount));
     }
    diff -Naur host/arch/i386/kernel/process.c host-ptrace/arch/i386/kernel/process.c
    --- host/arch/i386/kernel/process.c	Fri Aug  9 15:57:14 2002
    +++ host-ptrace/arch/i386/kernel/process.c	Wed Nov  6 22:12:45 2002
    @@ -551,13 +551,11 @@
      * we do not have to muck with descriptors here, that is
      * done in switch_mm() as needed.
      */
    -void copy_segments(struct task_struct *p, struct mm_struct *new_mm)
    +void mm_copy_segments(struct mm_struct *old_mm, struct mm_struct *new_mm)
     {
    -	struct mm_struct * old_mm;
     	void *old_ldt, *ldt;
     
     	ldt = NULL;
    -	old_mm = current->mm;
     	if (old_mm && (old_ldt = old_mm->context.segments) != NULL) {
     		/*
     		 * Completely new LDT, we initialize it from the parent:
    @@ -570,6 +568,16 @@
     	}
     	new_mm->context.segments = ldt;
     	new_mm->context.cpuvalid = ~0UL;	/* valid on all CPU's - they can't have stale data */
    +}
    +
    +void copy_segments(struct task_struct *p, struct mm_struct *new_mm)
    +{
    +	mm_copy_segments(current->mm, new_mm);
    +}
    +
    +void copy_task_segments(struct task_struct *from, struct mm_struct *new_mm)
    +{
    +	mm_copy_segments(from->mm, new_mm);
     }
     
     /*
    diff -Naur host/arch/i386/kernel/ptrace.c host-ptrace/arch/i386/kernel/ptrace.c
    --- host/arch/i386/kernel/ptrace.c	Fri Aug  9 15:57:14 2002
    +++ host-ptrace/arch/i386/kernel/ptrace.c	Mon Nov 11 19:03:38 2002
    @@ -147,6 +147,11 @@
     	put_stack_long(child, EFL_OFFSET, tmp);
     }
     
    +extern int modify_ldt(struct task_struct *task, int func, void *ptr, 
    +		      unsigned long bytecount);
    +
    +extern struct mm_struct *proc_mm_get_mm(int fd);
    +
     asmlinkage int sys_ptrace(long request, long pid, long addr, long data)
     {
     	struct task_struct *child;
    @@ -415,6 +420,53 @@
     			child->ptrace |= PT_TRACESYSGOOD;
     		else
     			child->ptrace &= ~PT_TRACESYSGOOD;
    +		ret = 0;
    +		break;
    +	}
    +
    +	case PTRACE_FAULTINFO: {
    +		struct ptrace_faultinfo fault;
    +
    +		fault = ((struct ptrace_faultinfo) 
    +			{ .is_write	= child->thread.error_code,
    +			  .addr		= child->thread.cr2 });
    +		ret = copy_to_user((unsigned long *) data, &fault, 
    +				   sizeof(fault));
    +		if(ret)
    +			break;
    +		break;
    +	}
    +	case PTRACE_SIGPENDING:
    +		ret = copy_to_user((unsigned long *) data, 
    +				   &child->pending.signal,
    +				   sizeof(child->pending.signal));
    +		break;
    +
    +	case PTRACE_LDT: {
    +		struct ptrace_ldt ldt;
    +
    +		if(copy_from_user(&ldt, (unsigned long *) data, 
    +				  sizeof(ldt))){
    +			ret = -EIO;
    +			break;
    +		}
    +		ret = modify_ldt(child, ldt.func, ldt.ptr, ldt.bytecount);
    +		break;
    +	}
    +
    +	case PTRACE_SWITCH_MM: {
    +		struct mm_struct *old = child->mm;
    +		struct mm_struct *new = proc_mm_get_mm(data);
    +
    +		if(IS_ERR(new)){
    +			ret = PTR_ERR(new);
    +			break;
    +		}
    +
    +		atomic_inc(&new->mm_users);
    +		child->mm = new;
    +		child->active_mm = new;
    +		mmput(old);
     		ret = 0;
     		break;
     	}
    diff -Naur host/arch/i386/kernel/sys_i386.c host-ptrace/arch/i386/kernel/sys_i386.c
    --- host/arch/i386/kernel/sys_i386.c	Mon Mar 19 15:35:09 2001
    +++ host-ptrace/arch/i386/kernel/sys_i386.c	Mon Nov 11 17:23:25 2002
    @@ -40,7 +40,7 @@
     }
     
     /* common code for old and new mmaps */
    -static inline long do_mmap2(
    +long do_mmap2(struct mm_struct *mm,
     	unsigned long addr, unsigned long len,
     	unsigned long prot, unsigned long flags,
     	unsigned long fd, unsigned long pgoff)
    @@ -55,9 +55,9 @@
     			goto out;
     	}
     
    -	down_write(&current->mm->mmap_sem);
    -	error = do_mmap_pgoff(file, addr, len, prot, flags, pgoff);
    -	up_write(&current->mm->mmap_sem);
    +	down_write(&mm->mmap_sem);
    +	error = do_mmap_pgoff(mm, file, addr, len, prot, flags, pgoff);
    +	up_write(&mm->mmap_sem);
     
     	if (file)
     		fput(file);
    @@ -69,7 +69,7 @@
     	unsigned long prot, unsigned long flags,
     	unsigned long fd, unsigned long pgoff)
     {
    -	return do_mmap2(addr, len, prot, flags, fd, pgoff);
    +	return do_mmap2(current->mm, addr, len, prot, flags, fd, pgoff);
     }
     
     /*
    @@ -100,7 +100,7 @@
     	if (a.offset & ~PAGE_MASK)
     		goto out;
     
    -	err = do_mmap2(a.addr, a.len, a.prot, a.flags, a.fd, a.offset >> PAGE_SHIFT);
    +	err = do_mmap2(current->mm, a.addr, a.len, a.prot, a.flags, a.fd, a.offset >> PAGE_SHIFT);
     out:
     	return err;
     }
    diff -Naur host/include/asm-i386/processor.h host-ptrace/include/asm-i386/processor.h
    --- host/include/asm-i386/processor.h	Sun Nov 10 18:47:37 2002
    +++ host-ptrace/include/asm-i386/processor.h	Mon Nov 11 17:33:30 2002
    @@ -436,6 +436,8 @@
     extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
     
     /* Copy and release all segment info associated with a VM */
    +extern void mm_copy_segments(struct mm_struct *old_mm, 
    +			     struct mm_struct *new_mm);
     extern void copy_segments(struct task_struct *p, struct mm_struct * mm);
     extern void release_segments(struct mm_struct * mm);
     
    diff -Naur host/include/asm-i386/ptrace.h host-ptrace/include/asm-i386/ptrace.h
    --- host/include/asm-i386/ptrace.h	Sun Sep 23 19:20:51 2001
    +++ host-ptrace/include/asm-i386/ptrace.h	Sun Nov 10 18:36:22 2002
    @@ -51,6 +51,22 @@
     
     #define PTRACE_SETOPTIONS         21
     
    +struct ptrace_faultinfo {
    +	int is_write;
    +	unsigned long addr;
    +};
    +
    +struct ptrace_ldt {
    +	int func;
    +  	void *ptr;
    +	unsigned long bytecount;
    +};
    +
    +#define PTRACE_FAULTINFO 52
    +#define PTRACE_SIGPENDING 53
    +#define PTRACE_LDT 54
    +#define PTRACE_SWITCH_MM 55
    +
     /* options set using PTRACE_SETOPTIONS */
     #define PTRACE_O_TRACESYSGOOD     0x00000001
     
    diff -Naur host/include/linux/mm.h host-ptrace/include/linux/mm.h
    --- host/include/linux/mm.h	Fri Aug 30 15:03:44 2002
    +++ host-ptrace/include/linux/mm.h	Mon Nov 11 19:08:53 2002
    @@ -492,6 +492,9 @@
     int get_user_pages(struct task_struct *tsk, struct mm_struct *mm, unsigned long start,
     		int len, int write, int force, struct page **pages, struct vm_area_struct **vmas);
     
    +extern long do_mprotect(struct mm_struct *mm, unsigned long start, 
    +			size_t len, unsigned long prot);
    +
     /*
      * On a two-level page table, this ends up being trivial. Thus the
      * inlining and the symmetry break with pte_alloc() that does all
    @@ -539,9 +542,10 @@
     
     extern unsigned long get_unmapped_area(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
     
    -extern unsigned long do_mmap_pgoff(struct file *file, unsigned long addr,
    -	unsigned long len, unsigned long prot,
    -	unsigned long flag, unsigned long pgoff);
    +extern unsigned long do_mmap_pgoff(struct mm_struct *mm, 
    +				   struct file *file, unsigned long addr,
    +				   unsigned long len, unsigned long prot,
    +				   unsigned long flag, unsigned long pgoff);
     
     static inline unsigned long do_mmap(struct file *file, unsigned long addr,
     	unsigned long len, unsigned long prot,
    @@ -551,7 +555,7 @@
     	if ((offset + PAGE_ALIGN(len)) < offset)
     		goto out;
     	if (!(offset & ~PAGE_MASK))
    -		ret = do_mmap_pgoff(file, addr, len, prot, flag, offset >> PAGE_SHIFT);
    +		ret = do_mmap_pgoff(current->mm, file, addr, len, prot, flag, offset >> PAGE_SHIFT);
     out:
     	return ret;
     }
    diff -Naur host/include/linux/proc_mm.h host-ptrace/include/linux/proc_mm.h
    --- host/include/linux/proc_mm.h	Wed Dec 31 19:00:00 1969
    +++ host-ptrace/include/linux/proc_mm.h	Mon Nov 11 17:41:09 2002
    @@ -0,0 +1,44 @@
    +/* 
    + * Copyright (C) 2002 Jeff Dike (jdike@karaya.com)
    + * Licensed under the GPL
    + */
    +
    +#ifndef __PROC_MM_H
    +#define __PROC_MM_H
    +
    +#define MM_MMAP 54
    +#define MM_MUNMAP 55
    +#define MM_MPROTECT 56
    +#define MM_COPY_SEGMENTS 57
    +
    +struct mm_mmap {
    +	unsigned long addr;
    +	unsigned long len;
    +	unsigned long prot;
    +	unsigned long flags;
    +	unsigned long fd;
    +	unsigned long offset;
    +};
    +
    +struct mm_munmap {
    +	unsigned long addr;
    +	unsigned long len;	
    +};
    +
    +struct mm_mprotect {
    +	unsigned long addr;
    +	unsigned long len;
    +        unsigned int prot;
    +};
    +
    +struct proc_mm_op {
    +	int op;
    +	union {
    +		struct mm_mmap mmap;
    +		struct mm_munmap munmap;
    +	        struct mm_mprotect mprotect;
    +		int copy_segments;
    +	} u;
    +};
    +
    +#endif
    diff -Naur host/mm/Makefile host-ptrace/mm/Makefile
    --- host/mm/Makefile	Fri Aug  9 15:57:31 2002
    +++ host-ptrace/mm/Makefile	Sun Nov 10 18:37:33 2002
    @@ -17,5 +17,6 @@
     	    shmem.o
     
     obj-$(CONFIG_HIGHMEM) += highmem.o
    +obj-$(CONFIG_PROC_MM) += proc_mm.o
     
     include $(TOPDIR)/Rules.make
    diff -Naur host/mm/mmap.c host-ptrace/mm/mmap.c
    --- host/mm/mmap.c	Fri Aug  9 15:57:31 2002
    +++ host-ptrace/mm/mmap.c	Mon Nov 11 17:24:18 2002
    @@ -390,10 +390,11 @@
     	return 0;
     }
     
    -unsigned long do_mmap_pgoff(struct file * file, unsigned long addr, unsigned long len,
    -	unsigned long prot, unsigned long flags, unsigned long pgoff)
    +unsigned long do_mmap_pgoff(struct mm_struct *mm, struct file * file, 
    +			    unsigned long addr, unsigned long len,
    +			    unsigned long prot, unsigned long flags, 
    +			    unsigned long pgoff)
     {
    -	struct mm_struct * mm = current->mm;
     	struct vm_area_struct * vma, * prev;
     	unsigned int vm_flags;
     	int correct_wcount = 0;
    diff -Naur host/mm/mprotect.c host-ptrace/mm/mprotect.c
    --- host/mm/mprotect.c	Fri Aug  9 15:57:31 2002
    +++ host-ptrace/mm/mprotect.c	Mon Nov 11 17:47:58 2002
    @@ -264,7 +264,8 @@
     	return 0;
     }
     
    -asmlinkage long sys_mprotect(unsigned long start, size_t len, unsigned long prot)
    +long do_mprotect(struct mm_struct *mm, unsigned long start, size_t len, 
    +		 unsigned long prot)
     {
     	unsigned long nstart, end, tmp;
     	struct vm_area_struct * vma, * next, * prev;
    @@ -281,9 +282,9 @@
     	if (end == start)
     		return 0;
     
    -	down_write(&current->mm->mmap_sem);
    +	down_write(&mm->mmap_sem);
     
    -	vma = find_vma_prev(current->mm, start, &prev);
    +	vma = find_vma_prev(mm, start, &prev);
     	error = -ENOMEM;
     	if (!vma || vma->vm_start > start)
     		goto out;
    @@ -332,6 +333,11 @@
     		prev->vm_mm->map_count--;
     	}
     out:
    -	up_write(&current->mm->mmap_sem);
    +	up_write(&mm->mmap_sem);
     	return error;
    +}
    +
    +asmlinkage long sys_mprotect(unsigned long start, size_t len, unsigned long prot)
    +{
    +	return(do_mprotect(current->mm, start, len, prot));
     }
    diff -Naur host/mm/proc_mm.c host-ptrace/mm/proc_mm.c
    --- host/mm/proc_mm.c	Wed Dec 31 19:00:00 1969
    +++ host-ptrace/mm/proc_mm.c	Mon Nov 11 19:07:52 2002
    @@ -0,0 +1,173 @@
    +/* 
    + * Copyright (C) 2002 Jeff Dike (jdike@karaya.com)
    + * Licensed under the GPL
    + */
    +
    +#include "linux/proc_fs.h"
    +#include "linux/proc_mm.h"
    +#include "linux/file.h"
    +#include "asm/uaccess.h"
    +#include "asm/mmu_context.h"
    +
    +static struct file_operations proc_mm_fops;
    +
    +struct mm_struct *proc_mm_get_mm(int fd)
    +{
    +	struct mm_struct *ret = ERR_PTR(-EBADF);
    +	struct file *file;
    +
    +	file = fget(fd);
    +	if (!file)
    +		goto out;
    +
    +	ret = ERR_PTR(-EINVAL);
    +	if(file->f_op != &proc_mm_fops)
    +		goto out_fput;
    +
    +	ret = file->private_data;
    +
    + out_fput:
    +	fput(file);
    + out:
    +	return(ret);
    +}
    +
    +extern long do_mmap2(struct mm_struct *mm, unsigned long addr, 
    +		     unsigned long len, unsigned long prot, 
    +		     unsigned long flags, unsigned long fd,
    +		     unsigned long pgoff);
    +
    +static ssize_t write_proc_mm(struct file *file, const char *buffer,
    +			     size_t count, loff_t *ppos)
    +{
    +	struct mm_struct *mm = file->private_data;
    +	struct proc_mm_op req;
    +	int n, ret;
    +
    +	if(count > sizeof(req))
    +		return(-EINVAL);
    +
    +	n = copy_from_user(&req, buffer, count);
    +	if(n != 0)
    +		return(-EFAULT);
    +
    +	ret = count;
    +	switch(req.op){
    +	case MM_MMAP: {
    +		struct mm_mmap *map = &req.u.mmap;
    +
    +		ret = do_mmap2(mm, map->addr, map->len, map->prot, 
    +			       map->flags, map->fd, map->offset >> PAGE_SHIFT);
    +		if((ret & ~PAGE_MASK) == 0)
    +			ret = count;
    +	
    +		break;
    +	}
    +	case MM_MUNMAP: {
    +		struct mm_munmap *unmap = &req.u.munmap;
    +
    +		down_write(&mm->mmap_sem);
    +		ret = do_munmap(mm, unmap->addr, unmap->len);
    +		up_write(&mm->mmap_sem);
    +
    +		if(ret == 0)
    +			ret = count;
    +		break;
    +	}
    +	case MM_MPROTECT: {
    +		struct mm_mprotect *protect = &req.u.mprotect;
    +
    +		ret = do_mprotect(mm, protect->addr, protect->len, 
    +				  protect->prot);
    +		if(ret == 0)
    +			ret = count;
    +		break;
    +	}
    +
    +	case MM_COPY_SEGMENTS: {
    +		struct mm_struct *from = proc_mm_get_mm(req.u.copy_segments);
    +
    +		if(IS_ERR(from)){
    +			ret = PTR_ERR(from);
    +			break;
    +		}
    +
    +		mm_copy_segments(from, mm);
    +		break;
    +	}
    +	default:
    +		ret = -EINVAL;
    +		break;
    +	}
    +
    +	return(ret);
    +}
    +
    +static int open_proc_mm(struct inode *inode, struct file *file)
    +{
    +	struct mm_struct *mm = mm_alloc();
    +	int ret;
    +
    +	ret = -ENOMEM;
    +	if(mm == NULL)
    +		goto out_mem;
    +
    +	ret = init_new_context(current, mm);
    +	if(ret)
    +		goto out_free;
    +
    +	spin_lock(&mmlist_lock);
    +	list_add(&mm->mmlist, &current->mm->mmlist);
    +	mmlist_nr++;
    +	spin_unlock(&mmlist_lock);
    +
    +	file->private_data = mm;
    +
    +	return(0);
    +
    + out_free:
    +	mmput(mm);
    + out_mem:
    +	return(ret);
    +}
    +
    +static int release_proc_mm(struct inode *inode, struct file *file)
    +{
    +	struct mm_struct *mm = file->private_data;
    +
    +	mmput(mm);
    +	return(0);
    +}
    +
    +static struct file_operations proc_mm_fops = {
    +	.open		= open_proc_mm,
    +	.release	= release_proc_mm,
    +	.write		= write_proc_mm,
    +};
    +
    +static int make_proc_mm(void)
    +{
    +	struct proc_dir_entry *ent;
    +
    +	ent = create_proc_entry("mm", 0222, &proc_root);
    +	if(ent == NULL){
    +		printk("make_proc_mm : Failed to register /proc/mm\n");
    +		return(0);
    +	}
    +	ent->proc_fops = &proc_mm_fops;
    +
    +	return(0);
    +}
    +
    +__initcall(make_proc_mm);
    +
    +/*
    + * Overrides for Emacs so that we follow Linus's tabbing style.
    + * Emacs will notice this stuff at the end of the file and automatically
    + * adjust the settings for this buffer only.  This must remain at the end
    + * of the file.
    + * ---------------------------------------------------------------------------
    + * Local variables:
    + * c-file-style: "linux"
    + * End:
    + */
    
    ________________________________________________________________________
    
                                                                    LWN.net Logo 
    
    
                                                                    Sponsored Link
    
       TrustCommerce
    
       E-Commerce & credit card processing - the Open Source way!
         ___________________________________________________________________________________________________________________________________
    
       You are not logged in
       Log in now
       Create an account
       Subscribe to LWN
    
       Recent Features
    
       LWN.net Weekly Edition for March 13, 2003
    
       A look at the SCO complaint
    
       LWN.net Weekly Edition for March 6, 2003
    
       LWN.net Weekly Edition for February 27, 2003
    
       LWN.net Weekly Edition for February 20, 2003
    
       Printable page
    
    
           Home      Weekly edition     Archives    Security  Calendar
       Distributions Penguin Gallery Kernel patches  Search   Old site
        LWN.net FAQ   Subscriptions    Advertise    Headlines Privacy
    
    Ptrace vulnerability in 2.2 and 2.4 kernels
    
       From:   Alan Cox <alan@redhat.com>
       To:   editor@lwn.net, scoop@freshmeat.net, kernel@linuxtoday.com, kernel@linuxfr.org, rob@linuxberg.com, chris@linuxdev.net,
       kernel@linuxhq.com, kernel@linuxcare.com, marcelo@conectiva.com.br, ac-kernels@tonnikala.net
       Subject:   Ptrace vulnerability in Linux 2.2/2.4
       Date:   Mon, 17 Mar 2003 11:00:16 -0500 (EST)
    
    Vulnerability: CAN-2003-0127
    
    The Linux 2.2 and Linux 2.4 kernels have a flaw in ptrace. This hole allows
    local users to obtain full privileges. Remote exploitation of this hole is
    not possible. Linux 2.5 is not believed to be vulnerable.
    
    Linux 2.2.25 has been released to correct Linux 2.2. It contains no other
    changes. The bug fixes that would have been in 2.2.5pre1 will now appear in
    2.2.26pre1. The patch will apply directly to most older 2.2 releases.
    
    A patch for Linux 2.4.20/Linux 2.4.21pre is attached. The patch also
    subtly changes the PR_SET_DUMPABLE prctl. We believe this is neccessary and
    that it will not affect any software. The functionality change is specific
    to unusual debugging situations.
    
    We would like to thank Andrzej Szombierski who found the problem, and
    wrote an initial patch. Seth Arnold cleaned up the 2.2 change. Arjan van
    de Ven and Ben LaHaise identified additional problems with the original
    fix.
    
    Alan
    
    diff -purN linux.orig/arch/alpha/kernel/entry.S linux/arch/alpha/kernel/entry.S
    --- linux.orig/arch/alpha/kernel/entry.S        Thu Mar 13 12:01:46 2003
    +++ linux/arch/alpha/kernel/entry.S     Thu Mar 13 13:28:49 2003
    @@ -231,12 +231,12 @@ kernel_clone:
     .end   kernel_clone
    
     /*
    - * kernel_thread(fn, arg, clone_flags)
    + * arch_kernel_thread(fn, arg, clone_flags)
      */
     .align 3
     .globl kernel_thread
     .ent   kernel_thread
    -kernel_thread:
    +arch_kernel_thread:
            ldgp    $29,0($27)      /* we can be called from a module */
            .frame $30, 4*8, $26
            subq    $30,4*8,$30
    diff -purN linux.orig/arch/arm/kernel/process.c linux/arch/arm/kernel/process.c
    --- linux.orig/arch/arm/kernel/process.c        Thu Mar 13 12:01:29 2003
    +++ linux/arch/arm/kernel/process.c     Thu Mar 13 13:25:56 2003
    @@ -366,7 +366,7 @@ void dump_thread(struct pt_regs * regs,
      * a system call from a "real" process, but the process memory space will
      * not be free'd until both the parent and the child have exited.
      */
    -pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
    +pid_t arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
     {
            pid_t __ret;
    
    diff -purN linux.orig/arch/cris/kernel/entry.S linux/arch/cris/kernel/entry.S
    --- linux.orig/arch/cris/kernel/entry.S Thu Mar 13 12:01:29 2003
    +++ linux/arch/cris/kernel/entry.S      Thu Mar 13 13:30:30 2003
    @@ -736,12 +736,12 @@ hw_bp_trig_ptr:
      * the grosser the code, at least with the gcc version in cris-dist-1.13.
      */
    
    -/* int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags) */
    +/* int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags) */
     /*                   r10                r11         r12  */
    
            .text
    -       .global kernel_thread
    -kernel_thread:
    +       .global arch_kernel_thread
    +arch_kernel_thread:
    
            /* Save ARG for later.  */
            move.d $r11, $r13
    diff -purN linux.orig/arch/i386/kernel/process.c linux/arch/i386/kernel/process.c
    --- linux.orig/arch/i386/kernel/process.c       Thu Mar 13 12:01:57 2003
    +++ linux/arch/i386/kernel/process.c    Thu Mar 13 13:26:08 2003
    @@ -495,7 +495,7 @@ void release_segments(struct mm_struct *
     /*
      * Create a kernel thread
      */
    -int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
    +int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
     {
            long retval, d0;
    
    @@ -518,6 +518,7 @@ int kernel_thread(int (*fn)(void *), voi
                     "r" (arg), "r" (fn),
                     "b" (flags | CLONE_VM)
                    : "memory");
    +
            return retval;
     }
    
    diff -purN linux.orig/arch/ia64/kernel/process.c linux/arch/ia64/kernel/process.c
    --- linux.orig/arch/ia64/kernel/process.c       Thu Mar 13 12:01:29 2003
    +++ linux/arch/ia64/kernel/process.c    Thu Mar 13 13:26:15 2003
    @@ -220,7 +220,7 @@ ia64_load_extra (struct task_struct *tas
      *     |                     | <-- sp (lowest addr)
      *     +---------------------+
      *
    - * Note: if we get called through kernel_thread() then the memory
    + * Note: if we get called through arch_kernel_thread() then the memory
      * above "(highest addr)" is valid kernel stack memory that needs to
      * be copied as well.
      *
    @@ -469,7 +469,7 @@ ia64_set_personality (struct elf64_hdr *
     }
    
     pid_t
    -kernel_thread (int (*fn)(void *), void *arg, unsigned long flags)
    +arch_kernel_thread (int (*fn)(void *), void *arg, unsigned long flags)
     {
            struct task_struct *parent = current;
            int result, tid;
    diff -purN linux.orig/arch/m68k/kernel/process.c linux/arch/m68k/kernel/process.c
    --- linux.orig/arch/m68k/kernel/process.c       Thu Mar 13 12:01:29 2003
    +++ linux/arch/m68k/kernel/process.c    Thu Mar 13 13:26:18 2003
    @@ -124,7 +124,7 @@ void show_regs(struct pt_regs * regs)
     /*
      * Create a kernel thread
      */
    -int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
    +int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
     {
            int pid;
            mm_segment_t fs;
    diff -purN linux.orig/arch/mips/kernel/process.c linux/arch/mips/kernel/process.c
    --- linux.orig/arch/mips/kernel/process.c       Thu Mar 13 12:01:29 2003
    +++ linux/arch/mips/kernel/process.c    Thu Mar 13 13:26:28 2003
    @@ -155,7 +155,7 @@ void dump_thread(struct pt_regs *regs, s
     /*
      * Create a kernel thread
      */
    -int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
    +int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
     {
            long retval;
    
    diff -purN linux.orig/arch/mips64/kernel/process.c linux/arch/mips64/kernel/process.c
    --- linux.orig/arch/mips64/kernel/process.c     Thu Mar 13 12:01:29 2003
    +++ linux/arch/mips64/kernel/process.c  Thu Mar 13 13:26:23 2003
    @@ -152,7 +152,7 @@ void dump_thread(struct pt_regs *regs, s
     /*
      * Create a kernel thread
      */
    -int kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
    +int arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
     {
            int retval;
    
    diff -purN linux.orig/arch/parisc/kernel/process.c linux/arch/parisc/kernel/process.c
    --- linux.orig/arch/parisc/kernel/process.c     Fri Feb  9 14:29:44 2001
    +++ linux/arch/parisc/kernel/process.c  Thu Mar 13 13:26:36 2003
    @@ -118,7 +118,7 @@ void machine_heartbeat(void)
      */
    
     extern pid_t __kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
    -pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
    +pid_t arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
     {
    
            /*
    diff -purN linux.orig/arch/ppc/kernel/misc.S linux/arch/ppc/kernel/misc.S
    --- linux.orig/arch/ppc/kernel/misc.S   Thu Mar 13 12:01:29 2003
    +++ linux/arch/ppc/kernel/misc.S        Thu Mar 13 13:32:21 2003
    @@ -899,9 +899,9 @@ _GLOBAL(cvt_df)
    
     /*
      * Create a kernel thread
    - *   kernel_thread(fn, arg, flags)
    + *   arch_kernel_thread(fn, arg, flags)
      */
    -_GLOBAL(kernel_thread)
    +_GLOBAL(arch_kernel_thread)
            mr      r6,r3           /* function */
            ori     r3,r5,CLONE_VM  /* flags */
            li      r0,__NR_clone
    diff -purN linux.orig/arch/ppc64/kernel/misc.S linux/arch/ppc64/kernel/misc.S
    --- linux.orig/arch/ppc64/kernel/misc.S Thu Mar 13 12:01:30 2003
    +++ linux/arch/ppc64/kernel/misc.S      Thu Mar 13 13:29:42 2003
    @@ -493,9 +493,9 @@ _GLOBAL(cvt_df)
    
     /*
      * Create a kernel thread
    - *   kernel_thread(fn, arg, flags)
    + *   arch_kernel_thread(fn, arg, flags)
      */
    -_GLOBAL(kernel_thread)
    +_GLOBAL(arch_kernel_thread)
            mr      r6,r3           /* function */
            ori     r3,r5,CLONE_VM  /* flags */
            li      r0,__NR_clone
    diff -purN linux.orig/arch/s390/kernel/process.c linux/arch/s390/kernel/process.c
    --- linux.orig/arch/s390/kernel/process.c       Thu Mar 13 12:01:30 2003
    +++ linux/arch/s390/kernel/process.c    Thu Mar 13 13:26:43 2003
    @@ -105,7 +105,7 @@ void show_regs(struct pt_regs *regs)
                    show_trace((unsigned long *) regs->gprs[15]);
     }
    
    -int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
    +int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
     {
             int clone_arg = flags | CLONE_VM;
             int retval;
    diff -purN linux.orig/arch/s390x/kernel/process.c linux/arch/s390x/kernel/process.c
    --- linux.orig/arch/s390x/kernel/process.c      Thu Mar 13 12:01:30 2003
    +++ linux/arch/s390x/kernel/process.c   Thu Mar 13 13:26:46 2003
    @@ -102,7 +102,7 @@ void show_regs(struct pt_regs *regs)
                    show_trace((unsigned long *) regs->gprs[15]);
     }
    
    -int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
    +int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
     {
             int clone_arg = flags | CLONE_VM;
             int retval;
    diff -purN linux.orig/arch/sh/kernel/process.c linux/arch/sh/kernel/process.c
    --- linux.orig/arch/sh/kernel/process.c Mon Oct 15 16:36:48 2001
    +++ linux/arch/sh/kernel/process.c      Thu Mar 13 13:26:49 2003
    @@ -118,7 +118,7 @@ void free_task_struct(struct task_struct
      * This is the mechanism for creating a new kernel thread.
      *
      */
    -int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
    +int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
     {      /* Don't use this in BL=1(cli).  Or else, CPU resets! */
            register unsigned long __sc0 __asm__ ("r0");
            register unsigned long __sc3 __asm__ ("r3") = __NR_clone;
    diff -purN linux.orig/arch/sparc/kernel/process.c linux/arch/sparc/kernel/process.c
    --- linux.orig/arch/sparc/kernel/process.c      Thu Mar 13 12:01:30 2003
    +++ linux/arch/sparc/kernel/process.c   Thu Mar 13 13:26:58 2003
    @@ -676,7 +676,7 @@ out:
      * a system call from a "real" process, but the process memory space will
      * not be free'd until both the parent and the child have exited.
      */
    -pid_t kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
    +pid_t arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
     {
            long retval;
    
    diff -purN linux.orig/arch/sparc64/kernel/process.c linux/arch/sparc64/kernel/process.c
    --- linux.orig/arch/sparc64/kernel/process.c    Thu Mar 13 12:01:30 2003
    +++ linux/arch/sparc64/kernel/process.c Thu Mar 13 13:26:54 2003
    @@ -658,7 +658,7 @@ int copy_thread(int nr, unsigned long cl
      * a system call from a "real" process, but the process memory space will
      * not be free'd until both the parent and the child have exited.
      */
    -pid_t kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
    +pid_t arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
     {
            long retval;
    
    diff -purN linux.orig/arch/um/kernel/process_kern.c linux/arch/um/kernel/process_kern.c
    --- linux.orig/arch/um/kernel/process_kern.c    Thu Mar 13 12:01:48 2003
    +++ linux/arch/um/kernel/process_kern.c Thu Mar 13 13:27:37 2003
    @@ -171,14 +171,14 @@ static int new_thread_proc(void *stack)
            os_usr1_process(os_getpid());
     }
    
    -int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
    +int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
     {
            int pid;
    
            current->thread.request.u.thread.proc = fn;
            current->thread.request.u.thread.arg = arg;
            pid = do_fork(CLONE_VM | flags, 0, NULL, 0);
    -       if(pid < 0) panic("do_fork failed in kernel_thread");
    +       if(pid < 0) panic("do_fork failed in arch_kernel_thread");
            return(pid);
     }
    
    diff -purN linux.orig/fs/exec.c linux/fs/exec.c
    --- linux.orig/fs/exec.c        Thu Mar 13 12:01:46 2003
    +++ linux/fs/exec.c     Thu Mar 13 14:19:08 2003
    @@ -559,8 +559,10 @@ int flush_old_exec(struct linux_binprm *
    
            current->sas_ss_sp = current->sas_ss_size = 0;
    
    -       if (current->euid == current->uid && current->egid == current->gid)
    +       if (current->euid == current->uid && current->egid == current->gid) {
                    current->mm->dumpable = 1;
    +               current->task_dumpable = 1;
    +       }
            name = bprm->filename;
            for (i=0; (ch = *(name++)) != '\0';) {
                    if (ch == '/')
    @@ -952,7 +954,7 @@ int do_coredump(long signr, struct pt_re
            binfmt = current->binfmt;
            if (!binfmt || !binfmt->core_dump)
                    goto fail;
    -       if (!current->mm->dumpable)
    +       if (!is_dumpable(current))
                    goto fail;
            current->mm->dumpable = 0;
            if (current->rlim[RLIMIT_CORE].rlim_cur < binfmt->min_coredump)
    diff -purN linux.orig/include/asm-alpha/processor.h linux/include/asm-alpha/processor.h
    --- linux.orig/include/asm-alpha/processor.h    Fri Oct  5 15:11:05 2001
    +++ linux/include/asm-alpha/processor.h Thu Mar 13 13:35:18 2003
    @@ -119,7 +119,7 @@ struct task_struct;
     extern void release_thread(struct task_struct *);
    
     /* Create a kernel thread without removing it from tasklists.  */
    -extern long kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
    +extern long arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
    
     #define copy_segments(tsk, mm)         do { } while (0)
     #define release_segments(mm)           do { } while (0)
    diff -purN linux.orig/include/asm-arm/processor.h linux/include/asm-arm/processor.h
    --- linux.orig/include/asm-arm/processor.h      Thu Mar 13 12:01:35 2003
    +++ linux/include/asm-arm/processor.h   Thu Mar 13 13:35:18 2003
    @@ -117,7 +117,7 @@ extern void __free_task_struct(struct ta
     /*
      * Create a new kernel thread
      */
    -extern int kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
    +extern int arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
    
     #endif
    
    diff -purN linux.orig/include/asm-cris/processor.h linux/include/asm-cris/processor.h
    --- linux.orig/include/asm-cris/processor.h     Thu Mar 13 12:01:35 2003
    +++ linux/include/asm-cris/processor.h  Thu Mar 13 13:35:18 2003
    @@ -81,7 +81,7 @@ struct thread_struct {
     #define INIT_THREAD  { \
        0, 0, 0x20 }  /* ccr = int enable, nothing else */
    
    -extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    +extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    
     /* give the thread a program location
      * set user-mode (The 'U' flag (User mode flag) is CCR/DCCR bit 8)
    diff -purN linux.orig/include/asm-i386/processor.h linux/include/asm-i386/processor.h
    --- linux.orig/include/asm-i386/processor.h     Thu Mar 13 12:01:57 2003
    +++ linux/include/asm-i386/processor.h  Thu Mar 13 13:51:02 2003
    @@ -433,7 +433,7 @@ extern void release_thread(struct task_s
     /*
      * create a kernel thread without removing it from tasklists
      */
    -extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    +extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    
     /* Copy and release all segment info associated with a VM */
     extern void copy_segments(struct task_struct *p, struct mm_struct * mm);
    diff -purN linux.orig/include/asm-ia64/processor.h linux/include/asm-ia64/processor.h
    --- linux.orig/include/asm-ia64/processor.h     Thu Mar 13 12:01:35 2003
    +++ linux/include/asm-ia64/processor.h  Thu Mar 13 13:35:18 2003
    @@ -476,7 +476,7 @@ struct task_struct;
      * do_basic_setup() and the timing is such that free_initmem() has
      * been called already.
      */
    -extern int kernel_thread (int (*fn)(void *), void *arg, unsigned long flags);
    +extern int arch_kernel_thread (int (*fn)(void *), void *arg, unsigned long flags);
    
     /* Copy and release all segment info associated with a VM */
     #define copy_segments(tsk, mm)                 do { } while (0)
    diff -purN linux.orig/include/asm-m68k/processor.h linux/include/asm-m68k/processor.h
    --- linux.orig/include/asm-m68k/processor.h     Fri Oct  5 15:11:05 2001
    +++ linux/include/asm-m68k/processor.h  Thu Mar 13 13:35:18 2003
    @@ -105,7 +105,7 @@ static inline void release_thread(struct
     {
     }
    
    -extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    +extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    
     #define copy_segments(tsk, mm)         do { } while (0)
     #define release_segments(mm)           do { } while (0)
    diff -purN linux.orig/include/asm-mips/processor.h linux/include/asm-mips/processor.h
    --- linux.orig/include/asm-mips/processor.h     Thu Mar 13 12:01:36 2003
    +++ linux/include/asm-mips/processor.h  Thu Mar 13 13:35:18 2003
    @@ -186,7 +186,7 @@ struct thread_struct {
     /* Free all resources held by a thread. */
     #define release_thread(thread) do { } while(0)
    
    -extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    +extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    
     /* Copy and release all segment info associated with a VM */
     #define copy_segments(p, mm) do { } while(0)
    diff -purN linux.orig/include/asm-mips64/processor.h linux/include/asm-mips64/processor.h
    --- linux.orig/include/asm-mips64/processor.h   Thu Mar 13 12:01:36 2003
    +++ linux/include/asm-mips64/processor.h        Thu Mar 13 13:35:18 2003
    @@ -245,7 +245,7 @@ struct thread_struct {
     /* Free all resources held by a thread. */
     #define release_thread(thread) do { } while(0)
    
    -extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    +extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    
     /* Copy and release all segment info associated with a VM */
     #define copy_segments(p, mm) do { } while(0)
    diff -purN linux.orig/include/asm-parisc/processor.h linux/include/asm-parisc/processor.h
    --- linux.orig/include/asm-parisc/processor.h   Fri Oct  5 15:11:05 2001
    +++ linux/include/asm-parisc/processor.h        Thu Mar 13 13:35:18 2003
    @@ -305,7 +305,7 @@ struct task_struct;
    
     /* Free all resources held by a thread. */
     extern void release_thread(struct task_struct *);
    -extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    +extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    
     #define copy_segments(tsk, mm) do { } while (0)
     #define release_segments(mm)   do { } while (0)
    diff -purN linux.orig/include/asm-ppc/processor.h linux/include/asm-ppc/processor.h
    --- linux.orig/include/asm-ppc/processor.h      Thu Mar 13 12:01:36 2003
    +++ linux/include/asm-ppc/processor.h   Thu Mar 13 13:35:18 2003
    @@ -593,7 +593,7 @@ void release_thread(struct task_struct *
     /*
      * Create a new kernel thread.
      */
    -extern long kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
    +extern long arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
    
     /*
      * Bus types
    diff -purN linux.orig/include/asm-ppc64/processor.h linux/include/asm-ppc64/processor.h
    --- linux.orig/include/asm-ppc64/processor.h    Thu Mar 13 12:01:36 2003
    +++ linux/include/asm-ppc64/processor.h Thu Mar 13 13:35:18 2003
    @@ -609,7 +609,7 @@ void release_thread(struct task_struct *
     /*
      * Create a new kernel thread.
      */
    -extern long kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
    +extern long arch_kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
    
     /*
      * Bus types
    diff -purN linux.orig/include/asm-s390/processor.h linux/include/asm-s390/processor.h
    --- linux.orig/include/asm-s390/processor.h     Thu Mar 13 12:01:36 2003
    +++ linux/include/asm-s390/processor.h  Thu Mar 13 13:35:18 2003
    @@ -113,7 +113,7 @@ struct mm_struct;
    
     /* Free all resources held by a thread. */
     extern void release_thread(struct task_struct *);
    -extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    +extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    
     /* Copy and release all segment info associated with a VM */
     #define copy_segments(nr, mm)           do { } while (0)
    diff -purN linux.orig/include/asm-s390x/processor.h linux/include/asm-s390x/processor.h
    --- linux.orig/include/asm-s390x/processor.h    Thu Mar 13 12:01:36 2003
    +++ linux/include/asm-s390x/processor.h Thu Mar 13 13:35:18 2003
    @@ -127,7 +127,7 @@ struct mm_struct;
    
     /* Free all resources held by a thread. */
     extern void release_thread(struct task_struct *);
    -extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    +extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    
     /* Copy and release all segment info associated with a VM */
     #define copy_segments(nr, mm)           do { } while (0)
    diff -purN linux.orig/include/asm-sh/processor.h linux/include/asm-sh/processor.h
    --- linux.orig/include/asm-sh/processor.h       Fri Oct  5 15:11:05 2001
    +++ linux/include/asm-sh/processor.h    Thu Mar 13 13:35:18 2003
    @@ -137,7 +137,7 @@ extern void release_thread(struct task_s
     /*
      * create a kernel thread without removing it from tasklists
      */
    -extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    +extern int arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    
     /*
      * Bus types
    diff -purN linux.orig/include/asm-sparc/processor.h linux/include/asm-sparc/processor.h
    --- linux.orig/include/asm-sparc/processor.h    Thu Oct 11 02:42:47 2001
    +++ linux/include/asm-sparc/processor.h Thu Mar 13 13:35:18 2003
    @@ -146,7 +146,7 @@ extern __inline__ void start_thread(stru
    
     /* Free all resources held by a thread. */
     #define release_thread(tsk)            do { } while(0)
    -extern pid_t kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    +extern pid_t arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    
    
     #define copy_segments(tsk, mm)         do { } while (0)
    diff -purN linux.orig/include/asm-sparc64/processor.h linux/include/asm-sparc64/processor.h
    --- linux.orig/include/asm-sparc64/processor.h  Thu Mar 13 12:01:36 2003
    +++ linux/include/asm-sparc64/processor.h       Thu Mar 13 13:35:18 2003
    @@ -270,7 +270,7 @@ do { \
     /* Free all resources held by a thread. */
     #define release_thread(tsk)            do { } while(0)
    
    -extern pid_t kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    +extern pid_t arch_kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    
     #define copy_segments(tsk, mm)         do { } while (0)
     #define release_segments(mm)           do { } while (0)
    diff -purN linux.orig/include/linux/sched.h linux/include/linux/sched.h
    --- linux.orig/include/linux/sched.h    Thu Mar 13 12:01:57 2003
    +++ linux/include/linux/sched.h Thu Mar 13 13:54:05 2003
    @@ -362,6 +362,7 @@ struct task_struct {
            /* ??? */
            unsigned long personality;
            int did_exec:1;
    +       unsigned task_dumpable:1;
            pid_t pid;
            pid_t pgrp;
            pid_t tty_old_pgrp;
    @@ -485,6 +486,8 @@ struct task_struct {
     #define PT_TRACESYSGOOD        0x00000008
     #define PT_PTRACE_CAP  0x00000010      /* ptracer can follow suid-exec */
    
    +#define is_dumpable(tsk)       ((tsk)->task_dumpable && (tsk)->mm->dumpable)
    +
     /*
      * Limit the stack by to some sane default: root can always
      * increase this limit if needed..  8MB seems reasonable.
    @@ -848,6 +851,8 @@ extern void FASTCALL(remove_wait_queue(w
    
     extern void wait_task_inactive(task_t * p);
     extern void kick_if_running(task_t * p);
    +extern long kernel_thread(int (*fn)(void *), void * arg, unsigned long flags);
    +
    
     #define __wait_event(wq, condition)                                    \
     do {                                                                   \
    diff -purN linux.orig/kernel/fork.c linux/kernel/fork.c
    --- linux.orig/kernel/fork.c    Thu Mar 13 12:01:57 2003
    +++ linux/kernel/fork.c Thu Mar 13 13:51:24 2003
    @@ -28,6 +28,7 @@
     #include <asm/pgalloc.h>
     #include <asm/uaccess.h>
     #include <asm/mmu_context.h>
    +#include <asm/processor.h>
    
     /* The idle threads do not count.. */
     int nr_threads;
    @@ -575,6 +576,31 @@ static inline void copy_flags(unsigned l
            p->flags = new_flags;
     }
    
    +long kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
    +{
    +       struct task_struct *task = current;
    +       unsigned old_task_dumpable;
    +       long ret;
    +
    +       /* lock out any potential ptracer */
    +       task_lock(task);
    +       if (task->ptrace) {
    +               task_unlock(task);
    +               return -EPERM;
    +       }
    +
    +       old_task_dumpable = task->task_dumpable;
    +       task->task_dumpable = 0;
    +       task_unlock(task);
    +
    +       ret = arch_kernel_thread(fn, arg, flags);
    +
    +       /* never reached in child process, only in parent */
    +       current->task_dumpable = old_task_dumpable;
    +
    +       return ret;
    +}
    +
     /*
      *  Ok, this is the main fork-routine. It copies the system process
      * information (task[nr]) and sets up the necessary registers. It also
    diff -purN linux.orig/kernel/ptrace.c linux/kernel/ptrace.c
    --- linux.orig/kernel/ptrace.c  Thu Mar 13 12:01:46 2003
    +++ linux/kernel/ptrace.c       Thu Mar 13 13:47:16 2003
    @@ -21,6 +21,10 @@
      */
     int ptrace_check_attach(struct task_struct *child, int kill)
     {
    +       mb();
    +       if (!is_dumpable(child))
    +               return -EPERM;
    +
            if (!(child->ptrace & PT_PTRACED))
                    return -ESRCH;
    
    @@ -57,7 +61,7 @@ int ptrace_attach(struct task_struct *ta
                (current->gid != task->gid)) && !capable(CAP_SYS_PTRACE))
                    goto bad;
            rmb();
    -       if (!task->mm->dumpable && !capable(CAP_SYS_PTRACE))
    +       if (!is_dumpable(task) && !capable(CAP_SYS_PTRACE))
                    goto bad;
            /* the same process cannot be attached many times */
            if (task->ptrace & PT_PTRACED)
    @@ -123,6 +127,8 @@ int access_process_vm(struct task_struct
            /* Worry about races with exit() */
            task_lock(tsk);
            mm = tsk->mm;
    +       if (!is_dumpable(tsk) || (&init_mm == mm))
    +               mm = NULL;
            if (mm)
                    atomic_inc(&mm->mm_users);
            task_unlock(tsk);
    diff -purN linux.orig/kernel/sys.c linux/kernel/sys.c
    --- linux.orig/kernel/sys.c     Thu Mar 13 12:01:57 2003
    +++ linux/kernel/sys.c  Thu Mar 13 13:41:25 2003
    @@ -1286,7 +1286,7 @@ asmlinkage long sys_prctl(int option, un
                            error = put_user(current->pdeath_signal, (int *)arg2);
                            break;
                    case PR_GET_DUMPABLE:
    -                       if (current->mm->dumpable)
    +                       if (is_dumpable(current))
                                    error = 1;
                            break;
                    case PR_SET_DUMPABLE:
    @@ -1294,7 +1294,8 @@ asmlinkage long sys_prctl(int option, un
                                    error = -EINVAL;
                                    break;
                            }
    -                       current->mm->dumpable = arg2;
    +                       if (is_dumpable(current))
    +                               current->mm->dumpable = arg2;
                            break;
                    case PR_SET_UNALIGN:
     #ifdef SET_UNALIGN_CTL
       _________________________________________________________________________________
    
       No comments have been posted. Log in to post comments.
    
                                                          Copyright (©) 2003, Eklektix, Inc.
                                                Linux (®) is a registered trademark of Linus Torvalds
                                                        Web hosting provided by Rackspace.com.
    -- 
    ===============================================================================
    Matthew Grant	     /\	 ^/\^	grantma@anathoth.gen.nz      /~~~~\
    A Linux Network Guy /~~\^/~~\_/~~~~~\_______/~~~~~~~~~~\____/******\
    ===GPG KeyID: 2EE20270  FingerPrint:
    8C2535E1A11DF3EA5EA19125BA4E790E2EE20270==
    
    

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

Re: Ptrace hole / Linux 2.2.25

[Florian Weimer]

Russell King <rmk@arm.linux.org.uk> writes:

> To give an instance, because I don't work for a distribution, I don't
> have access to the security lists.  Yet, I'm the guy who produces the
> ARM patches which the ARM community at large use.

Well, this is a problem which will be fixed over time.  Amorphous
distributions such as Debian will no longer be notified first, and
non-US distributions will follow if things proceed in the current
direction.  (Look at the handling of the recent IIS vulnerability to
get a glimpse of the future.)

Re: Ptrace hole / Linux 2.2.25

[Alan Cox]

On Sun, 2003-03-23 at 20:33, Florian Weimer wrote:
> Well, this is a problem which will be fixed over time.  Amorphous
> distributions such as Debian will no longer be notified first, and

Why would anyone do that. Debian is a bunch of amateurs true, but
they happen to be a bunch of extremely professional amateurs when it
comes to security.

The problem vendor-sec has is with all the tiny little groups, because
its hard to know if they are going to act securely or not. Now I trust
Russell but thats because I know him, many of the others are hard
choices.

If you get it wrong stuff leaks, take a look at the latest CERT fiasco

Re: Ptrace hole / Linux 2.2.25

[Florian Weimer]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> On Sun, 2003-03-23 at 20:33, Florian Weimer wrote:
>> Well, this is a problem which will be fixed over time.  Amorphous
>> distributions such as Debian will no longer be notified first, and
>
> Why would anyone do that.

Read the IIS rationale for not contacting Apache.

For a different perspective, ask some folks who are involved in the
current IIS issue.  There are many reasons nowadays to restrict
information to non-citizens.

I'm not saying that this is reasonable, but there will always be
people unable to make a rational, informed decision, and if things get
irrational, those without the big pockets tend to lose.

Anyway, the current way security issues are handled will last a year,
maybe two.  I'm not sure in which direction it will evolve, either far
more anarchistic (unlikely), or completely regulated (very likely, I
smell a lot of money down that road).

> Debian is a bunch of amateurs true, but they happen to be a bunch of
> extremely professional amateurs when it comes to security.

I'm not in a position to judge this because the process is too closed.
But in general, they seem to do a good job, I agree.

> If you get it wrong stuff leaks, take a look at the latest CERT fiasco

I don't think things were different if the issues were revealed in a
coordinated manner in June or July.  You can't really fix it anyway
and my Kerberos guru tells me that the community has known for ages
that Kerberos 4 was broken at the protocol level.  Nobody was bothered
enough to write it down, though.

And CERT/CC deliberately leaks stuff to unrelated parties, you know.
This time, you just don't have to pay for it.

Re: Ptrace hole / Linux 2.2.25

[Alan Cox]

On Sun, 2003-03-23 at 21:46, Florian Weimer wrote:
> Anyway, the current way security issues are handled will last a year,
> maybe two.  I'm not sure in which direction it will evolve, either far
> more anarchistic (unlikely), or completely regulated (very likely, I
> smell a lot of money down that road).

Some people would certainly like it that way, and there is certainly 
pressure from some governments to try and hide and censor security
information. 

The slight problem (in fact nonproblem is that most security hole
finders will simply not deal with such people). Vendor-sec gets a
measurable number of reports that specifically forbid their
redistribution to cert for example

Re: Ptrace hole / Linux 2.2.25

[Florian Weimer]

Robert Love <rml@tech9.net> writes:

> Users should rely on their vendors if they cannot rely on
> themselves.

My vendor is the Linux project.  Face it, the kernel is the part of
the distribution which most users tend to throw away first (if they
throw away anything, that is).

Re: Ptrace hole / Linux 2.2.25

[Robert Love]

On Sun, 2003-03-23 at 15:35, Florian Weimer wrote:

> My vendor is the Linux project.  Face it, the kernel is the part of
> the distribution which most users tend to throw away first (if they
> throw away anything, that is).

So is mine - I have my own tree where I do development.

In fact, all of my machines are using a custom kernel.  I do not think I
have ever not, expect perhaps on my laptop.

What is your point?

I never ever said users must use a vendor kernel.  I applaud users for
compiling their own kernel.  I am glad you do.

	Robert Love

Re: Ptrace hole / Linux 2.2.25

[Martin J. Bligh]

> I see a lot of new Red Hat work getting discussed, landing in the 2.5
> tree, and then getting backported as a value-add 2.4 feature for an RH
> kernel.  Other stuff is "hack it into stability, but it's ugly and should
> not go to Marcelo."
> 
> IMNSHO this perception is more a not-looking-hard-enough issue rather
> than reality.

Well ... or we had different meanings ;-) yes, lots of stuff is in 2.5
but I was meaning 2.4. If there's stuff that's in both RH and UL kernels,
and it's stable enough for them both to ship as their product, it sounds
mergeable to me.

> I have no idea about UnitedLinux kernel, but for RHAS I wager there is
> next to _nil_ patches you would actually want to submit to Marcelo, for
> three main reasons:  it's a 2.5 backport, or, it's a 2.4.2X backport, or,
> its an ugly-hack-for-stability that should not be in a mainline kernel
> without cleaning anyway.

I don't see what's wrong with putting 2.5 backports into 2.4 once they're
stable. And I'd rather have an ugly-hack-for-stability than an unstable
kernel ... 2.5 is the place for cleanliness ... 2.4 is a dead end that
just needs to work.

> Can you actually quantify this divergance?
> 
>  From actually _looking_ at RHAS for submittable patches, it seems to me
> like mostly 2.5-backport patches in 2.4, or, bandaid-until-2.5 fixes that
> don't belong in mainline.

Right ... I think we're agreeing about what's the difference. Just
disagreeing about what should be in mainline 2.4. If most others think it
shouldn't go either, than I guess we need a separate tree for a 2.4 that
works, not a 2.4 that's pretty ...

M.

Re: Ptrace hole / Linux 2.2.25

[Jeff Garzik]

Martin J. Bligh wrote:
>>I see a lot of new Red Hat work getting discussed, landing in the 2.5
>>tree, and then getting backported as a value-add 2.4 feature for an RH
>>kernel.  Other stuff is "hack it into stability, but it's ugly and should
>>not go to Marcelo."
>>
>>IMNSHO this perception is more a not-looking-hard-enough issue rather
>>than reality.
> 
> 
> Well ... or we had different meanings ;-) yes, lots of stuff is in 2.5
> but I was meaning 2.4. If there's stuff that's in both RH and UL kernels,
> and it's stable enough for them both to ship as their product, it sounds
> mergeable to me.

That's a _really_ naive statement, that proves you haven't even looked 
at what you are talking about.

The currently released RHAS is based off 2.4.9, with a lot of tweaks 
specifically for the VM/VFS layer as it existed at that time. 
(Remember, the VM was basically replaced in 2.4.10)  That's a totally 
dead end branch (from a mainline perspective) with very little mergeable 
worth.

Still, if you want to create a "2.4-features++" branch, I think that 
there is value there.  Just PLEASE don't put the junk in mainline.


>>I have no idea about UnitedLinux kernel, but for RHAS I wager there is
>>next to _nil_ patches you would actually want to submit to Marcelo, for
>>three main reasons:  it's a 2.5 backport, or, it's a 2.4.2X backport, or,
>>its an ugly-hack-for-stability that should not be in a mainline kernel
>>without cleaning anyway.
> 
> 
> I don't see what's wrong with putting 2.5 backports into 2.4 once they're
> stable. And I'd rather have an ugly-hack-for-stability than an unstable
> kernel ... 2.5 is the place for cleanliness ... 2.4 is a dead end that
> just needs to work.

That's no excuse for sloppiness in 2.4.


> Right ... I think we're agreeing about what's the difference. Just
> disagreeing about what should be in mainline 2.4. If most others think it
> shouldn't go either, than I guess we need a separate tree for a 2.4 that
> works, not a 2.4 that's pretty ...


I agree that we are disagreeing about what should be mainline 2.4 :)

"People are shipping it, so it must be good" is the proverbial 
road-to-hell-paved-with-good-intentions.

	Jeff

Re: Ptrace hole / Linux 2.2.25

[Martin J. Bligh]

>> Well ... or we had different meanings ;-) yes, lots of stuff is in 2.5
>> but I was meaning 2.4. If there's stuff that's in both RH and UL kernels,
>> and it's stable enough for them both to ship as their product, it sounds
>> mergeable to me.
> 
> That's a _really_ naive statement, that proves you haven't even looked at
> what you are talking about.

No, I just think we have different definitions of "mergeable" ;-)
 
> The currently released RHAS is based off 2.4.9, with a lot of tweaks
> specifically for the VM/VFS layer as it existed at that time. (Remember,
> the VM was basically replaced in 2.4.10)  That's a totally dead end
> branch (from a mainline perspective) with very little mergeable worth.

Right ... looking at more recent stuff would be the way to go.
 
> Still, if you want to create a "2.4-features++" branch, I think that
> there is value there.  Just PLEASE don't put the junk in mainline.

Sure, it can always be a separate fork. I just hate all the duplicated
effort that's going on right now.

> I agree that we are disagreeing about what should be mainline 2.4 :)
> 
> "People are shipping it, so it must be good" is the proverbial
> road-to-hell-paved-with-good-intentions.

Mmmm ... not sure what that says about the vendor kernels ;-) I have a more
"if it works, use it" attitude to the 2.4 tree ... IMHO, I'd like to see
the mainline 2.4 tree be more pragmatic, and 2.5 do "the right thing". As
long as the development tree is clean, it seems maintainable on a long term
basis to me. 

But I'm well aware that that's in disagreement with others ... having a
separate "common-vendor" tree is probably the right thing to do. People
will just argue about that instead though ...proably needs one for the
intersection of the "workstation" trees, and one for the intersection of the
"enterprise" trees. Getting all the vendors basing off it is obviously
pretty important too ;-)

M.

Re: Ptrace hole / Linux 2.2.25

[Stephan von Krawczynski]

On Sun, 23 Mar 2003 15:06:35 -0800
"Martin J. Bligh" <mbligh@aracnet.com> wrote:

> > I agree that we are disagreeing about what should be mainline 2.4 :)

I guess this is the main reason why kernel-maintenance is organized
non-democratic (and has always been). Sometimes you just get nowhere if 5
brilliant people (_no_ sarcasm here) talk about at least 6 brilliant, but
completely different, ideas.

> > "People are shipping it, so it must be good" is the proverbial
> > road-to-hell-paved-with-good-intentions.
> 
> Mmmm ... not sure what that says about the vendor kernels ;-)

As we all know it just says everything.

> But I'm well aware that that's in disagreement with others ... having a
> separate "common-vendor" tree is probably the right thing to do.

dear Martin, dear Jeff, dear all,

_please_ be honest and realistic: we are talking about the problem of vendors
forking around yakr (Yet Another Kernel Release) and you really say "lets solve
it all with _another_ fork" ?? Come on, don't be silly (tm Linus).
Let's focus and not fork. There _are_ issues with 2.4, but they are getting
solved bit-by-bit. It would be faster of course if we all would concentrate on
the _mainline_ and not on yet-another patchlist, split-tree or whatever.

Another thing has already been talked about here, so lets talk real open about
it: some of us are living in the strong impression that Marcelo has problems
with the pure time working on maintaining. I do not know anything about the
backgrounds, but if this is really true, then let _me_ ask Conectiva if there
is a chance that he can do the maintaining full-time. I mean this is for sure
one of the interesting PR activities, too. After all those years it is still
true: there can be only one.
Of course this only makes sense if he still really wants to do that. _Me_
asking this because I am in no way related to any other distro, vendor or
Marcelo, just being the "linux-enthusiast from next-door" (with management
background ;-). 

JMHO
Stephan

Re: Ptrace hole / Linux 2.2.25

[Christoph Hellwig]

this might sound a bit AOLish, but I fully agree.

Re: Ptrace hole / Linux 2.2.25

[Martin J. Bligh]

> _please_ be honest and realistic: we are talking about the problem of
> vendors forking around yakr (Yet Another Kernel Release) and you really
> say "lets solve it all with _another_ fork" ?? Come on, don't be silly
> (tm Linus). Let's focus and not fork. There _are_ issues with 2.4, but
> they are getting solved bit-by-bit. It would be faster of course if we
> all would concentrate on the _mainline_ and not on yet-another patchlist,
> split-tree or whatever.

I see your point, and I'd love to get this stuff merged back to mainline
2.4, and that would actually be the whole point of doing this ... to
provide a channel of stuff that should get merged back. The other thing to
bear in mind is that what I want is not really another to turn 4 branches
into 5, it's to turn 4 branches into two branches with a couple of twigs
off each ;-) So I actually want *more* commonality.
 
> Another thing has already been talked about here, so lets talk real open
> about it: some of us are living in the strong impression that Marcelo has
> problems with the pure time working on maintaining. I do not know
> anything about the backgrounds, but if this is really true, then let _me_
> ask Conectiva if there is a chance that he can do the maintaining
> full-time. I mean this is for sure one of the interesting PR activities,
> too. After all those years it is still true: there can be only one.
> Of course this only makes sense if he still really wants to do that. _Me_
> asking this because I am in no way related to any other distro, vendor or
> Marcelo, just being the "linux-enthusiast from next-door" (with management
> background ;-). 

If Marcelo would like some more help from others for integration / testing
whatever, I'm sure it could be arranged if he described what he'd like. I
know that helps me out a lot at least if I can get others to help me ...
(eg. take these 5 patches, merge them on top of my latest prerelease, and
kick the snot of them for me to see if they're basically looking OK). 

There's plenty of talent and enthusiasm around on LKML that's able to share
the burden ... would be much more constructive than us (myself included)
complaining ;-)

M.

PS. If Andrea's VM fixes are a good candidate, that people are seriously
interested in, I'll get myself and others here to give them a beating.

Re: Ptrace hole / Linux 2.2.25

[Stephan von Krawczynski]

On Mon, 24 Mar 2003 07:40:58 -0800
"Martin J. Bligh" <mbligh@aracnet.com> wrote:

> > [no new trees]
> 
> I see your point, and I'd love to get this stuff merged back to mainline
> 2.4, and that would actually be the whole point of doing this ... to
> provide a channel of stuff that should get merged back. The other thing to
> bear in mind is that what I want is not really another to turn 4 branches
> into 5, it's to turn 4 branches into two branches with a couple of twigs
> off each ;-) So I actually want *more* commonality.

I do know your brave intentions, only you are heading in the wrong direction.
Simple thing is: the more you split off new trees the fewer testing they will
get. This is simply because only very (read VERY) few people run different
trees (kernels) every day on their boxes. They decide for _one_ tree and try to
stay there. Simply because most people want to do something useful besides the
testing. So they cannot go and reboot their machines 20 times a day only to
know which patch of what tree looks like being "the right thing(tm)" for them.
Forget that.
So the more trees you spin off the fewer testing your mainline will get, _and_
the lower the pressure will be to make the needed patches work in the mainline.
The people needing good working SMP/VM/name-one will go and use -aa -rmap
-name-one instead, because they believe they have no other chance _right now_.
And they won't come back that easy.
The only thing that can be done against this phenomenon is to speed up mainline
patch release and make it _reliable_. This is why I made the suggestion
(elsewhere) to release a -pre every week on the same weekday. People will know
when the next one comes in. They have a plan, it is reliable.
Another very good reason is: the steps between the -pres are smaller, so there
is less risk for a complete failure or a mis-direction of certain development
steps.
And again this is a good argument for Marcelo needing more time for
maintenance, more releases = more time.

> > Another thing has already been talked about here, so lets talk real open
> > about it: some of us are living in the strong impression that Marcelo has
> > problems with the pure time working on maintaining. I do not know
> > anything about the backgrounds, but if this is really true, then let _me_
> > ask Conectiva if there is a chance that he can do the maintaining
> > full-time. I mean this is for sure one of the interesting PR activities,
> > too. After all those years it is still true: there can be only one.
> > Of course this only makes sense if he still really wants to do that. _Me_
> > asking this because I am in no way related to any other distro, vendor or
> > Marcelo, just being the "linux-enthusiast from next-door" (with management
> > background ;-). 
> 
> If Marcelo would like some more help from others for integration / testing
> whatever, I'm sure it could be arranged if he described what he'd like. I
> know that helps me out a lot at least if I can get others to help me ...
> (eg. take these 5 patches, merge them on top of my latest prerelease, and
> kick the snot of them for me to see if they're basically looking OK). 
> 
> There's plenty of talent and enthusiasm around on LKML that's able to share
> the burden ... would be much more constructive than us (myself included)
> complaining ;-)
> 
> M.

This is no real solution. There are already maintainers for big and small parts
of the kernel. The simple truth is: there are quite a lot of parts, and there
is no way around the fact that one person (the lines maintainer) has to keep
it all together somehow - and you need time to do that. This _is_ a really
important job.

Sh*t, I do not really want to initiate major discussion about this whole issue,
as I do believe that most of the story is clear to most of the people, and
after all it is a tech mailing list. We could talk for years with no productive
outcome ever.

--- 
Regards,
Stephan

Re: Ptrace hole / Linux 2.2.25

[Dr. Greg Wettstein]

On Mar 24, 10:33am, jlnance@unity.ncsu.edu wrote:
} Subject: Re: Ptrace hole / Linux 2.2.25

Good morning to everyone.

> On Sun, Mar 23, 2003 at 08:44:23PM +0100, Martin Mares wrote:
> 
> > Do you really think that "People should either use vendor kernels or
> > read LKML and be able to gather the fixes from there themselves" is a
> > good strategy?

> Hi Martin,
>     I must say that I think it is an excellent strategy.  I will admit
> though, that I have voiced this opinion several times in the past and
> it seems that most people disagree with me.
>     I think we do a disservice to people by encouraging them to believe
> that the kernels they download from kernel.org can be depended on to
> work.  Kernel.org kernels are effectivly a way for people to participate
> in the development process and to help with QA.  If you dont want to
> be involved with these activities, you really do not want to use those
> kernels.
>     We could try and make that guarantee if we wanted to, but it would
> be a lot of work and the vendors are already doing it.  So why not
> leverage their work?

Let me state clearly that I don't have any problems with money being
made off free software.  I also understand the importance of Linux
vendors.

That being said the reason not to leverage their work is that the
reality of capitalism implies an imperative on the vendor to make
decisions which make 'their' kernel more appealing from a marketing
perspective.  Unfortunately the history of the software industry has
pretty effectively demonstrated that making software appealing from a
marketing perspective is at direct odds to producing a quality
product.

I personally have seen too many cases of vendor kernels exploding or
having problems in environments where I run stock statically compiled
kernels without problems.  That isn't meant as an indictment but an
observational fact.

I think the strategy of having a 'hot-list' of security or critical
performance patches for the current release kernel makes the most
amount of sense.  Those people that are comfortable with rolling their
own kernels can grab the patches and have at it.  The presence of
those patches shouldn't affect the steady progression of maintenance
on the 'stable' kernel.

> Jim

}-- End of excerpt from jlnance@unity.ncsu.edu

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-4950            WWW: http://www.enjellic.com
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"Intel engineering seem to have misheard Intel marketing strategy.  The
phrase was 'Divide and conquer' not 'Divide and cock up'".
                                -- Alan Cox