[patch 0/6] 2.6.14.7 -stable review

[patch 0/6] 2.6.14.7 -stable review

[Greg KH]

This is the start of the stable review cycle for the 2.6.14.7 release.
There are 6 patches in this series, all will be posted as a response to
this one.  If anyone has any issues with these being applied, please let
us know.  If anyone is a maintainer of the proper subsystem, and wants
to add a signed-off-by: line to the patch, please respond with it.

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

Responses should be made by Monday, January 30, 00:00:00 UTC.  Anything
received after that time, might be too late.

thanks,

the -stable release team

[patch 1/6] setting irq affinity is broken in ia32 with MSI enabled

[Greg KH]

[-- Attachment #1: setting-irq-affinity-is-broken-in-ia32-with-MSI-enabled.patch --]
[-- Type: text/plain, Size: 1167 bytes --]

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

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

From: Shaohua Li <shaohua.li@intel.com>

Setting irq affinity stops working when MSI is enabled.  With MSI, move_irq
is empty, so we can't change irq affinity.  It appears a typo in Ashok's
original commit for this issue.  X86_64 actually is using move_native_irq.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/i386/kernel/io_apic.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.14.6.orig/arch/i386/kernel/io_apic.c
+++ linux-2.6.14.6/arch/i386/kernel/io_apic.c
@@ -1937,7 +1937,7 @@ static void ack_edge_ioapic_vector(unsig
 {
 	int irq = vector_to_irq(vector);
 
-	move_irq(vector);
+	move_native_irq(vector);
 	ack_edge_ioapic_irq(irq);
 }
 
@@ -1952,7 +1952,7 @@ static void end_level_ioapic_vector (uns
 {
 	int irq = vector_to_irq(vector);
 
-	move_irq(vector);
+	move_native_irq(vector);
 	end_level_ioapic_irq(irq);
 }
 

--

[patch 2/6] [EBTABLES] Don't match tcp/udp source/destination port for IP fragments

[Greg KH]

[-- Attachment #1: fix-bridge-netfilter-matching-ip-fragments.patch --]
[-- Type: text/plain, Size: 1065 bytes --]

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

------------------
From: Bart De Schuymer <bdschuym@pandora.be>

Signed-off-by: Bart De Schuymer <bdschuym@pandora.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/bridge/netfilter/ebt_ip.c |    3 +++
 1 file changed, 3 insertions(+)

--- linux-2.6.14.6.orig/net/bridge/netfilter/ebt_ip.c
+++ linux-2.6.14.6/net/bridge/netfilter/ebt_ip.c
@@ -15,6 +15,7 @@
 #include <linux/netfilter_bridge/ebtables.h>
 #include <linux/netfilter_bridge/ebt_ip.h>
 #include <linux/ip.h>
+#include <net/ip.h>
 #include <linux/in.h>
 #include <linux/module.h>
 
@@ -51,6 +52,8 @@ static int ebt_filter_ip(const struct sk
 		if (!(info->bitmask & EBT_IP_DPORT) &&
 		    !(info->bitmask & EBT_IP_SPORT))
 			return EBT_MATCH;
+		if (ntohs(ih->frag_off) & IP_OFFSET)
+			return EBT_NOMATCH;
 		pptr = skb_header_pointer(skb, ih->ihl*4,
 					  sizeof(_ports), &_ports);
 		if (pptr == NULL)

--

[patch 3/6] [SPARC64]: Fix ptrace/strace

[Greg KH]

[-- Attachment #1: sparc64-fix-ptrace.patch --]
[-- Type: text/plain, Size: 1392 bytes --]

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

------------------
From: Richard Mortimer <richm@oldelvet.org.uk>

Don't clobber register %l0 while checking TI_SYS_NOERROR value in
syscall return path.  This bug was introduced by:

db7d9a4eb700be766cc9f29241483dbb1e748832

Problem narrowed down by Luis F. Ortiz and Richard Mortimer.

I tried using %l2 as suggested by Luis and that works for me.

Looking at the code I wonder if it makes sense to simplify the code
a little bit. The following works for me but I'm not sure how to
exercise the "NOERROR" codepath.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/sparc64/kernel/entry.S |    7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

--- linux-2.6.14.6.orig/arch/sparc64/kernel/entry.S
+++ linux-2.6.14.6/arch/sparc64/kernel/entry.S
@@ -1657,13 +1657,10 @@ ret_sys_call:
 	/* Check if force_successful_syscall_return()
 	 * was invoked.
 	 */
-	ldub		[%curptr + TI_SYS_NOERROR], %l0
-	brz,pt		%l0, 1f
-	 nop
-	ba,pt		%xcc, 80f
+	ldub            [%curptr + TI_SYS_NOERROR], %l2
+	brnz,a,pn       %l2, 80f
 	 stb		%g0, [%curptr + TI_SYS_NOERROR]
 
-1:
 	cmp		%o0, -ERESTART_RESTARTBLOCK
 	bgeu,pn		%xcc, 1f
 	 andcc		%l0, (_TIF_SYSCALL_TRACE|_TIF_SECCOMP|_TIF_SYSCALL_AUDIT), %l6

--

[patch 4/6] [SPARC64]: Fix sys_fstat64() entry in 64-bit syscall table.

[Greg KH]

[-- Attachment #1: sparc64-fix-sys_fstat64-entry-in-64-bit-syscall-table.patch --]
[-- Type: text/plain, Size: 1179 bytes --]


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

------------------
From: "David S. Miller" <davem@davemloft.net>

Noticed by Jakub Jelinek.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/sparc64/kernel/systbls.S |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.14.6.orig/arch/sparc64/kernel/systbls.S
+++ linux-2.6.14.6/arch/sparc64/kernel/systbls.S
@@ -98,7 +98,7 @@ sys_call_table:
 	.word sys_umount, sys_setgid, sys_getgid, sys_signal, sys_geteuid
 /*50*/	.word sys_getegid, sys_acct, sys_memory_ordering, sys_nis_syscall, sys_ioctl
 	.word sys_reboot, sys_nis_syscall, sys_symlink, sys_readlink, sys_execve
-/*60*/	.word sys_umask, sys_chroot, sys_newfstat, sys_stat64, sys_getpagesize
+/*60*/	.word sys_umask, sys_chroot, sys_newfstat, sys_fstat64, sys_getpagesize
 	.word sys_msync, sys_vfork, sys_pread64, sys_pwrite64, sys_nis_syscall
 /*70*/	.word sys_nis_syscall, sys_mmap, sys_nis_syscall, sys64_munmap, sys_mprotect
 	.word sys_madvise, sys_vhangup, sys_nis_syscall, sys_mincore, sys_getgroups

--

[patch 5/6] [NETFILTER]: Fix crash in ip_nat_pptp (CVE-2006-0036)

[Greg KH]

[-- Attachment #1: netfilter-fix-crash-in-ip_nat_pptp.patch --]
[-- Type: text/plain, Size: 1004 bytes --]

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

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

From: Patrick McHardy <kaber@trash.net>

When an inbound PPTP_IN_CALL_REQUEST packet is received the
PPTP NAT helper uses a NULL pointer in pointer arithmentic to
calculate the offset in the packet which needs to be mangled
and corrupts random memory or crashes.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/ipv4/netfilter/ip_nat_helper_pptp.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.14.6.orig/net/ipv4/netfilter/ip_nat_helper_pptp.c
+++ linux-2.6.14.6/net/ipv4/netfilter/ip_nat_helper_pptp.c
@@ -313,7 +313,7 @@ pptp_inbound_pkt(struct sk_buff **pskb,
 		break;
 	case PPTP_IN_CALL_REQUEST:
 		/* only need to nat in case PAC is behind NAT box */
-		break;
+		return NF_ACCEPT;
 	case PPTP_WAN_ERROR_NOTIFY:
 		pcid = &pptpReq->wanerr.peersCallID;
 		break;

--

[patch 6/6] [NETFILTER]: Fix another crash in ip_nat_pptp (CVE-2006-0037)

[Greg KH]

[-- Attachment #1: netfilter-fix-another-crash-in-ip_nat_pptp.patch --]
[-- Type: text/plain, Size: 5633 bytes --]

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

------------------
From: Patrick McHardy <kaber@trash.net>

The PPTP NAT helper calculates the offset at which the packet needs
to be mangled as difference between two pointers to the header. With
non-linear skbs however the pointers may point to two seperate buffers
on the stack and the calculation results in a wrong offset beeing
used.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/ipv4/netfilter/ip_nat_helper_pptp.c |   57 +++++++++++++++-----------------
 1 file changed, 27 insertions(+), 30 deletions(-)

--- linux-2.6.14.6.orig/net/ipv4/netfilter/ip_nat_helper_pptp.c
+++ linux-2.6.14.6/net/ipv4/netfilter/ip_nat_helper_pptp.c
@@ -148,14 +148,14 @@ pptp_outbound_pkt(struct sk_buff **pskb,
 {
 	struct ip_ct_pptp_master *ct_pptp_info = &ct->help.ct_pptp_info;
 	struct ip_nat_pptp *nat_pptp_info = &ct->nat.help.nat_pptp_info;
-
-	u_int16_t msg, *cid = NULL, new_callid;
+	u_int16_t msg, new_callid;
+	unsigned int cid_off;
 
 	new_callid = htons(ct_pptp_info->pns_call_id);
 	
 	switch (msg = ntohs(ctlh->messageType)) {
 		case PPTP_OUT_CALL_REQUEST:
-			cid = &pptpReq->ocreq.callID;
+			cid_off = offsetof(union pptp_ctrl_union, ocreq.callID);
 			/* FIXME: ideally we would want to reserve a call ID
 			 * here.  current netfilter NAT core is not able to do
 			 * this :( For now we use TCP source port. This breaks
@@ -172,10 +172,10 @@ pptp_outbound_pkt(struct sk_buff **pskb,
 			ct_pptp_info->pns_call_id = ntohs(new_callid);
 			break;
 		case PPTP_IN_CALL_REPLY:
-			cid = &pptpReq->icreq.callID;
+			cid_off = offsetof(union pptp_ctrl_union, icreq.callID);
 			break;
 		case PPTP_CALL_CLEAR_REQUEST:
-			cid = &pptpReq->clrreq.callID;
+			cid_off = offsetof(union pptp_ctrl_union, clrreq.callID);
 			break;
 		default:
 			DEBUGP("unknown outbound packet 0x%04x:%s\n", msg,
@@ -197,18 +197,15 @@ pptp_outbound_pkt(struct sk_buff **pskb,
 
 	/* only OUT_CALL_REQUEST, IN_CALL_REPLY, CALL_CLEAR_REQUEST pass
 	 * down to here */
-
-	IP_NF_ASSERT(cid);
-
 	DEBUGP("altering call id from 0x%04x to 0x%04x\n",
-		ntohs(*cid), ntohs(new_callid));
+		ntohs(*(u_int16_t *)pptpReq + cid_off), ntohs(new_callid));
 
 	/* mangle packet */
 	if (ip_nat_mangle_tcp_packet(pskb, ct, ctinfo,
-		(void *)cid - ((void *)ctlh - sizeof(struct pptp_pkt_hdr)),
-				 	sizeof(new_callid), 
-					(char *)&new_callid,
-				 	sizeof(new_callid)) == 0)
+	                             cid_off + sizeof(struct pptp_pkt_hdr) +
+	                             sizeof(struct PptpControlHeader),
+	                             sizeof(new_callid), (char *)&new_callid,
+	                             sizeof(new_callid)) == 0)
 		return NF_DROP;
 
 	return NF_ACCEPT;
@@ -297,7 +294,8 @@ pptp_inbound_pkt(struct sk_buff **pskb,
 		 union pptp_ctrl_union *pptpReq)
 {
 	struct ip_nat_pptp *nat_pptp_info = &ct->nat.help.nat_pptp_info;
-	u_int16_t msg, new_cid = 0, new_pcid, *pcid = NULL, *cid = NULL;
+	u_int16_t msg, new_cid = 0, new_pcid;
+	unsigned int pcid_off, cid_off = 0;
 
 	int ret = NF_ACCEPT, rv;
 
@@ -305,23 +303,23 @@ pptp_inbound_pkt(struct sk_buff **pskb,
 
 	switch (msg = ntohs(ctlh->messageType)) {
 	case PPTP_OUT_CALL_REPLY:
-		pcid = &pptpReq->ocack.peersCallID;	
-		cid = &pptpReq->ocack.callID;
+		pcid_off = offsetof(union pptp_ctrl_union, ocack.peersCallID);
+		cid_off = offsetof(union pptp_ctrl_union, ocack.callID);
 		break;
 	case PPTP_IN_CALL_CONNECT:
-		pcid = &pptpReq->iccon.peersCallID;
+		pcid_off = offsetof(union pptp_ctrl_union, iccon.peersCallID);
 		break;
 	case PPTP_IN_CALL_REQUEST:
 		/* only need to nat in case PAC is behind NAT box */
 		return NF_ACCEPT;
 	case PPTP_WAN_ERROR_NOTIFY:
-		pcid = &pptpReq->wanerr.peersCallID;
+		pcid_off = offsetof(union pptp_ctrl_union, wanerr.peersCallID);
 		break;
 	case PPTP_CALL_DISCONNECT_NOTIFY:
-		pcid = &pptpReq->disc.callID;
+		pcid_off = offsetof(union pptp_ctrl_union, disc.callID);
 		break;
 	case PPTP_SET_LINK_INFO:
-		pcid = &pptpReq->setlink.peersCallID;
+		pcid_off = offsetof(union pptp_ctrl_union, setlink.peersCallID);
 		break;
 
 	default:
@@ -343,25 +341,24 @@ pptp_inbound_pkt(struct sk_buff **pskb,
 	 * WAN_ERROR_NOTIFY, CALL_DISCONNECT_NOTIFY pass down here */
 
 	/* mangle packet */
-	IP_NF_ASSERT(pcid);
 	DEBUGP("altering peer call id from 0x%04x to 0x%04x\n",
-		ntohs(*pcid), ntohs(new_pcid));
+		ntohs(*(u_int16_t *)pptpReq + pcid_off), ntohs(new_pcid));
 	
-	rv = ip_nat_mangle_tcp_packet(pskb, ct, ctinfo, 
-				      (void *)pcid - ((void *)ctlh - sizeof(struct pptp_pkt_hdr)),
+	rv = ip_nat_mangle_tcp_packet(pskb, ct, ctinfo,
+	                              pcid_off + sizeof(struct pptp_pkt_hdr) +
+				      sizeof(struct PptpControlHeader),
 				      sizeof(new_pcid), (char *)&new_pcid, 
 				      sizeof(new_pcid));
 	if (rv != NF_ACCEPT) 
 		return rv;
 
 	if (new_cid) {
-		IP_NF_ASSERT(cid);
 		DEBUGP("altering call id from 0x%04x to 0x%04x\n",
-			ntohs(*cid), ntohs(new_cid));
-		rv = ip_nat_mangle_tcp_packet(pskb, ct, ctinfo, 
-					      (void *)cid - ((void *)ctlh - sizeof(struct pptp_pkt_hdr)), 
-					      sizeof(new_cid),
-					      (char *)&new_cid, 
+			ntohs(*(u_int16_t *)pptpReq + cid_off), ntohs(new_cid));
+		rv = ip_nat_mangle_tcp_packet(pskb, ct, ctinfo,
+		                              cid_off + sizeof(struct pptp_pkt_hdr) +
+					      sizeof(struct PptpControlHeader),
+					      sizeof(new_cid), (char *)&new_cid,
 					      sizeof(new_cid));
 		if (rv != NF_ACCEPT)
 			return rv;

--

Re: [patch 0/6] 2.6.14.7 -stable review

[Chuck Wolber]

On Fri, 27 Jan 2006, Greg KH wrote:

> This is the start of the stable review cycle for the 2.6.14.7 release. 
> There are 6 patches in this series, all will be posted as a response to 
> this one.  If anyone has any issues with these being applied, please let 
> us know.  If anyone is a maintainer of the proper subsystem, and wants 
> to add a signed-off-by: line to the patch, please respond with it.

Please correct me if I'm wrong here, but aren't we supposed to stop doing 
this for the 2.6.14 release now that 2.6.15 is out?

..Chuck..


-- 
http://www.quantumlinux.com
 Quantum Linux Laboratories, LLC.
 ACCELERATING Business with Open Technology

 "The measure of the restoration lies in the extent to which we apply
  social values more noble than mere monetary profit." - FDR

Re: [patch 0/6] 2.6.14.7 -stable review

[Justin M. Forbes]

On Sat, Jan 28, 2006 at 08:30:25PM -0800, Chuck Wolber wrote:
> 
> Please correct me if I'm wrong here, but aren't we supposed to stop doing 
> this for the 2.6.14 release now that 2.6.15 is out?
> 
I don't see a problems with doing additional stable releases for any
kernel, I just wouldn't commit to supporting any specific number of
releases.  Basically if people send enough patches to warrant a
review/release there is obviously some interest.  What is the harm?

Justin

Re: [patch 0/6] 2.6.14.7 -stable review

[Randy.Dunlap]

On Sat, 28 Jan 2006 20:30:25 -0800 (PST) Chuck Wolber wrote:

> On Fri, 27 Jan 2006, Greg KH wrote:
> 
> > This is the start of the stable review cycle for the 2.6.14.7 release. 
> > There are 6 patches in this series, all will be posted as a response to 
> > this one.  If anyone has any issues with these being applied, please let 
> > us know.  If anyone is a maintainer of the proper subsystem, and wants 
> > to add a signed-off-by: line to the patch, please respond with it.
> 
> Please correct me if I'm wrong here, but aren't we supposed to stop doing 
> this for the 2.6.14 release now that 2.6.15 is out?

Some people wanted more -stable so the stable team agreed
to do a little more.  Is it a problem?

---
~Randy

Re: [patch 0/6] 2.6.14.7 -stable review

[Chuck Wolber]

On Sat, 28 Jan 2006, Justin M. Forbes wrote:

> On Sat, Jan 28, 2006 at 08:30:25PM -0800, Chuck Wolber wrote:
> > 
> > Please correct me if I'm wrong here, but aren't we supposed to stop doing 
> > this for the 2.6.14 release now that 2.6.15 is out?
>
> I don't see a problems with doing additional stable releases for any 
> kernel, I just wouldn't commit to supporting any specific number of 
> releases.  Basically if people send enough patches to warrant a 
> review/release there is obviously some interest.  What is the harm?

The harm is that stable release patches will eventually start being 
maintained and we'll have to add another stable release "dot" to the end 
of the growing width of the release version moniker. This stable branch 
was meant only for "one-off" fixes to a stable release, not for adding 
fixes upon fixes upon fixes that eventually turn into features that have 
to be maintained. A new stable release means we change our focus to it and 
ignore the old stable release.

..Chuck..

-- 
http://www.quantumlinux.com
 Quantum Linux Laboratories, LLC.
 ACCELERATING Business with Open Technology

 "The measure of the restoration lies in the extent to which we apply
  social values more noble than mere monetary profit." - FDR

Re: [patch 0/6] 2.6.14.7 -stable review

[Randy.Dunlap]

On Sat, 28 Jan 2006 20:52:46 -0800 (PST) Chuck Wolber wrote:

> On Sat, 28 Jan 2006, Justin M. Forbes wrote:
> 
> > On Sat, Jan 28, 2006 at 08:30:25PM -0800, Chuck Wolber wrote:
> > > 
> > > Please correct me if I'm wrong here, but aren't we supposed to stop doing 
> > > this for the 2.6.14 release now that 2.6.15 is out?
> >
> > I don't see a problems with doing additional stable releases for any 
> > kernel, I just wouldn't commit to supporting any specific number of 
> > releases.  Basically if people send enough patches to warrant a 
> > review/release there is obviously some interest.  What is the harm?
> 
> The harm is that stable release patches will eventually start being 
> maintained and we'll have to add another stable release "dot" to the end 
> of the growing width of the release version moniker. This stable branch 
> was meant only for "one-off" fixes to a stable release, not for adding 
> fixes upon fixes upon fixes that eventually turn into features that have 
> to be maintained. A new stable release means we change our focus to it and 
> ignore the old stable release.

It's a 6-month sliding window for stable releases IIRC.
Maybe <stable@kernel.org> can add something like that to
Documentation/stable_kernel_rules.txt>.

---
~Randy

Re: [patch 0/6] 2.6.14.7 -stable review

[Chuck Wolber]

On Sat, 28 Jan 2006, Randy.Dunlap wrote:

> On Sat, 28 Jan 2006 20:30:25 -0800 (PST) Chuck Wolber wrote:
> 
> > On Fri, 27 Jan 2006, Greg KH wrote:
> > 
> > > This is the start of the stable review cycle for the 2.6.14.7 
> > > release. There are 6 patches in this series, all will be posted as a 
> > > response to this one.  If anyone has any issues with these being 
> > > applied, please let us know.  If anyone is a maintainer of the 
> > > proper subsystem, and wants to add a signed-off-by: line to the 
> > > patch, please respond with it.
> > 
> > Please correct me if I'm wrong here, but aren't we supposed to stop 
> > doing this for the 2.6.14 release now that 2.6.15 is out?
> 
> Some people wanted more -stable so the stable team agreed to do a little 
> more.  Is it a problem?


I don't know if there is a problem, but it goes against the concept of 
"one-off" fixes that aren't maintained (aka the purpose of the -stable 
team). This slope eventually leads us to backporting -stable fixes from 
other -stable releases etc etc. 

If there's one thing I've learned from watching guys like Alan Cox 
maintain stable releases, it's that they're profoundly good at saying 
"no". I'm not saying that's warranted here, I'm just trying to encourage 
the dialog (I suspect that I've missed part of the conversation as I am 
not currently subscribed to LKML).

..Chuck..


-- 
http://www.quantumlinux.com
 Quantum Linux Laboratories, LLC.
 ACCELERATING Business with Open Technology

 "The measure of the restoration lies in the extent to which we apply
  social values more noble than mere monetary profit." - FDR

Re: [patch 0/6] 2.6.14.7 -stable review

[Greg KH]

On Sat, Jan 28, 2006 at 08:57:01PM -0800, Randy.Dunlap wrote:
> On Sat, 28 Jan 2006 20:52:46 -0800 (PST) Chuck Wolber wrote:
> 
> > On Sat, 28 Jan 2006, Justin M. Forbes wrote:
> > 
> > > On Sat, Jan 28, 2006 at 08:30:25PM -0800, Chuck Wolber wrote:
> > > > 
> > > > Please correct me if I'm wrong here, but aren't we supposed to stop doing 
> > > > this for the 2.6.14 release now that 2.6.15 is out?
> > >
> > > I don't see a problems with doing additional stable releases for any 
> > > kernel, I just wouldn't commit to supporting any specific number of 
> > > releases.  Basically if people send enough patches to warrant a 
> > > review/release there is obviously some interest.  What is the harm?
> > 
> > The harm is that stable release patches will eventually start being 
> > maintained and we'll have to add another stable release "dot" to the end 
> > of the growing width of the release version moniker. This stable branch 
> > was meant only for "one-off" fixes to a stable release, not for adding 
> > fixes upon fixes upon fixes that eventually turn into features that have 
> > to be maintained. A new stable release means we change our focus to it and 
> > ignore the old stable release.
> 
> It's a 6-month sliding window for stable releases IIRC.
> Maybe <stable@kernel.org> can add something like that to
> Documentation/stable_kernel_rules.txt>.

No, it's not a 6 month window, I released this because people sent us
patches that they said should go into the 2.6.14-stable tree.  And as
people complained so much on lkml that we were dropping the old kernels
too fast, I never thought that people would complain that we are
maintaining older stuff that people seem interested in...

And, odds are, it will probably be the last 2.6.14 stable kernel we (the
stable team) release, unless something unusual happens...

And, as always, anyone is free to take on maintaining any of the
different kernel versions for as long as they wish.

Does that help?

Man, people complain when you don't maintain older kernels, and they
complain when you do...

thanks,

greg k-h

Re: [patch 0/6] 2.6.14.7 -stable review

[Willy Tarreau]

On Sat, Jan 28, 2006 at 09:34:58PM -0800, Greg KH wrote:
> On Sat, Jan 28, 2006 at 08:57:01PM -0800, Randy.Dunlap wrote:
> > On Sat, 28 Jan 2006 20:52:46 -0800 (PST) Chuck Wolber wrote:
> > 
> > > On Sat, 28 Jan 2006, Justin M. Forbes wrote:
> > > 
> > > > On Sat, Jan 28, 2006 at 08:30:25PM -0800, Chuck Wolber wrote:
> > > > > 
> > > > > Please correct me if I'm wrong here, but aren't we supposed to stop doing 
> > > > > this for the 2.6.14 release now that 2.6.15 is out?
> > > >
> > > > I don't see a problems with doing additional stable releases for any 
> > > > kernel, I just wouldn't commit to supporting any specific number of 
> > > > releases.  Basically if people send enough patches to warrant a 
> > > > review/release there is obviously some interest.  What is the harm?
> > > 
> > > The harm is that stable release patches will eventually start being 
> > > maintained and we'll have to add another stable release "dot" to the end 
> > > of the growing width of the release version moniker. This stable branch 
> > > was meant only for "one-off" fixes to a stable release, not for adding 
> > > fixes upon fixes upon fixes that eventually turn into features that have 
> > > to be maintained. A new stable release means we change our focus to it and 
> > > ignore the old stable release.
> > 
> > It's a 6-month sliding window for stable releases IIRC.
> > Maybe <stable@kernel.org> can add something like that to
> > Documentation/stable_kernel_rules.txt>.
> 
> No, it's not a 6 month window, I released this because people sent us
> patches that they said should go into the 2.6.14-stable tree.  And as
> people complained so much on lkml that we were dropping the old kernels
> too fast, I never thought that people would complain that we are
> maintaining older stuff that people seem interested in...
> 
> And, odds are, it will probably be the last 2.6.14 stable kernel we (the
> stable team) release, unless something unusual happens...
> 
> And, as always, anyone is free to take on maintaining any of the
> different kernel versions for as long as they wish.
> 
> Does that help?
> 
> Man, people complain when you don't maintain older kernels, and they
> complain when you do...

Greg, there will always be stupid people who don't understand the work
of others. These are the same type of people who won't understand at all
why there's a -stable branch. When I started 2.4-hf, I've been told
"you're dumb, 2.4 is dead". I'm very glad that you take care of people
who cannot easily upgrade to latest version, and I'm sure that a lot of
users are too.

> thanks,
> 
> greg k-h

Thanks for keeping up the good work,
Willy

Re: [patch 0/6] 2.6.14.7 -stable review

[Willy Tarreau]

On Sat, Jan 28, 2006 at 09:02:16PM -0800, Chuck Wolber wrote:
> On Sat, 28 Jan 2006, Randy.Dunlap wrote:
> 
> > On Sat, 28 Jan 2006 20:30:25 -0800 (PST) Chuck Wolber wrote:
> > 
> > > On Fri, 27 Jan 2006, Greg KH wrote:
> > > 
> > > > This is the start of the stable review cycle for the 2.6.14.7 
> > > > release. There are 6 patches in this series, all will be posted as a 
> > > > response to this one.  If anyone has any issues with these being 
> > > > applied, please let us know.  If anyone is a maintainer of the 
> > > > proper subsystem, and wants to add a signed-off-by: line to the 
> > > > patch, please respond with it.
> > > 
> > > Please correct me if I'm wrong here, but aren't we supposed to stop 
> > > doing this for the 2.6.14 release now that 2.6.15 is out?
> > 
> > Some people wanted more -stable so the stable team agreed to do a little 
> > more.  Is it a problem?
> 
> 
> I don't know if there is a problem, but it goes against the concept of 
> "one-off" fixes that aren't maintained (aka the purpose of the -stable 
> team). This slope eventually leads us to backporting -stable fixes from 
> other -stable releases etc etc. 

The purpose of -stable is to provide stable kernels to 2.6 users. If time
was not a problem, it's possible that there would be even more versions
supported. The day you will install Linux on a server, you'll understand
why it's problematic for some people to upgrade to latest version to get
fixes. And when you get something that works, you hope to be able to use
it as an alternative to a simple upgrade when the later breaks on your
hardware.

> If there's one thing I've learned from watching guys like Alan Cox 
> maintain stable releases, it's that they're profoundly good at saying 
> "no". I'm not saying that's warranted here, I'm just trying to encourage 
> the dialog (I suspect that I've missed part of the conversation as I am 
> not currently subscribed to LKML).

It's not a matter of saying "yes" or "no", it's a matter of helping
users in getting something which works best on their hardware while
still being reliable and secure. Maintainers propose some solutions
for this, and can adapt to users' demands. I don't see anything wrong
with this.

> ..Chuck..

Willy

Re: [patch 0/6] 2.6.14.7 -stable review

[Chuck Wolber]

On Sat, 28 Jan 2006, Greg KH wrote:

> No, it's not a 6 month window, I released this because people sent us 
> patches that they said should go into the 2.6.14-stable tree.  And as 
> people complained so much on lkml that we were dropping the old kernels 
> too fast, I never thought that people would complain that we are 
> maintaining older stuff that people seem interested in...

Don't think of it as a complaint. I'm sorry if it came off that way. It's 
anyone's job if they want to maintain any kernel release as long as they 
see fit.

I guess it's how we want to define ourselves. Was I mistaken to think that 
the -stable team maintains -stable for the current patch release only? 


> And, as always, anyone is free to take on maintaining any of the 
> different kernel versions for as long as they wish.
> 
> Does that help?

Well, that's the way it's always been. We have a late model 2.5 kernel 
that we still maintain in a level C avionics device on Boeing jets. You'd 
be amazed at how stable a 2.5 kernel can be made ;)


> Man, people complain when you don't maintain older kernels, and they 
> complain when you do...

Nope, wasn't complaining. It was an attempt at a dialog to more clearly 
define our purpose (or perhaps my personal understanding of it) *AND* let 
other developers know what to expect of us. We can choose to take on as 
much or as little as we want. I personally am good with whatever everyone 
else is comfortable taking on. We should manage outside expectations 
though so you don't have to answer "why do you drop old kernels" questions 
on your own. 

Things have changed a lot with the 2.6 release series and -stable seems to 
me to be one of those growing pains that still isn't fully resolved. It's 
a blending between the traditional stable release maintainers and the more 
nimble release schedule these days. Can the -stable team fill the void, or 
do we limit our scope to certain patch releases?

..Chuck..


-- 
http://www.quantumlinux.com
 Quantum Linux Laboratories, LLC.
 ACCELERATING Business with Open Technology

 "The measure of the restoration lies in the extent to which we apply
  social values more noble than mere monetary profit." - FDR

Re: [patch 0/6] 2.6.14.7 -stable review

[Chuck Wolber]

On Sun, 29 Jan 2006, Willy Tarreau wrote:

> Greg, there will always be stupid people who don't understand the work 
> of others.

Hmmm, true, but I wouldn't call them stupid, just a bit ignorant. It's 
incumbent upon us to manage and maintain expectations to fix that problem.


> I'm very glad that you take care of people who cannot easily upgrade to 
> latest version, and I'm sure that a lot of users are too.

Me too. I'd never dream of criticizing Greg's efforts. He's done an 
incredible job. I think better defining -stable will make life easier for 
him and help us be more productive.

..Chuck..


-- 
http://www.quantumlinux.com
 Quantum Linux Laboratories, LLC.
 ACCELERATING Business with Open Technology

 "The measure of the restoration lies in the extent to which we apply
  social values more noble than mere monetary profit." - FDR

Re: [patch 0/6] 2.6.14.7 -stable review

[Chuck Wolber]

On Sun, 29 Jan 2006, Willy Tarreau wrote:

> The purpose of -stable is to provide stable kernels to 2.6 users. If time
> was not a problem, it's possible that there would be even more versions
> supported.

Mmmm, yup. I was there when this whole thing was brewed up ;)


> The day you will install Linux on a server, you'll understand why it's 
> problematic for some people to upgrade to latest version to get fixes.

Sure hope you're not implying I haven't done that before...

 
> It's not a matter of saying "yes" or "no", it's a matter of helping 
> users in getting something which works best on their hardware while 
> still being reliable and secure. Maintainers propose some solutions for 
> this, and can adapt to users' demands. I don't see anything wrong with 
> this.

Neither do I. To a great extent, that void is already filled by distro 
maintainers. 

..Chuck..


-- 
http://www.quantumlinux.com
 Quantum Linux Laboratories, LLC.
 ACCELERATING Business with Open Technology

 "The measure of the restoration lies in the extent to which we apply
  social values more noble than mere monetary profit." - FDR

Re: [patch 0/6] 2.6.14.7 -stable review

[Chuck Wolber]

On Sat, 28 Jan 2006, Justin M. Forbes wrote:

> On Sat, Jan 28, 2006 at 08:30:25PM -0800, Chuck Wolber wrote:
> > 
> > Please correct me if I'm wrong here, but aren't we supposed to stop doing 
> > this for the 2.6.14 release now that 2.6.15 is out?
> 
> I don't see a problems with doing additional stable releases for any 
> kernel, I just wouldn't commit to supporting any specific number of 
> releases.  Basically if people send enough patches to warrant a 
> review/release there is obviously some interest.  What is the harm?

No harm at all, and that settles it for me then. I like the idea of having 
a demand based release system. If no patches arrive, no releases go out.

..Chuck..


-- 
http://www.quantumlinux.com
 Quantum Linux Laboratories, LLC.
 ACCELERATING Business with Open Technology

 "The measure of the restoration lies in the extent to which we apply
  social values more noble than mere monetary profit." - FDR

Re: [patch 0/6] 2.6.14.7 -stable review

[Krzysztof Halasa]

Chuck Wolber <chuckw@quantumlinux.com> writes:

> I don't know if there is a problem, but it goes against the concept of 
> "one-off" fixes that aren't maintained

If they have time for this then great, I can't see any drawbacks.
The early concept was just meant to limit the workload.

> (aka the purpose of the -stable 
> team). This slope eventually leads us to backporting -stable fixes from 
> other -stable releases etc etc.

As long as they can contribute their time it's a win.
-- 
Krzysztof Halasa

Re: [patch 6/6] [NETFILTER]: Fix another crash in ip_nat_pptp (CVE-2006-0037)

[Holger Eitzenberger]

On Fri, Jan 27, 2006 at 06:18:35PM -0800, Greg KH wrote:

>  	DEBUGP("altering call id from 0x%04x to 0x%04x\n",
> -		ntohs(*cid), ntohs(new_callid));
> +		ntohs(*(u_int16_t *)pptpReq + cid_off), ntohs(new_callid));

Note that this fix introduces another bug in the above use DEBUGP
statement, as there is (u_int16_t *) ptr arithmetic used, whereas
cid_off is a byte offset.

A fix for that was send a few weeks ago on netfilter-devel.

/holger

Re: [stable] Re: [patch 6/6] [NETFILTER]: Fix another crash in ip_nat_pptp (CVE-2006-0037)

[Greg KH]

On Wed, Feb 08, 2006 at 01:35:41PM +0100, Holger Eitzenberger wrote:
> On Fri, Jan 27, 2006 at 06:18:35PM -0800, Greg KH wrote:
> 
> >  	DEBUGP("altering call id from 0x%04x to 0x%04x\n",
> > -		ntohs(*cid), ntohs(new_callid));
> > +		ntohs(*(u_int16_t *)pptpReq + cid_off), ntohs(new_callid));
> 
> Note that this fix introduces another bug in the above use DEBUGP
> statement, as there is (u_int16_t *) ptr arithmetic used, whereas
> cid_off is a byte offset.
> 
> A fix for that was send a few weeks ago on netfilter-devel.

Great, care to forward it to stable@kernel.org so we can get it in the
next release?

thanks,

greg k-h

Re: [stable] Re: [patch 6/6] [NETFILTER]: Fix another crash in ip_nat_pptp (CVE-2006-0037)

[Andrew Morton]

Greg KH <greg@kroah.com> wrote:
>
> On Wed, Feb 08, 2006 at 01:35:41PM +0100, Holger Eitzenberger wrote:
> > On Fri, Jan 27, 2006 at 06:18:35PM -0800, Greg KH wrote:
> > 
> > >  	DEBUGP("altering call id from 0x%04x to 0x%04x\n",
> > > -		ntohs(*cid), ntohs(new_callid));
> > > +		ntohs(*(u_int16_t *)pptpReq + cid_off), ntohs(new_callid));
> > 
> > Note that this fix introduces another bug in the above use DEBUGP
> > statement, as there is (u_int16_t *) ptr arithmetic used, whereas
> > cid_off is a byte offset.
> > 
> > A fix for that was send a few weeks ago on netfilter-devel.
> 
> Great, care to forward it to stable@kernel.org so we can get it in the
> next release?
> 

I have a copy of the patch and I'll cc stable@ on it.  Although afaik this
bug just causes wrong debug info to come out, so I don't think it's
terribly important (?)

Re: [stable] Re: [patch 6/6] [NETFILTER]: Fix another crash in ip_nat_pptp (CVE-2006-0037)

[Greg KH]

On Thu, Feb 09, 2006 at 08:57:29PM -0800, Andrew Morton wrote:
> Greg KH <greg@kroah.com> wrote:
> >
> > On Wed, Feb 08, 2006 at 01:35:41PM +0100, Holger Eitzenberger wrote:
> > > On Fri, Jan 27, 2006 at 06:18:35PM -0800, Greg KH wrote:
> > > 
> > > >  	DEBUGP("altering call id from 0x%04x to 0x%04x\n",
> > > > -		ntohs(*cid), ntohs(new_callid));
> > > > +		ntohs(*(u_int16_t *)pptpReq + cid_off), ntohs(new_callid));
> > > 
> > > Note that this fix introduces another bug in the above use DEBUGP
> > > statement, as there is (u_int16_t *) ptr arithmetic used, whereas
> > > cid_off is a byte offset.
> > > 
> > > A fix for that was send a few weeks ago on netfilter-devel.
> > 
> > Great, care to forward it to stable@kernel.org so we can get it in the
> > next release?
> > 
> 
> I have a copy of the patch and I'll cc stable@ on it.  Although afaik this
> bug just causes wrong debug info to come out, so I don't think it's
> terribly important (?)

If that's the only problem with it, no it's not worth adding to -stable.

thanks though.

greg k-h

Re: [stable] Re: [patch 6/6] [NETFILTER]: Fix another crash in ip_nat_pptp (CVE-2006-0037)

[Harald Welte]

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

On Thu, Feb 09, 2006 at 09:08:19PM -0800, Greg KH wrote:
> On Thu, Feb 09, 2006 at 08:57:29PM -0800, Andrew Morton wrote:
> > Greg KH <greg@kroah.com> wrote:
> > >
> > > On Wed, Feb 08, 2006 at 01:35:41PM +0100, Holger Eitzenberger wrote:
> > > > On Fri, Jan 27, 2006 at 06:18:35PM -0800, Greg KH wrote:
> > > > 
> > > > >  	DEBUGP("altering call id from 0x%04x to 0x%04x\n",
> > > > > -		ntohs(*cid), ntohs(new_callid));
> > > > > +		ntohs(*(u_int16_t *)pptpReq + cid_off), ntohs(new_callid));
> > > > 
> > > > Note that this fix introduces another bug in the above use DEBUGP
> > > > statement, as there is (u_int16_t *) ptr arithmetic used, whereas
> > > > cid_off is a byte offset.
> > > > 
> > > > A fix for that was send a few weeks ago on netfilter-devel.
> > > 
> > > Great, care to forward it to stable@kernel.org so we can get it in the
> > > next release?
> > > 
> > 
> > I have a copy of the patch and I'll cc stable@ on it.  Although afaik this
> > bug just causes wrong debug info to come out, so I don't think it's
> > terribly important (?)
> 
> If that's the only problem with it, no it's not worth adding to -stable.

Yes, this patch only fixes code in DEBUG statements.  Debug can only be
enabled at compile time, so I agree it's not a candidate for -stable.

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

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