From: Junio C Hamano <gitster@pobox.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: git@vger.kernel.org, Gaston Gonzalez <gascoar@gmail.com>
Subject: Re: Bug in 'git am' when applying a broken patch
Date: Mon, 01 Jun 2015 11:58:43 -0700 [thread overview]
Message-ID: <xmqqd21f5k7w.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <xmqqwpzn5lht.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Mon, 01 Jun 2015 11:31:10 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> It claims that it has only 2 lines in the hunk, so "git apply"
> parses the hunk that begins at line 660 as such:
>
> @@ -660,2 +660,2 @@ inline struct sk_buff *ieee80211_authentic...
> auth = (struct ieee80211_authentication *)
> skb_put(skb, sizeof(struct ieee80211_authentication));
>
> And then seeing that the next line does not begin with "@@ -", it
> says "OK, the remainder is a cruft after the patch" and discards
> the rest (which it must be capable of, to ignore "-- ", "2.1.4",
> "devel mailing list", etc.)
>
> There is some safety against not finding a correct patch header
> (i.e. "diff --git" line) by detecting a lone "@@ -" while parsing
> the patch stream, but there is no logic implemented to detect this
> kind of breakage in the code.
For this particular case, it is tempting to say "if a hunk does not
have any +/- line, that is clearly bogus", but the breakage could
have been like this, telling Git to remove a line without doing
anything else.
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c b/...
index d2e8b12..0477ba1 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
@@ -660,4 +660,4 @@ inline struct sk_buff *ieee80211_authentication_...
auth = (struct ieee80211_authentication *)
skb_put(skb, sizeof(struct ieee80211_authentication));
- auth->header.frame_ctl = IEEE80211_STYPE_AUTH;
So "a no-op hunk is suspicious" may be a good criterion to make "git
apply" barf and error out, but that alone would not be a foolproof
solution to protect us against a hand-edited patch.
-- >8 --
Subject: apply: reject a hunk that does not do anything
A hunk like this in a hand-edited patch without correctly adjusting
the line counts:
@@ -660,2 +660,2 @@ inline struct sk_buff *ieee80211_authentic...
auth = (struct ieee80211_authentication *)
skb_put(skb, sizeof(struct ieee80211_authentication));
- some old text
+ some new text
--
2.1.0
dev mailing list
at the end of the patch does not have a good way for us to diagnose
it as corrupt patch. We just read two lines and discard the remainder
as cruft, which we must do in order to ignore the e-mail footer.
If the hand-edited hunk header were "@@ -660,3, +660,2", this fix
will not help---we would just remove the old text without adding the
enw one, and treat "+ some new text" and everything after that line
as trailing cruft. So it is dubious that this patch would help very
much in practice, but it is better than nothing ;-)
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/apply.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/builtin/apply.c b/builtin/apply.c
index 146be97..54aba4e 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -1638,6 +1638,9 @@ static int parse_fragment(const char *line, unsigned long size,
}
if (oldlines || newlines)
return -1;
+ if (!deleted && !added)
+ return -1;
+
fragment->leading = leading;
fragment->trailing = trailing;
next prev parent reply other threads:[~2015-06-01 18:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-01 0:17 Bug in 'git am' when applying a broken patch Greg KH
2015-06-01 1:54 ` Greg KH
2015-06-01 12:09 ` Christian Couder
2015-06-01 18:31 ` Junio C Hamano
2015-06-01 18:58 ` Junio C Hamano [this message]
2015-06-01 20:09 ` Eric Sunshine
2015-06-01 20:23 ` Junio C Hamano
2015-06-02 1:26 ` Greg KH
2015-06-26 19:49 ` Stefan Beller
2015-06-26 20:58 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqd21f5k7w.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=gascoar@gmail.com \
--cc=git@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.