Re: Linux 2.6.14.1
Greg KH
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)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH
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
Coywolf Qi Hunt
> 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/
Greg KH
> 2005/11/9, Greg KH <gre...@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
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?
Chris Wright
> [....]
> > 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
Greg KH
> [....]
> > 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
Ernst Herzberg
[...]
> 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
Coywolf Qi Hunt
> On Wed, Nov 09, 2005 at 10:05:43AM +0800, Coywolf Qi Hunt wrote:
> > 2005/11/9, Greg KH <gre...@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/
Andrew Morton
>
> 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-...@vger.kernel.org>
To: git-comm...@vger.kernel.org
Subject: [NET]: Fix zero-size datagram reception
tree ee282f7fd6e465d7b031d64b9ed7c03233ea94cf
parent c2da8acaf488b8651edfb04ebf3ab089f3a7830f
author Herbert Xu <her...@gondor.apana.org.au> Wed, 02 Nov 2005 18:55:00 +1100
committer Arnaldo Carvalho de Melo <ac...@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 <her...@gondor.apana.org.au>
Signed-off-by: Arnaldo Carvalho de Melo <ac...@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
David S. Miller
Date: Tue, 8 Nov 2005 21:13:54 -0800
> Greg KH <gre...@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
sta...@kernel.org even.
In any event, yes please put that in.
Chris Wright
> From: Andrew Morton <ak...@osdl.org>
> Date: Tue, 8 Nov 2005 21:13:54 -0800
>
> > Greg KH <gre...@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
> sta...@kernel.org even.
>
> In any event, yes please put that in.
Yes, it's queued, will be part of .2 review cycle.
thanks,
-chris
Andrew Walrond
>
> 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
Chris Wright
Greg KH
> 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
Andrew Walrond
>
> 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
Bill Davidsen
> Greg KH <gre...@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 (davi...@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me