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$(echo .)com \
--cc=gascoar@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gregkh@linuxfoundation$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox