Linux 2.6.14.1

Linux 2.6.14.1

[Greg KH]

We (the -stable team) are announcing the release of the 2.6.14.1 kernel.

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch between
2.6.14 and 2.6.14.1, as it is small enough to do so.

The updated 2.6.14.y git tree can be found at:
	rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/linux-2.6.14.y.git
and can be browsed at the normal kernel.org git web browser:
	www.kernel.org/git/

thanks,

greg k-h

--------

 Makefile                           |    2 
 arch/s390/appldata/appldata_base.c |    7 +
 include/linux/proc_fs.h            |    1 
 include/linux/sysctl.h             |    3 
 kernel/sysctl.c                    |  136 +++++++++++++++++++++++++++++--------
 5 files changed, 117 insertions(+), 32 deletions(-)


Summary of changes from v2.6.13.3 to v2.6.13.4
============================================

Al Viro:
      CVE-2005-2709 sysctl unregistration oops

Greg Kroah-Hartman:
      Linux 2.6.14.1

Re: Linux 2.6.14.1

[Greg KH]

diff --git a/Makefile b/Makefile
index 1fa7e53..e5315e6 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 14
-EXTRAVERSION =
+EXTRAVERSION = .1
 NAME=Affluent Albatross
 
 # *DOCUMENTATION*
diff --git a/arch/s390/appldata/appldata_base.c b/arch/s390/appldata/appldata_base.c
index c9f2f60..dee6ab5 100644
--- a/arch/s390/appldata/appldata_base.c
+++ b/arch/s390/appldata/appldata_base.c
@@ -592,12 +592,15 @@ int appldata_register_ops(struct appldat
  */
 void appldata_unregister_ops(struct appldata_ops *ops)
 {
+	void *table;
 	spin_lock(&appldata_ops_lock);
-	unregister_sysctl_table(ops->sysctl_header);
 	list_del(&ops->list);
-	kfree(ops->ctl_table);
+	/* at that point any incoming access will fail */
+	table = ops->ctl_table;
 	ops->ctl_table = NULL;
 	spin_unlock(&appldata_ops_lock);
+	unregister_sysctl_table(ops->sysctl_header);
+	kfree(table);
 	P_INFO("%s-ops unregistered!\n", ops->name);
 }
 /********************** module-ops management <END> **************************/
diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h
index 0563581..a7b0329 100644
--- a/include/linux/proc_fs.h
+++ b/include/linux/proc_fs.h
@@ -66,6 +66,7 @@ struct proc_dir_entry {
 	write_proc_t *write_proc;
 	atomic_t count;		/* use count */
 	int deleted;		/* delete flag */
+	void *set;
 };
 
 struct kcore_list {
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index fc8e367..fc131d6 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -24,6 +24,7 @@
 #include <linux/compiler.h>
 
 struct file;
+struct completion;
 
 #define CTL_MAXNAME 10		/* how many path components do we allow in a
 				   call to sysctl?   In other words, what is
@@ -925,6 +926,8 @@ struct ctl_table_header
 {
 	ctl_table *ctl_table;
 	struct list_head ctl_entry;
+	int used;
+	struct completion *unregistering;
 };
 
 struct ctl_table_header * register_sysctl_table(ctl_table * table, 
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 8e56e24..b90dba7 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -169,7 +169,7 @@ struct file_operations proc_sys_file_ope
 
 extern struct proc_dir_entry *proc_sys_root;
 
-static void register_proc_table(ctl_table *, struct proc_dir_entry *);
+static void register_proc_table(ctl_table *, struct proc_dir_entry *, void *);
 static void unregister_proc_table(ctl_table *, struct proc_dir_entry *);
 #endif
 
@@ -992,10 +992,51 @@ static ctl_table dev_table[] = {
 
 extern void init_irq_proc (void);
 
+static DEFINE_SPINLOCK(sysctl_lock);
+
+/* called under sysctl_lock */
+static int use_table(struct ctl_table_header *p)
+{
+	if (unlikely(p->unregistering))
+		return 0;
+	p->used++;
+	return 1;
+}
+
+/* called under sysctl_lock */
+static void unuse_table(struct ctl_table_header *p)
+{
+	if (!--p->used)
+		if (unlikely(p->unregistering))
+			complete(p->unregistering);
+}
+
+/* called under sysctl_lock, will reacquire if has to wait */
+static void start_unregistering(struct ctl_table_header *p)
+{
+	/*
+	 * if p->used is 0, nobody will ever touch that entry again;
+	 * we'll eliminate all paths to it before dropping sysctl_lock
+	 */
+	if (unlikely(p->used)) {
+		struct completion wait;
+		init_completion(&wait);
+		p->unregistering = &wait;
+		spin_unlock(&sysctl_lock);
+		wait_for_completion(&wait);
+		spin_lock(&sysctl_lock);
+	}
+	/*
+	 * do not remove from the list until nobody holds it; walking the
+	 * list in do_sysctl() relies on that.
+	 */
+	list_del_init(&p->ctl_entry);
+}
+
 void __init sysctl_init(void)
 {
 #ifdef CONFIG_PROC_FS
-	register_proc_table(root_table, proc_sys_root);
+	register_proc_table(root_table, proc_sys_root, &root_table_header);
 	init_irq_proc();
 #endif
 }
@@ -1004,6 +1045,7 @@ int do_sysctl(int __user *name, int nlen
 	       void __user *newval, size_t newlen)
 {
 	struct list_head *tmp;
+	int error = -ENOTDIR;
 
 	if (nlen <= 0 || nlen >= CTL_MAXNAME)
 		return -ENOTDIR;
@@ -1012,20 +1054,30 @@ int do_sysctl(int __user *name, int nlen
 		if (!oldlenp || get_user(old_len, oldlenp))
 			return -EFAULT;
 	}
+	spin_lock(&sysctl_lock);
 	tmp = &root_table_header.ctl_entry;
 	do {
 		struct ctl_table_header *head =
 			list_entry(tmp, struct ctl_table_header, ctl_entry);
 		void *context = NULL;
-		int error = parse_table(name, nlen, oldval, oldlenp, 
+
+		if (!use_table(head))
+			continue;
+
+		spin_unlock(&sysctl_lock);
+
+		error = parse_table(name, nlen, oldval, oldlenp, 
 					newval, newlen, head->ctl_table,
 					&context);
 		kfree(context);
+
+		spin_lock(&sysctl_lock);
+		unuse_table(head);
 		if (error != -ENOTDIR)
-			return error;
-		tmp = tmp->next;
-	} while (tmp != &root_table_header.ctl_entry);
-	return -ENOTDIR;
+			break;
+	} while ((tmp = tmp->next) != &root_table_header.ctl_entry);
+	spin_unlock(&sysctl_lock);
+	return error;
 }
 
 asmlinkage long sys_sysctl(struct __sysctl_args __user *args)
@@ -1236,12 +1288,16 @@ struct ctl_table_header *register_sysctl
 		return NULL;
 	tmp->ctl_table = table;
 	INIT_LIST_HEAD(&tmp->ctl_entry);
+	tmp->used = 0;
+	tmp->unregistering = NULL;
+	spin_lock(&sysctl_lock);
 	if (insert_at_head)
 		list_add(&tmp->ctl_entry, &root_table_header.ctl_entry);
 	else
 		list_add_tail(&tmp->ctl_entry, &root_table_header.ctl_entry);
+	spin_unlock(&sysctl_lock);
 #ifdef CONFIG_PROC_FS
-	register_proc_table(table, proc_sys_root);
+	register_proc_table(table, proc_sys_root, tmp);
 #endif
 	return tmp;
 }
@@ -1255,10 +1311,13 @@ struct ctl_table_header *register_sysctl
  */
 void unregister_sysctl_table(struct ctl_table_header * header)
 {
-	list_del(&header->ctl_entry);
+	might_sleep();
+	spin_lock(&sysctl_lock);
+	start_unregistering(header);
 #ifdef CONFIG_PROC_FS
 	unregister_proc_table(header->ctl_table, proc_sys_root);
 #endif
+	spin_unlock(&sysctl_lock);
 	kfree(header);
 }
 
@@ -1269,7 +1328,7 @@ void unregister_sysctl_table(struct ctl_
 #ifdef CONFIG_PROC_FS
 
 /* Scan the sysctl entries in table and add them all into /proc */
-static void register_proc_table(ctl_table * table, struct proc_dir_entry *root)
+static void register_proc_table(ctl_table * table, struct proc_dir_entry *root, void *set)
 {
 	struct proc_dir_entry *de;
 	int len;
@@ -1305,13 +1364,14 @@ static void register_proc_table(ctl_tabl
 			de = create_proc_entry(table->procname, mode, root);
 			if (!de)
 				continue;
+			de->set = set;
 			de->data = (void *) table;
 			if (table->proc_handler)
 				de->proc_fops = &proc_sys_file_operations;
 		}
 		table->de = de;
 		if (de->mode & S_IFDIR)
-			register_proc_table(table->child, de);
+			register_proc_table(table->child, de, set);
 	}
 }
 
@@ -1336,6 +1396,13 @@ static void unregister_proc_table(ctl_ta
 				continue;
 		}
 
+		/*
+		 * In any case, mark the entry as goner; we'll keep it
+		 * around if it's busy, but we'll know to do nothing with
+		 * its fields.  We are under sysctl_lock here.
+		 */
+		de->data = NULL;
+
 		/* Don't unregister proc entries that are still being used.. */
 		if (atomic_read(&de->count))
 			continue;
@@ -1349,27 +1416,38 @@ static ssize_t do_rw_proc(int write, str
 			  size_t count, loff_t *ppos)
 {
 	int op;
-	struct proc_dir_entry *de;
+	struct proc_dir_entry *de = PDE(file->f_dentry->d_inode);
 	struct ctl_table *table;
 	size_t res;
-	ssize_t error;
-	
-	de = PDE(file->f_dentry->d_inode);
-	if (!de || !de->data)
-		return -ENOTDIR;
-	table = (struct ctl_table *) de->data;
-	if (!table || !table->proc_handler)
-		return -ENOTDIR;
-	op = (write ? 002 : 004);
-	if (ctl_perm(table, op))
-		return -EPERM;
+	ssize_t error = -ENOTDIR;
 	
-	res = count;
-
-	error = (*table->proc_handler) (table, write, file, buf, &res, ppos);
-	if (error)
-		return error;
-	return res;
+	spin_lock(&sysctl_lock);
+	if (de && de->data && use_table(de->set)) {
+		/*
+		 * at that point we know that sysctl was not unregistered
+		 * and won't be until we finish
+		 */
+		spin_unlock(&sysctl_lock);
+		table = (struct ctl_table *) de->data;
+		if (!table || !table->proc_handler)
+			goto out;
+		error = -EPERM;
+		op = (write ? 002 : 004);
+		if (ctl_perm(table, op))
+			goto out;
+		
+		/* careful: calling conventions are nasty here */
+		res = count;
+		error = (*table->proc_handler)(table, write, file,
+						buf, &res, ppos);
+		if (!error)
+			error = res;
+	out:
+		spin_lock(&sysctl_lock);
+		unuse_table(de->set);
+	}
+	spin_unlock(&sysctl_lock);
+	return error;
 }
 
 static int proc_opensys(struct inode *inode, struct file *file)

Re: Linux 2.6.14.1

[Coywolf Qi Hunt]

2005/11/9, Greg KH <gregkh@suse.de>:
> We (the -stable team) are announcing the release of the 2.6.14.1 kernel.
>
> The diffstat and short summary of the fixes are below.
>
> I'll also be replying to this message with a copy of the patch between
> 2.6.14 and 2.6.14.1, as it is small enough to do so.
>
> The updated 2.6.14.y git tree can be found at:
>         rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/linux-2.6.14.y.git
> and can be browsed at the normal kernel.org git web browser:
>         www.kernel.org/git/


I'd appreciate it that if you would not overwrite the 2.6.14 record on
the kernel.org page, but add a new record for 2.6.14.y instead. It
would benefit others too. FYI: http://lkml.org/lkml/2005/10/9/18

It's uninteresting for people to install the stable kernel x.x.x.y
sometimes. Leave the base kernel x.x.x there would be convenient.
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/

Re: [stable] Re: Linux 2.6.14.1

[Greg KH]

On Wed, Nov 09, 2005 at 10:05:43AM +0800, Coywolf Qi Hunt wrote:
> 2005/11/9, Greg KH <gregkh@suse.de>:
> > We (the -stable team) are announcing the release of the 2.6.14.1 kernel.
> >
> > The diffstat and short summary of the fixes are below.
> >
> > I'll also be replying to this message with a copy of the patch between
> > 2.6.14 and 2.6.14.1, as it is small enough to do so.
> >
> > The updated 2.6.14.y git tree can be found at:
> >         rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/linux-2.6.14.y.git
> > and can be browsed at the normal kernel.org git web browser:
> >         www.kernel.org/git/
> 
> 
> I'd appreciate it that if you would not overwrite the 2.6.14 record on
> the kernel.org page, but add a new record for 2.6.14.y instead. It
> would benefit others too. FYI: http://lkml.org/lkml/2005/10/9/18

Sorry, but I am not in charge of that at all.  Please contact the
kernel.org web masters if you want to discuss this.  And as 2.6.14 now
has a documented security issue, I wouldn't recommend it being displayed
on the kernel.org page anyway.

Tools like ketchup can handle updating to the proper kernel version just
fine if you want to use it, instead of having to rely on web pages :)

thanks,

greg k-h

Re: Linux 2.6.14.1

[Ernst Herzberg]

[....]
> Summary of changes from v2.6.13.3 to v2.6.13.4
> ============================================
>
> Al Viro:
>       CVE-2005-2709 sysctl unregistration oops
>
> Greg Kroah-Hartman:
>       Linux 2.6.14.1

Hu? Version numbers mixed, or does this BUG also affect 2.6.13.x? 

Re: [stable] Re: Linux 2.6.14.1

[Chris Wright]

* Ernst Herzberg (earny@net4u.de) wrote:
> [....]
> > Summary of changes from v2.6.13.3 to v2.6.13.4
> > ============================================
> >
> > Al Viro:
> >       CVE-2005-2709 sysctl unregistration oops
> >
> > Greg Kroah-Hartman:
> >       Linux 2.6.14.1
> 
> Hu? Version numbers mixed, or does this BUG also affect 2.6.13.x? 

Yes, both a mixup in the message, and it effects older kernels.

thanks,
-chris

Re: [stable] Re: Linux 2.6.14.1

[Greg KH]

On Wed, Nov 09, 2005 at 03:22:59AM +0100, Ernst Herzberg wrote:
> [....]
> > Summary of changes from v2.6.13.3 to v2.6.13.4
> > ============================================
> >
> > Al Viro:
> >       CVE-2005-2709 sysctl unregistration oops
> >
> > Greg Kroah-Hartman:
> >       Linux 2.6.14.1
> 
> Hu? Version numbers mixed, or does this BUG also affect 2.6.13.x? 

Sorry about that, that line was cut and pasted from an older email
message and I forgot to update it.  The Changelog on kernel.org shows
that the two entries are correct.

Again, very sorry for any potential confusion.

thanks,

greg k-h

Re: [stable] Re: Linux 2.6.14.1

[Coywolf Qi Hunt]

2005/11/9, Greg KH <greg@kroah.com>:
> On Wed, Nov 09, 2005 at 10:05:43AM +0800, Coywolf Qi Hunt wrote:
> > 2005/11/9, Greg KH <gregkh@suse.de>:
> > > We (the -stable team) are announcing the release of the 2.6.14.1 kernel.
> > >
> > > The diffstat and short summary of the fixes are below.
> > >
> > > I'll also be replying to this message with a copy of the patch between
> > > 2.6.14 and 2.6.14.1, as it is small enough to do so.
> > >
> > > The updated 2.6.14.y git tree can be found at:
> > >         rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/linux-2.6.14.y.git
> > > and can be browsed at the normal kernel.org git web browser:
> > >         www.kernel.org/git/
> >
> >
> > I'd appreciate it that if you would not overwrite the 2.6.14 record on
> > the kernel.org page, but add a new record for 2.6.14.y instead. It
> > would benefit others too. FYI: http://lkml.org/lkml/2005/10/9/18
>
> Sorry, but I am not in charge of that at all.  Please contact the
> kernel.org web masters if you want to discuss this.  And as 2.6.14 now
> has a documented security issue, I wouldn't recommend it being displayed
> on the kernel.org page anyway.
>
> Tools like ketchup can handle updating to the proper kernel version just
> fine if you want to use it, instead of having to rely on web pages :)

I tried a little. Nice tool! I have my own script with some of
ketchup's function partially for easy my lxr site maintaining. I'll
adapt my script to use it probably. Thanks.
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/

Re: [stable] Re: Linux 2.6.14.1

[Ernst Herzberg]

On Wednesday 09 November 2005 03:40, Greg KH wrote:
[...]
> Sorry about that, that line was cut and pasted from an older email
> message and I forgot to update it.  The Changelog on kernel.org shows
> that the two entries are correct.

No prob, thx.

I want only be shure. I had one Oops on an older Kernel, 2.6.11, uptime 153 Days.

Oops:

Nov  4 02:51:13 moci kernel BUG at include/linux/dcache.h:293!
Nov  4 02:51:13 moci invalid operand: 0000 [#1]
Nov  4 02:51:13 moci PREEMPT SMP
Nov  4 02:51:13 moci Modules linked in: w83627hf eeprom i2c_isa i2c_i801 i2c_dev nfsd exportfs lockd sunrpc snd_pcm_oss snd_mixer_oss ipt_MARK ipt_MASQUERA
DE iptable_mangle iptable_nat ip_conntrack iptable_filter ip_tables ebt_log ebt_ip ebtable_filter ebtables i2c_sensor ohci_hcd ohci1394 ieee1394 snd_intel8
x0 snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc ehci_hcd auerswald usblp uhci_hcd usbcore
Nov  4 02:51:13 moci CPU:    1
Nov  4 02:51:13 moci EIP:    0060:[<c0185b19>]    Tainted: G   M  VLI
Nov  4 02:51:13 moci EFLAGS: 00010246   (2.6.11)
Nov  4 02:51:13 moci EIP is at sysfs_remove_dir+0xe9/0x100
Nov  4 02:51:13 moci eax: 00000000   ebx: f4f71e20   ecx: c0262220   edx: f4f71e20
Nov  4 02:51:13 moci esi: f6778240   edi: dc089e60   ebp: f6778240   esp: cab14ecc
Nov  4 02:51:13 moci ds: 007b   es: 007b   ss: 0068
Nov  4 02:51:13 moci Process brctl (pid: 29551, threadinfo=cab14000 task=eb561a80)
Nov  4 02:51:13 moci Stack: f60dd3b0 f4f71e20 f6778240 00000006 f6778240 c01dfc94 f4f71d80 c0354f41
Nov  4 02:51:13 moci c9ed9800 f4f71d80 c0355e8b c042a860 c9ed9800 00000006 f6202e20 c01263c8
Nov  4 02:51:13 moci c9ed9800 c9ed9800 d55dc828 c02f94c6 00000202 c02f33bb c9ed9a64 c9e14180
Nov  4 02:51:13 moci Call Trace:
Nov  4 02:51:13 moci [<c01dfc94>] kobject_del+0x14/0x20
Nov  4 02:51:13 moci [<c0354f41>] br_del_if+0x31/0x51
Nov  4 02:51:13 moci [<c0355e8b>] br_device_event+0xcb/0xf0
Nov  4 02:51:13 moci [<c01263c8>] notifier_call_chain+0x18/0x40
Nov  4 02:51:13 moci [<c02f94c6>] unregister_netdevice+0x136/0x250
Nov  4 02:51:13 moci [<c02f33bb>] skb_dequeue+0x4b/0x60
Nov  4 02:51:13 moci [<c02a0245>] tun_chr_close+0x75/0x80
Nov  4 02:51:13 moci [<c0153ff6>] __fput+0x106/0x120
Nov  4 02:51:13 moci [<c01527ff>] filp_close+0x4f/0x80
Nov  4 02:51:13 moci [<c011b4b1>] put_files_struct+0x61/0xb0
Nov  4 02:51:13 moci [<c011c101>] do_exit+0xd1/0x350
Nov  4 02:51:13 moci [<c01645be>] vfs_ioctl+0x5e/0x1d0
Nov  4 02:51:13 moci [<c0153fa9>] __fput+0xb9/0x120
Nov  4 02:51:13 moci [<c011c3f7>] do_group_exit+0x37/0xa0
Nov  4 02:51:13 moci [<c01026ff>] syscall_call+0x7/0xb
Nov  4 02:51:13 moci Code: 89 f2 e8 bb 84 fb ff eb 90 8b 46 14 89 04 24 8b 00 e8 6c 85 fb ff 8b 14 24 8b 42 04 e8 71 a2 05 00 8b 04 24 e8 59 85 fb ff eb d0
 <0f> 0b 25 01 4c 9b 37 c0 e9 26 ff ff ff 58 5b 5e 5f 5d c3 8d 74

Installed 2.6.14 now, running without problems.

Ok, this one was running > 150 days... only to make shure, that older Kernles
also affected. Or is this Bug different?

Thx, earny

Re: Linux 2.6.14.1

[Andrew Morton]

Greg KH <gregkh@suse.de> wrote:
>
> We (the -stable team) are announcing the release of the 2.6.14.1 kernel.

We need the fix for the net-drops-zero-length-udp-messages bug which broke
bind and traceroute.



Begin forwarded message:

Date: Fri, 4 Nov 2005 12:04:53 -0800
From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
To: git-commits-head@vger.kernel.org
Subject: [NET]: Fix zero-size datagram reception


tree ee282f7fd6e465d7b031d64b9ed7c03233ea94cf
parent c2da8acaf488b8651edfb04ebf3ab089f3a7830f
author Herbert Xu <herbert@gondor.apana.org.au> Wed, 02 Nov 2005 18:55:00 +1100
committer Arnaldo Carvalho de Melo <acme@mandriva.com> Thu, 03 Nov 2005 02:25:04 -0200

[NET]: Fix zero-size datagram reception

The recent rewrite of skb_copy_datagram_iovec broke the reception of
zero-size datagrams.  This patch fixes it.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>

 net/core/datagram.c |    4 ++++
 1 files changed, 4 insertions(+)

diff --git a/net/core/datagram.c b/net/core/datagram.c
index 81987df..d219435 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -213,6 +213,10 @@ int skb_copy_datagram_iovec(const struct
 {
 	int i, err, fraglen, end = 0;
 	struct sk_buff *next = skb_shinfo(skb)->frag_list;
+
+	if (!len)
+		return 0;
+
 next_skb:
 	fraglen = skb_headlen(skb);
 	i = -1;
-
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux 2.6.14.1

[David S. Miller]

From: Andrew Morton <akpm@osdl.org>
Date: Tue, 8 Nov 2005 21:13:54 -0800

> Greg KH <gregkh@suse.de> wrote:
> >
> > We (the -stable team) are announcing the release of the 2.6.14.1 kernel.
> 
> We need the fix for the net-drops-zero-length-udp-messages bug which broke
> bind and traceroute.

Yes, and I was pretty sure I saw Herbert submit this to
stable@kernel.org even.

In any event, yes please put that in.

Re: [stable] Re: Linux 2.6.14.1

[Chris Wright]

* David S. Miller (davem@davemloft.net) wrote:
> From: Andrew Morton <akpm@osdl.org>
> Date: Tue, 8 Nov 2005 21:13:54 -0800
> 
> > Greg KH <gregkh@suse.de> wrote:
> > >
> > > We (the -stable team) are announcing the release of the 2.6.14.1 kernel.
> > 
> > We need the fix for the net-drops-zero-length-udp-messages bug which broke
> > bind and traceroute.
> 
> Yes, and I was pretty sure I saw Herbert submit this to
> stable@kernel.org even.
> 
> In any event, yes please put that in.

Yes, it's queued, will be part of .2 review cycle.

thanks,
-chris

Re: [stable] Re: Linux 2.6.14.1

[Andrew Walrond]

On Wednesday 09 November 2005 06:04, Chris Wright wrote:
>
> Yes, it's queued, will be part of .2 review cycle.
>

Can we have it soon? I was suprised that 2.6.14 was tagged without a fix; I'm 
frankly amazed its not it 2.6.14.1

Bind is, well, rather important to quite a lot of us ;)

Andrew Walrond

Re: [stable] Re: Linux 2.6.14.1

[Chris Wright]

* Andrew Walrond (andrew@walrond.org) wrote:
> Can we have it soon?

Yes.

Re: [stable] Re: Linux 2.6.14.1

[Greg KH]

On Wed, Nov 09, 2005 at 11:57:05AM +0000, Andrew Walrond wrote:
> On Wednesday 09 November 2005 06:04, Chris Wright wrote:
> >
> > Yes, it's queued, will be part of .2 review cycle.
> >
> 
> Can we have it soon?

It will start up in a few hours...

> I was suprised that 2.6.14 was tagged without a fix; I'm frankly
> amazed its not it 2.6.14.1

Sorry, but no one prodded the -stable team to get to this sooner (yeah,
Andrew did mention it in passing to me a week ago, but then I forgot
about it, sorry...)

> Bind is, well, rather important to quite a lot of us ;)

I agree, sorry for the delay.  If you ever think we need to cut a new
release because of something like this, please let us know.

thanks,

greg k-h

Re: [stable] Re: Linux 2.6.14.1

[Andrew Walrond]

On Wednesday 09 November 2005 17:15, Greg KH wrote:
>
> I agree, sorry for the delay.  If you ever think we need to cut a new
> release because of something like this, please let us know.
>

Me? Poke the gods with a stick? Sounds like a recipe for thunderbolts ;)

Great work (the -stable team) BTW. Moving from a -stable kernel to the next 
2.6.x release is quite unsettling (no offense, Linus); I start breathing 
again when .1 arrives.

Andrew Walrond

Re: Linux 2.6.14.1

[Bill Davidsen]

Andrew Morton wrote:
> Greg KH <gregkh@suse.de> wrote:
> 
>>We (the -stable team) are announcing the release of the 2.6.14.1 kernel.
> 
> 
> We need the fix for the net-drops-zero-length-udp-messages bug which broke
> bind and traceroute.

Yes, particularly since there's a security issue, people might not have 
found the patch to get their bind working and be holding off upgrade 
because of that.
-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me