From: Jeff King Date: Sat, 17 Nov 2007 09:06:34 GMT Subject: Re: Fwd: [postmaster@vger.kernel.org: Delivery reports about your email [FAILED(1)]] Message-ID: <20071117090634.GA22352@sigill.intra.peff.net> In-Reply-To: <20071116183530.GI6372@mea-ext.zmailer.org> On Fri, Nov 16, 2007 at 08:35:30PM +0200, Matti Aarnio wrote: > Here is a sample message that NEEDS proper charset mime tags. Thank you for posting a complete example. However, I'm not sure that git is to blame here. The problem text seems to be "Ilpo J�rvinen ". However, that text seems to be included in a regular mail sent by gregkh. I see no evidence of git-send-email being used (neither an X-Mailer, nor any message-id which would have been generated by it). It looks like the culprit is whatever he is using to generate the stable-commit response. I'll note a few things below (sorry, the quoting is long, but I don't want to omit any details): > Following is copy of the message headers. Original message content may > be in subsequent parts of this MESSAGE/DELIVERY-STATUS structure. > > Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand > id S1751399AbXKPSJk; Fri, 16 Nov 2007 13:09:40 -0500 > Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756649AbXKPSJk > (ORCPT ); > Fri, 16 Nov 2007 13:09:40 -0500 > Received: from ns2.suse.de ([195.135.220.15]:33829 "EHLO mx2.suse.de" > rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP > id S1751399AbXKPSJj (ORCPT ); > Fri, 16 Nov 2007 13:09:39 -0500 > Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) > (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) > (No client certificate requested) > by mx2.suse.de (Postfix) with ESMTP id 142E02BDB9; > Fri, 16 Nov 2007 19:09:38 +0100 (CET) > Subject: patch tcp-make-sure-write_queue_from-does-not-begin-with-null-ptr.patch queued to -stable tree > To: ilpo.jarvinen@helsinki.fi, davem@davemloft.net > Cc: , > From: > Date: Fri, 16 Nov 2007 10:08:58 -0800 > Message-Id: <20071116180937.250A0144AB0C@imap.suse.de> > Sender: stable-commits-owner@vger.kernel.org > Precedence: bulk > Reply-To: linux-kernel@vger.kernel.org > X-Mailing-List: stable-commits@vger.kernel.org This is presumably the complete header for the rejected message. I agree this ought to have a content-type header, but it clearly wasn't sent by git-send-email. Presumably there is some post-receive hook that is doing this, but it's hard to say more without seeing the hook. > Reporting-MTA: dns; vger.kernel.org > Arrival-Date: Fri, 16 Nov 2007 13:09:40 -0500 > Local-Spool-ID: S1751399AbXKPSJk > > Original-Recipient: rfc822;jfunk@funktronics.ca > Final-Recipient: RFC822;jfunk@funktronics.ca > Action: failed > Status: 5.1.1 (bad destination mailbox) > Remote-MTA: dns; elseed.funktronics.ca (65.61.206.36|25|209.132.176.167|48741) > Last-Attempt-Date: Fri, 16 Nov 2007 13:10:02 -0500 > Diagnostic-Code: smtp; 550 (Error: improper use of 8-bit data in message body) > Date: Fri, 16 Nov 2007 10:08:58 -0800 > From: gregkh@suse.de > To: ilpo.jarvinen@helsinki.fi, davem@davemloft.net > Cc: stable@kernel.org, stable-commits@vger.kernel.org > Reply-To: linux-kernel@vger.kernel.org > Subject: patch > tcp-make-sure-write_queue_from-does-not-begin-with-null-ptr.patch > queued to -stable tree > > > This is a note to let you know that we have just queued up the patch titled > > Subject: TCP: Make sure write_queue_from does not begin with NULL ptr (CVE-2007-5501) > > to the 2.6.23-stable tree. Its filename is > > tcp-make-sure-write_queue_from-does-not-begin-with-null-ptr.patch > > A git repo of this tree can be found at > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > > > >From 96a2d41a3e495734b63bff4e5dd0112741b93b38 Mon Sep 17 00:00:00 2001 > From: Ilpo J�rvinen > Date: Wed, 14 Nov 2007 15:47:18 -0800 > Subject: TCP: Make sure write_queue_from does not begin with NULL ptr (CVE-2007-5501) > > From: Ilpo J�rvinen And this is clearly generated by git-format-patch. The signed-off-by requires a charset specifier. This was fixed by Junio in 4593fb84 about 2 weeks ago, but hasn't made it into a released version yet. The extra 'From' line in the body of the email is not something generated by git-format-patch. Usually such lines are placed by git-send-email, and would require encoding; we just queued a fix for that yesterday. However, I don't see any other evidence of git-send-email being used here, so it looks more like whatever script generated the outer mail just called git-format-patch. > patch 96a2d41a3e495734b63bff4e5dd0112741b93b38 in mainline. > > NULL ptr can be returned from tcp_write_queue_head to cached_skb > and then assigned to skb if packets_out was zero. Without this, > system is vulnerable to a carefully crafted ACKs which obviously > is remotely triggerable. > > Besides, there's very little that needs to be done in sacktag > if there weren't any packets outstanding, just skipping the rest > doesn't hurt. > > Signed-off-by: Ilpo J�rvinen > Signed-off-by: David S. Miller > > --- > net/ipv4/tcp_input.c | 5 +++++ > 1 file changed, 5 insertions(+) > > --- a/net/ipv4/tcp_input.c > +++ b/net/ipv4/tcp_input.c > @@ -1012,6 +1012,9 @@ tcp_sacktag_write_queue(struct sock *sk, > if (before(TCP_SKB_CB(ack_skb)->ack_seq, prior_snd_una - tp->max_window)) > return 0; > > + if (!tp->packets_out) > + goto out; > + > /* SACK fastpath: > * if the only SACK change is the increase of the end_seq of > * the first block then only apply that SACK block > @@ -1280,6 +1283,8 @@ tcp_sacktag_write_queue(struct sock *sk, > (!tp->frto_highmark || after(tp->snd_una, tp->frto_highmark))) > tcp_update_reordering(sk, ((tp->fackets_out + 1) - reord), 0); > > +out: > + > #if FASTRETRANS_DEBUG > 0 > BUG_TRAP((int)tp->sacked_out >= 0); > BUG_TRAP((int)tp->lost_out >= 0); > > > Patches currently in stable-queue which might be from ilpo.jarvinen@helsinki.fi are > > queue-2.6.23/tcp-make-sure-write_queue_from-does-not-begin-with-null-ptr.patch > - > To unsubscribe from this list: send the line "unsubscribe stable-commits" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html