Update Swedish translation. #1
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Translate some non-TEST into Icelandic. This is far from a complete translation, I've only translated init-db.c. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
An incomplete German translation. Signed-off-by: Jan Krüger <jk@jk.gs> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Translate three Git messages from US to British English. These all had to do with z v.s. s differences. Signed-off-by: Sam Reed <sam@reedyboy.net> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Translate a few Git messages to Standard Hindi. It uses a phonetic script called Devanagari. Focus especially on transforming grammar and tense in a sane manner to serve as a guideline for future translators. Note that Devanagari rendering is broken on many applications by default at this time- the latest Emacs, Vim and Chrome render it incorrectly. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Acked-by: Antriksh Pany <antriksh.pany@gmail.com> Acked-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
An incomplete Polish translation. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Marcin Cieślak <saper@saper.info>
Signed-off-by: Peter Krefting <peter@softwolves.pp.se> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Translate all 689 currently translatable messages in Git into German. Making the German translation 100% complete. [Ævar Arnfjörð Bjarmason: Modified by running msgmerge(1) on it to normalize the line wrapping, and squashed two of Jan's commits together] Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Also incorporate review changes from the first translation run by Göran Uddeborg <goeran@uddeborg.se> Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
|
Np, will try to submin it soon
|
avar
pushed a commit
that referenced
this pull request
Oct 19, 2011
The previous logic in show_config was to print the delimiter when the value was set, but Boolean variables have an implicit value "true" when they appear with no value in the config file. As a result, we got: git_Config --get-regexp '.*\.Boolean' #1. Ok: example.boolean git_Config --bool --get-regexp '.*\.Boolean' #2. NO: example.booleantrue Fix this by defering the display of the separator until after the value to display has been computed. Reported-by: Brian Foster <brian.foster@maxim-ic.com> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
avar
pushed a commit
that referenced
this pull request
Jan 20, 2012
While identifying the commit merged to our history as "parent #2" is technically correct, we will never say "parent #1" (as that is the tip of our history before the merge is made), and we rarely would say "parent #3" (which would mean the merge is an octopus), especially when responding to a request to pull a signed tag. Treat the most common case to merge a single commit specially, and just say "merged tag '<tagname>'" instead. Signed-off-by: Junio C Hamano <gitster@pobox.com>
avar
pushed a commit
that referenced
this pull request
Mar 5, 2013
entry_count is used in update_one() for two purposes: 1. to skip through the number of processed entries in in-memory index 2. to record the number of entries this cache-tree covers on disk Unfortunately when CE_REMOVE is present these numbers are not the same because CE_REMOVE entries are automatically removed before writing to disk but entry_count is not adjusted and still counts CE_REMOVE entries. Separate the two use cases into two different variables. #1 is taken care by the new field count in struct cache_tree_sub and entry_count is prepared for #2. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
avar
pushed a commit
that referenced
this pull request
Aug 30, 2013
The DWIM mode of checkout allows you to run "git checkout foo" when there is no existing local ref or path called "foo", and there is exactly _one_ remote with a remote-tracking branch called "foo". Git will automatically create a new local branch called "foo" using the remote-tracking "foo" as its starting point and configured upstream. For example, consider the following unconventional (but perfectly valid) remote setup: [remote "origin"] fetch = refs/heads/*:refs/remotes/origin/* [remote "frotz"] fetch = refs/heads/*:refs/remotes/frotz/nitfol/* Case 1: Assume both "origin" and "frotz" have remote-tracking branches called "foo", at "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo" respectively. In this case "git checkout foo" should fail, because there is more than one remote with a "foo" branch. Case 2: Assume only "frotz" have a remote-tracking branch called "foo". In this case "git checkout foo" should succeed, and create a local branch "foo" from "refs/remotes/frotz/nitfol/foo", using remote branch "foo" from "frotz" as its upstream. The current code hardcodes the assumption that all remote-tracking branches must match the "refs/remotes/$remote/*" pattern (which is true for remotes with "conventional" refspecs, but not true for the "frotz" remote above). When running "git checkout foo", the current code looks for exactly one ref matching "refs/remotes/*/foo", hence in the above example, it fails to find "refs/remotes/frotz/nitfol/foo", which causes it to fail both case #1 and #2. The better way to handle the above example is to actually study the fetch refspecs to deduce the candidate remote-tracking branches for "foo"; i.e. assume "foo" is a remote branch being fetched, and then map "refs/heads/foo" through the refspecs in order to get the corresponding remote-tracking branches "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo". Finally we check which of these happens to exist in the local repo, and if there is exactly one, we have an unambiguous match for "git checkout foo", and may proceed. This fixes most of the failing tests introduced in the previous patch. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
avar
pushed a commit
that referenced
this pull request
May 11, 2014
We have two ways of dealing with empty pathspec: 1. limit it to current prefix 2. match the entire working directory Some commands go with #1, some #2. get_pathspec() and parse_pathspec() only support #1. Make parse_pathspec() reject empty pathspec by default. #1 and #2 can be specified via new flags. This makes it more expressive about default behavior at command level. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
avar
pushed a commit
that referenced
this pull request
May 11, 2014
In 41c21f2 (branch.c: Validate tracking branches with refspecs instead of refs/remotes/*), we changed the rules for what is considered a valid tracking branch (a.k.a. upstream branch). We now use the configured remotes and their refspecs to determine whether a proposed tracking branch is in fact within the domain of a remote, and we then use that information to deduce the upstream configuration (branch.<name>.remote and branch.<name>.merge). However, with that change, we also check that - in addition to a matching refspec - the result of mapping the tracking branch through that refspec (i.e. the corresponding ref name in the remote repo) happens to start with "refs/heads/". In other words, we require that a tracking branch refers to a _branch_ in the remote repo. Now, consider that you are e.g. setting up an automated building/testing infrastructure for a group of similar "source" repositories. The build/test infrastructure consists of a central scheduler, and a number of build/test "slave" machines that perform the actual build/test work. The scheduler monitors the group of similar repos for changes (e.g. with a periodic "git fetch"), and triggers builds/tests to be run on one or more slaves. Graphically the changes flow between the repos like this: Source #1 -------v ----> Slave #1 / Source #2 -----> Scheduler -----> Slave #2 \ Source #3 -------^ ----> Slave #3 ... ... The scheduler maintains a single Git repo with each of the source repos set up as distinct remotes. The slaves also need access to all the changes from all of the source repos, so they pull from the scheduler repo, but using the following custom refspec: remote.origin.fetch = "+refs/remotes/*:refs/remotes/*" This makes all of the scheduler's remote-tracking branches automatically available as identical remote-tracking branches in each of the slaves. Now, consider what happens if a slave tries to create a local branch with one of the remote-tracking branches as upstream: git branch local_branch --track refs/remotes/source-1/some_branch Git now looks at the configured remotes (in this case there is only "origin", pointing to the scheduler's repo) and sees refs/remotes/source-1/some_branch matching origin's refspec. Mapping through that refspec we find that the corresponding remote ref name is "refs/remotes/source-1/some_branch". However, since this remote ref name does not start with "refs/heads/", we discard it as a suitable upstream, and the whole command fails. This patch adds a testcase demonstrating this failure by creating two source repos ("a" and "b") that are forwarded through a scheduler ("c") to a slave repo ("d"), that then tries create a local branch with an upstream. See the next patch in this series for the exciting conclusion to this story... Reported-by: Per Cederqvist <cederp@opera.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
avar
pushed a commit
that referenced
this pull request
Dec 14, 2015
When ac49f5c (rerere "remaining", 2011-02-16) split out a new helper function check_one_conflict() out of find_conflict() function, so that the latter will use the returned value from the new helper to update the loop control variable that is an index into active_cache[], the new variable incremented the index by one too many when it found a path with only stage #1 entry at the very end of active_cache[]. This "strange" return value does not have any effect on the loop control of two callers of this function, as they all notice that active_nr+2 is larger than active_nr just like active_nr+1 is, but nevertheless it puzzles the readers when they are trying to figure out what the function is trying to do. In fact, there is no need to do an early return. The code that follows after skipping the stage #1 entry is fully prepared to handle a case where the entry is at the very end of active_cache[]. Help future readers from unnecessary confusion by dropping an early return. We skip the stage #1 entry, and if there are stage #2 and stage #3 entries for the same path, we diagnose the path as THREE_STAGED (otherwise we say PUNTED), and then we skip all entries for the same path. Signed-off-by: Junio C Hamano <gitster@pobox.com>
avar
pushed a commit
that referenced
this pull request
Dec 14, 2015
A conflicted index can have multiple stage #1 entries when dealing with a criss-cross merge and using the "resolve" merge strategy. Signed-off-by: Junio C Hamano <gitster@pobox.com>
avar
pushed a commit
that referenced
this pull request
Dec 14, 2015
A conflicted index can have multiple stage #1 entries when dealing with a criss-cross merge and using the "resolve" merge strategy. Plug the leak by reading only the first one of the same stage entries. Strictly speaking, this fix does change the semantics, in that we used to use the last stage #1 entry as the common ancestor when doing the plain-vanilla three-way merge, but with the leak fix, we will use the first stage #1 entry. But it is not a grave backward compatibility breakage. Either way, we are arbitrarily picking one of multiple stage #1 entries and using it, ignoring others, and there is no meaning in the ordering of these stage #1 entries. Signed-off-by: Junio C Hamano <gitster@pobox.com>
avar
pushed a commit
that referenced
this pull request
Dec 14, 2015
Code clean-up and minor fixes. * jc/rerere: (21 commits) rerere: un-nest merge() further rerere: use "struct rerere_id" instead of "char *" for conflict ID rerere: call conflict-ids IDs rerere: further clarify do_rerere_one_path() rerere: further de-dent do_plain_rerere() rerere: refactor "replay" part of do_plain_rerere() rerere: explain the remainder rerere: explain "rerere forget" codepath rerere: explain the primary codepath rerere: explain MERGE_RR management helpers rerere: fix benign off-by-one non-bug and clarify code rerere: explain the rerere I/O abstraction rerere: do not leak mmfile[] for a path with multiple stage #1 entries rerere: stop looping unnecessarily rerere: drop want_sp parameter from is_cmarker() rerere: report autoupdated paths only after actually updating them rerere: write out each record of MERGE_RR in one go rerere: lift PATH_MAX limitation rerere: plug conflict ID leaks rerere: handle conflicts with multiple stage #1 entries ...
avar
pushed a commit
that referenced
this pull request
Feb 27, 2017
We generate the squash commit message incrementally running a sed script once for each commit. It parses "This is a combination of <N> commits" from the first line of the existing message, adds one to <N>, and uses the result as the number of our current message. Since f2d1706 (i18n: rebase-interactive: mark comments of squash for translation, 2016-06-17), the first line may be localized, and sed uses a pretty liberal regex, looking for: /^#.*([0-9][0-9]*)/ The "[0-9][0-9]*" tries to match double digits, but it doesn't quite work. The first ".*" is greedy, so if you have: This is a combination of 10 commits. it will eat up "This is a combination of 1", leaving "0" to match the first "[0-9]" digit, and then skipping the optional match of "[0-9]*". As a result, the count resets every 10 commits, and a 15-commit squash would end up as: # This is a combination of 5 commits. # This is the 1st commit message: ... # This is the commit message #2: ... and so on .. # This is the commit message git#10: ... # This is the commit message #1: ... # This is the commit message #2: ... etc, up to 5 ... We can fix this by making the ".*" less greedy. Instead of depending on ".*?" working portably, we can just limit the match to non-digit characters, which accomplishes the same thing. Reported-by: Brandon Tolsch <btolsch@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
avar
added a commit
that referenced
this pull request
Jun 1, 2017
Amend my change earlier in this series ("grep: add support for the
PCRE v1 JIT API", 2017-04-11) to un-break the build on PCRE v1
versions later than 8.31 compiled without --enable-jit.
As explained in that change and a later compatibility change in this
series ("grep: un-break building with PCRE < 8.32", 2017-05-10) the
pcre_jit_exec() function is a faster path to execute the JIT.
Unfortunately there's no compatibility stub for that function compiled
into the library if pcre_config(PCRE_CONFIG_JIT, &ret) would return 0,
and no macro that can be used to check for it, so the only portable
option to support builds without --enable-jit is via a new
NO_LIBPCRE1_JIT=UnfortunatelyYes Makefile option[1].
Another option would be to make the JIT opt-in via
USE_LIBPCRE1_JIT=YesPlease, after all it's not a default option of
PCRE v1.
I think it makes more sense to make it opt-out since even though it's
not a default option, most packagers of PCRE seem to turn it on by
default, with the notable exception of the MinGW package.
Make the MinGW platform work by default by changing the build defaults
to turn on NO_LIBPCRE1_JIT=UnfortunatelyYes. It is the only platform
that turns on USE_LIBPCRE=YesPlease by default, see commit
df5218b ("config.mak.uname: support MSys2", 2016-01-13) for that
change.
1. "How do I support pcre1 JIT on all
versions?" (https://lists.exim.org/lurker/thread/20170601.103148.10253788.en.html)
2. https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-pcre/PKGBUILD
(referenced from "Re: PCRE v2 compile error, was Re: What's cooking
in git.git (May 2017, #1; Mon, 1)";
<alpine.DEB.2.20.1705021756530.3480@virtualbox>)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
avar
added a commit
that referenced
this pull request
Jan 9, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Jan 10, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Jan 12, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Jan 12, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Jan 13, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
pushed a commit
that referenced
this pull request
Jan 18, 2023
There is an out-of-bounds read possible when parsing gitattributes that
have an attribute that is 2^31+1 bytes long. This is caused due to an
integer overflow when we assign the result of strlen(3P) to an `int`,
where we use the wrapped-around value in a subsequent call to
memcpy(3P). The following code reproduces the issue:
blob=$(perl -e 'print "a" x 2147483649 . " attr"' | git hash-object -w --stdin)
git update-index --add --cacheinfo 100644,$blob,.gitattributes
git check-attr --all file
AddressSanitizer:DEADLYSIGNAL
=================================================================
==8451==ERROR: AddressSanitizer: SEGV on unknown address 0x7f93efa00800 (pc 0x7f94f1f8f082 bp 0x7ffddb59b3a0 sp 0x7ffddb59ab28 T0)
==8451==The signal is caused by a READ memory access.
#0 0x7f94f1f8f082 (/usr/lib/libc.so.6+0x176082)
#1 0x7f94f2047d9c in __interceptor_strspn /usr/src/debug/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:752
#2 0x560e190f7f26 in parse_attr_line attr.c:375
#3 0x560e190f9663 in handle_attr_line attr.c:660
#4 0x560e190f9ddd in read_attr_from_index attr.c:769
#5 0x560e190f9f14 in read_attr attr.c:797
git#6 0x560e190fa24e in bootstrap_attr_stack attr.c:867
#7 0x560e190fa4a5 in prepare_attr_stack attr.c:902
git#8 0x560e190fb5dc in collect_some_attrs attr.c:1097
git#9 0x560e190fb93f in git_all_attrs attr.c:1128
git#10 0x560e18e6136e in check_attr builtin/check-attr.c:67
git#11 0x560e18e61c12 in cmd_check_attr builtin/check-attr.c:183
git#12 0x560e18e15993 in run_builtin git.c:466
git#13 0x560e18e16397 in handle_builtin git.c:721
git#14 0x560e18e16b2b in run_argv git.c:788
git#15 0x560e18e17991 in cmd_main git.c:926
git#16 0x560e190ae2bd in main common-main.c:57
git#17 0x7f94f1e3c28f (/usr/lib/libc.so.6+0x2328f)
git#18 0x7f94f1e3c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349)
git#19 0x560e18e110e4 in _start ../sysdeps/x86_64/start.S:115
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/usr/lib/libc.so.6+0x176082)
==8451==ABORTING
Fix this bug by converting the variable to a `size_t` instead.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
avar
pushed a commit
that referenced
this pull request
Jan 18, 2023
It is possible to trigger an integer overflow when parsing attribute
names when there are more than 2^31 of them for a single pattern. This
can either lead to us dying due to trying to request too many bytes:
blob=$(perl -e 'print "f" . " a=" x 2147483649' | git hash-object -w --stdin)
git update-index --add --cacheinfo 100644,$blob,.gitattributes
git attr-check --all file
=================================================================
==1022==ERROR: AddressSanitizer: requested allocation size 0xfffffff800000032 (0xfffffff800001038 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x10000000000 (thread T0)
#0 0x7fd3efabf411 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x5563a0a1e3d3 in xcalloc wrapper.c:150
#2 0x5563a058d005 in parse_attr_line attr.c:384
#3 0x5563a058e661 in handle_attr_line attr.c:660
#4 0x5563a058eddb in read_attr_from_index attr.c:769
#5 0x5563a058ef12 in read_attr attr.c:797
git#6 0x5563a058f24c in bootstrap_attr_stack attr.c:867
#7 0x5563a058f4a3 in prepare_attr_stack attr.c:902
git#8 0x5563a05905da in collect_some_attrs attr.c:1097
git#9 0x5563a059093d in git_all_attrs attr.c:1128
git#10 0x5563a02f636e in check_attr builtin/check-attr.c:67
git#11 0x5563a02f6c12 in cmd_check_attr builtin/check-attr.c:183
git#12 0x5563a02aa993 in run_builtin git.c:466
git#13 0x5563a02ab397 in handle_builtin git.c:721
git#14 0x5563a02abb2b in run_argv git.c:788
git#15 0x5563a02ac991 in cmd_main git.c:926
git#16 0x5563a05432bd in main common-main.c:57
git#17 0x7fd3ef82228f (/usr/lib/libc.so.6+0x2328f)
==1022==HINT: if you don't care about these errors you may set allocator_may_return_null=1
SUMMARY: AddressSanitizer: allocation-size-too-big /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77 in __interceptor_calloc
==1022==ABORTING
Or, much worse, it can lead to an out-of-bounds write because we
underallocate and then memcpy(3P) into an array:
perl -e '
print "A " . "\rh="x2000000000;
print "\rh="x2000000000;
print "\rh="x294967294 . "\n"
' >.gitattributes
git add .gitattributes
git commit -am "evil attributes"
$ git clone --quiet /path/to/repo
=================================================================
==15062==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000002550 at pc 0x5555559884d5 bp 0x7fffffffbc60 sp 0x7fffffffbc58
WRITE of size 8 at 0x602000002550 thread T0
#0 0x5555559884d4 in parse_attr_line attr.c:393
#1 0x5555559884d4 in handle_attr_line attr.c:660
#2 0x555555988902 in read_attr_from_index attr.c:784
#3 0x555555988902 in read_attr_from_index attr.c:747
#4 0x555555988a1d in read_attr attr.c:800
#5 0x555555989b0c in bootstrap_attr_stack attr.c:882
git#6 0x555555989b0c in prepare_attr_stack attr.c:917
#7 0x555555989b0c in collect_some_attrs attr.c:1112
git#8 0x55555598b141 in git_check_attr attr.c:1126
git#9 0x555555a13004 in convert_attrs convert.c:1311
git#10 0x555555a95e04 in checkout_entry_ca entry.c:553
git#11 0x555555d58bf6 in checkout_entry entry.h:42
git#12 0x555555d58bf6 in check_updates unpack-trees.c:480
git#13 0x555555d5eb55 in unpack_trees unpack-trees.c:2040
git#14 0x555555785ab7 in checkout builtin/clone.c:724
git#15 0x555555785ab7 in cmd_clone builtin/clone.c:1384
git#16 0x55555572443c in run_builtin git.c:466
git#17 0x55555572443c in handle_builtin git.c:721
git#18 0x555555727872 in run_argv git.c:788
git#19 0x555555727872 in cmd_main git.c:926
git#20 0x555555721fa0 in main common-main.c:57
git#21 0x7ffff73f1d09 in __libc_start_main ../csu/libc-start.c:308
git#22 0x555555723f39 in _start (git+0x1cff39)
0x602000002552 is located 0 bytes to the right of 2-byte region [0x602000002550,0x602000002552) allocated by thread T0 here:
#0 0x7ffff768c037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x555555d7fff7 in xcalloc wrapper.c:150
#2 0x55555598815f in parse_attr_line attr.c:384
#3 0x55555598815f in handle_attr_line attr.c:660
#4 0x555555988902 in read_attr_from_index attr.c:784
#5 0x555555988902 in read_attr_from_index attr.c:747
git#6 0x555555988a1d in read_attr attr.c:800
#7 0x555555989b0c in bootstrap_attr_stack attr.c:882
git#8 0x555555989b0c in prepare_attr_stack attr.c:917
git#9 0x555555989b0c in collect_some_attrs attr.c:1112
git#10 0x55555598b141 in git_check_attr attr.c:1126
git#11 0x555555a13004 in convert_attrs convert.c:1311
git#12 0x555555a95e04 in checkout_entry_ca entry.c:553
git#13 0x555555d58bf6 in checkout_entry entry.h:42
git#14 0x555555d58bf6 in check_updates unpack-trees.c:480
git#15 0x555555d5eb55 in unpack_trees unpack-trees.c:2040
git#16 0x555555785ab7 in checkout builtin/clone.c:724
git#17 0x555555785ab7 in cmd_clone builtin/clone.c:1384
git#18 0x55555572443c in run_builtin git.c:466
git#19 0x55555572443c in handle_builtin git.c:721
git#20 0x555555727872 in run_argv git.c:788
git#21 0x555555727872 in cmd_main git.c:926
git#22 0x555555721fa0 in main common-main.c:57
git#23 0x7ffff73f1d09 in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: heap-buffer-overflow attr.c:393 in parse_attr_line
Shadow bytes around the buggy address:
0x0c047fff8450: fa fa 00 02 fa fa 00 07 fa fa fd fd fa fa 00 00
0x0c047fff8460: fa fa 02 fa fa fa fd fd fa fa 00 06 fa fa 05 fa
0x0c047fff8470: fa fa fd fd fa fa 00 02 fa fa 06 fa fa fa 05 fa
0x0c047fff8480: fa fa 07 fa fa fa fd fd fa fa 00 01 fa fa 00 02
0x0c047fff8490: fa fa 00 03 fa fa 00 fa fa fa 00 01 fa fa 00 03
=>0x0c047fff84a0: fa fa 00 01 fa fa 00 02 fa fa[02]fa fa fa fa fa
0x0c047fff84b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff84c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff84d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff84e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff84f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==15062==ABORTING
Fix this bug by using `size_t` instead to count the number of attributes
so that this value cannot reasonably overflow without running out of
memory before already.
Reported-by: Markus Vervier <markus.vervier@x41-dsec.de>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
avar
pushed a commit
that referenced
this pull request
Jan 18, 2023
When using a padding specifier in the pretty format passed to git-log(1)
we need to calculate the string length in several places. These string
lengths are stored in `int`s though, which means that these can easily
overflow when the input lengths exceeds 2GB. This can ultimately lead to
an out-of-bounds write when these are used in a call to memcpy(3P):
==8340==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f1ec62f97fe at pc 0x7f2127e5f427 bp 0x7ffd3bd63de0 sp 0x7ffd3bd63588
WRITE of size 1 at 0x7f1ec62f97fe thread T0
#0 0x7f2127e5f426 in __interceptor_memcpy /usr/src/debug/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827
#1 0x5628e96aa605 in format_and_pad_commit pretty.c:1762
#2 0x5628e96aa7f4 in format_commit_item pretty.c:1801
#3 0x5628e97cdb24 in strbuf_expand strbuf.c:429
#4 0x5628e96ab060 in repo_format_commit_message pretty.c:1869
#5 0x5628e96acd0f in pretty_print_commit pretty.c:2161
git#6 0x5628e95a44c8 in show_log log-tree.c:781
#7 0x5628e95a76ba in log_tree_commit log-tree.c:1117
git#8 0x5628e922bed5 in cmd_log_walk_no_free builtin/log.c:508
git#9 0x5628e922c35b in cmd_log_walk builtin/log.c:549
git#10 0x5628e922f1a2 in cmd_log builtin/log.c:883
git#11 0x5628e9106993 in run_builtin git.c:466
git#12 0x5628e9107397 in handle_builtin git.c:721
git#13 0x5628e9107b07 in run_argv git.c:788
git#14 0x5628e91088a7 in cmd_main git.c:923
git#15 0x5628e939d682 in main common-main.c:57
git#16 0x7f2127c3c28f (/usr/lib/libc.so.6+0x2328f)
git#17 0x7f2127c3c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349)
git#18 0x5628e91020e4 in _start ../sysdeps/x86_64/start.S:115
0x7f1ec62f97fe is located 2 bytes to the left of 4831838265-byte region [0x7f1ec62f9800,0x7f1fe62f9839)
allocated by thread T0 here:
#0 0x7f2127ebe7ea in __interceptor_realloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:85
#1 0x5628e98774d4 in xrealloc wrapper.c:136
#2 0x5628e97cb01c in strbuf_grow strbuf.c:99
#3 0x5628e97ccd42 in strbuf_addchars strbuf.c:327
#4 0x5628e96aa55c in format_and_pad_commit pretty.c:1761
#5 0x5628e96aa7f4 in format_commit_item pretty.c:1801
git#6 0x5628e97cdb24 in strbuf_expand strbuf.c:429
#7 0x5628e96ab060 in repo_format_commit_message pretty.c:1869
git#8 0x5628e96acd0f in pretty_print_commit pretty.c:2161
git#9 0x5628e95a44c8 in show_log log-tree.c:781
git#10 0x5628e95a76ba in log_tree_commit log-tree.c:1117
git#11 0x5628e922bed5 in cmd_log_walk_no_free builtin/log.c:508
git#12 0x5628e922c35b in cmd_log_walk builtin/log.c:549
git#13 0x5628e922f1a2 in cmd_log builtin/log.c:883
git#14 0x5628e9106993 in run_builtin git.c:466
git#15 0x5628e9107397 in handle_builtin git.c:721
git#16 0x5628e9107b07 in run_argv git.c:788
git#17 0x5628e91088a7 in cmd_main git.c:923
git#18 0x5628e939d682 in main common-main.c:57
git#19 0x7f2127c3c28f (/usr/lib/libc.so.6+0x2328f)
git#20 0x7f2127c3c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349)
git#21 0x5628e91020e4 in _start ../sysdeps/x86_64/start.S:115
SUMMARY: AddressSanitizer: heap-buffer-overflow /usr/src/debug/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827 in __interceptor_memcpy
Shadow bytes around the buggy address:
0x0fe458c572a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0fe458c572b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0fe458c572c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0fe458c572d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0fe458c572e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0fe458c572f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa[fa]
0x0fe458c57300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe458c57310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe458c57320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe458c57330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe458c57340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==8340==ABORTING
The pretty format can also be used in `git archive` operations via the
`export-subst` attribute. So this is what in our opinion makes this a
critical issue in the context of Git forges which allow to download an
archive of user supplied Git repositories.
Fix this vulnerability by using `size_t` instead of `int` to track the
string lengths. Add tests which detect this vulnerability when Git is
compiled with the address sanitizer.
Reported-by: Joern Schneeweisz <jschneeweisz@gitlab.com>
Original-patch-by: Joern Schneeweisz <jschneeweisz@gitlab.com>
Modified-by: Taylor Blau <me@ttalorr.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
avar
pushed a commit
that referenced
this pull request
Jan 18, 2023
With the `%>>(<N>)` pretty formatter, you can ask git-log(1) et al to
steal spaces. To do so we need to look ahead of the next token to see
whether there are spaces there. This loop takes into account ANSI
sequences that end with an `m`, and if it finds any it will skip them
until it finds the first space. While doing so it does not take into
account the buffer's limits though and easily does an out-of-bounds
read.
Add a test that hits this behaviour. While we don't have an easy way to
verify this, the test causes the following failure when run with
`SANITIZE=address`:
==37941==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000000baf at pc 0x55ba6f88e0d0 bp 0x7ffc84c50d20 sp 0x7ffc84c50d10
READ of size 1 at 0x603000000baf thread T0
#0 0x55ba6f88e0cf in format_and_pad_commit pretty.c:1712
#1 0x55ba6f88e7b4 in format_commit_item pretty.c:1801
#2 0x55ba6f9b1ae4 in strbuf_expand strbuf.c:429
#3 0x55ba6f88f020 in repo_format_commit_message pretty.c:1869
#4 0x55ba6f890ccf in pretty_print_commit pretty.c:2161
#5 0x55ba6f7884c8 in show_log log-tree.c:781
git#6 0x55ba6f78b6ba in log_tree_commit log-tree.c:1117
#7 0x55ba6f40fed5 in cmd_log_walk_no_free builtin/log.c:508
git#8 0x55ba6f41035b in cmd_log_walk builtin/log.c:549
git#9 0x55ba6f4131a2 in cmd_log builtin/log.c:883
git#10 0x55ba6f2ea993 in run_builtin git.c:466
git#11 0x55ba6f2eb397 in handle_builtin git.c:721
git#12 0x55ba6f2ebb07 in run_argv git.c:788
git#13 0x55ba6f2ec8a7 in cmd_main git.c:923
git#14 0x55ba6f581682 in main common-main.c:57
git#15 0x7f2d08c3c28f (/usr/lib/libc.so.6+0x2328f)
git#16 0x7f2d08c3c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349)
git#17 0x55ba6f2e60e4 in _start ../sysdeps/x86_64/start.S:115
0x603000000baf is located 1 bytes to the left of 24-byte region [0x603000000bb0,0x603000000bc8)
allocated by thread T0 here:
#0 0x7f2d08ebe7ea in __interceptor_realloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:85
#1 0x55ba6fa5b494 in xrealloc wrapper.c:136
#2 0x55ba6f9aefdc in strbuf_grow strbuf.c:99
#3 0x55ba6f9b0a06 in strbuf_add strbuf.c:298
#4 0x55ba6f9b1a25 in strbuf_expand strbuf.c:418
#5 0x55ba6f88f020 in repo_format_commit_message pretty.c:1869
git#6 0x55ba6f890ccf in pretty_print_commit pretty.c:2161
#7 0x55ba6f7884c8 in show_log log-tree.c:781
git#8 0x55ba6f78b6ba in log_tree_commit log-tree.c:1117
git#9 0x55ba6f40fed5 in cmd_log_walk_no_free builtin/log.c:508
git#10 0x55ba6f41035b in cmd_log_walk builtin/log.c:549
git#11 0x55ba6f4131a2 in cmd_log builtin/log.c:883
git#12 0x55ba6f2ea993 in run_builtin git.c:466
git#13 0x55ba6f2eb397 in handle_builtin git.c:721
git#14 0x55ba6f2ebb07 in run_argv git.c:788
git#15 0x55ba6f2ec8a7 in cmd_main git.c:923
git#16 0x55ba6f581682 in main common-main.c:57
git#17 0x7f2d08c3c28f (/usr/lib/libc.so.6+0x2328f)
git#18 0x7f2d08c3c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349)
git#19 0x55ba6f2e60e4 in _start ../sysdeps/x86_64/start.S:115
SUMMARY: AddressSanitizer: heap-buffer-overflow pretty.c:1712 in format_and_pad_commit
Shadow bytes around the buggy address:
0x0c067fff8120: fa fa fd fd fd fa fa fa fd fd fd fa fa fa fd fd
0x0c067fff8130: fd fd fa fa fd fd fd fd fa fa fd fd fd fa fa fa
0x0c067fff8140: fd fd fd fa fa fa fd fd fd fa fa fa fd fd fd fa
0x0c067fff8150: fa fa fd fd fd fd fa fa 00 00 00 fa fa fa fd fd
0x0c067fff8160: fd fa fa fa fd fd fd fa fa fa fd fd fd fa fa fa
=>0x0c067fff8170: fd fd fd fa fa[fa]00 00 00 fa fa fa 00 00 00 fa
0x0c067fff8180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff8190: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff81a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff81b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff81c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Luckily enough, this would only cause us to copy the out-of-bounds data
into the formatted commit in case we really had an ANSI sequence
preceding our buffer. So this bug likely has no security consequences.
Fix it regardless by not traversing past the buffer's start.
Reported-by: Patrick Steinhardt <ps@pks.im>
Reported-by: Eric Sesterhenn <eric.sesterhenn@x41-dsec.de>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
avar
pushed a commit
that referenced
this pull request
Jan 18, 2023
An out-of-bounds read can be triggered when parsing an incomplete padding format string passed via `--pretty=format` or in Git archives when files are marked with the `export-subst` gitattribute. This bug exists since we have introduced support for truncating output via the `trunc` keyword a7f01c6 (pretty: support truncating in %>, %< and %><, 2013-04-19). Before this commit, we used to find the end of the formatting string by using strchr(3P). This function returns a `NULL` pointer in case the character in question wasn't found. The subsequent check whether any character was found thus simply checked the returned pointer. After the commit we switched to strcspn(3P) though, which only returns the offset to the first found character or to the trailing NUL byte. As the end pointer is now computed by adding the offset to the start pointer it won't be `NULL` anymore, and as a consequence the check doesn't do anything anymore. The out-of-bounds data that is being read can in fact end up in the formatted string. As a consequence, it is possible to leak memory contents either by calling git-log(1) or via git-archive(1) when any of the archived files is marked with the `export-subst` gitattribute. ==10888==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000398 at pc 0x7f0356047cb2 bp 0x7fff3ffb95d0 sp 0x7fff3ffb8d78 READ of size 1 at 0x602000000398 thread T0 #0 0x7f0356047cb1 in __interceptor_strchrnul /usr/src/debug/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:725 #1 0x563b7cec9a43 in strbuf_expand strbuf.c:417 #2 0x563b7cda7060 in repo_format_commit_message pretty.c:1869 #3 0x563b7cda8d0f in pretty_print_commit pretty.c:2161 #4 0x563b7cca04c8 in show_log log-tree.c:781 #5 0x563b7cca36ba in log_tree_commit log-tree.c:1117 git#6 0x563b7c927ed5 in cmd_log_walk_no_free builtin/log.c:508 #7 0x563b7c92835b in cmd_log_walk builtin/log.c:549 git#8 0x563b7c92b1a2 in cmd_log builtin/log.c:883 git#9 0x563b7c802993 in run_builtin git.c:466 git#10 0x563b7c803397 in handle_builtin git.c:721 git#11 0x563b7c803b07 in run_argv git.c:788 git#12 0x563b7c8048a7 in cmd_main git.c:923 git#13 0x563b7ca99682 in main common-main.c:57 git#14 0x7f0355e3c28f (/usr/lib/libc.so.6+0x2328f) git#15 0x7f0355e3c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349) git#16 0x563b7c7fe0e4 in _start ../sysdeps/x86_64/start.S:115 0x602000000398 is located 0 bytes to the right of 8-byte region [0x602000000390,0x602000000398) allocated by thread T0 here: #0 0x7f0356072faa in __interceptor_strdup /usr/src/debug/gcc/libsanitizer/asan/asan_interceptors.cpp:439 #1 0x563b7cf7317c in xstrdup wrapper.c:39 #2 0x563b7cd9a06a in save_user_format pretty.c:40 #3 0x563b7cd9b3e5 in get_commit_format pretty.c:173 #4 0x563b7ce54ea0 in handle_revision_opt revision.c:2456 #5 0x563b7ce597c9 in setup_revisions revision.c:2850 git#6 0x563b7c9269e0 in cmd_log_init_finish builtin/log.c:269 #7 0x563b7c927362 in cmd_log_init builtin/log.c:348 git#8 0x563b7c92b193 in cmd_log builtin/log.c:882 git#9 0x563b7c802993 in run_builtin git.c:466 git#10 0x563b7c803397 in handle_builtin git.c:721 git#11 0x563b7c803b07 in run_argv git.c:788 git#12 0x563b7c8048a7 in cmd_main git.c:923 git#13 0x563b7ca99682 in main common-main.c:57 git#14 0x7f0355e3c28f (/usr/lib/libc.so.6+0x2328f) git#15 0x7f0355e3c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349) git#16 0x563b7c7fe0e4 in _start ../sysdeps/x86_64/start.S:115 SUMMARY: AddressSanitizer: heap-buffer-overflow /usr/src/debug/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:725 in __interceptor_strchrnul Shadow bytes around the buggy address: 0x0c047fff8020: fa fa fd fd fa fa 00 06 fa fa 05 fa fa fa fd fd 0x0c047fff8030: fa fa 00 02 fa fa 06 fa fa fa 05 fa fa fa fd fd 0x0c047fff8040: fa fa 00 07 fa fa 03 fa fa fa fd fd fa fa 00 00 0x0c047fff8050: fa fa 00 01 fa fa fd fd fa fa 00 00 fa fa 00 01 0x0c047fff8060: fa fa 00 06 fa fa 00 06 fa fa 05 fa fa fa 05 fa =>0x0c047fff8070: fa fa 00[fa]fa fa fd fa fa fa fd fd fa fa fd fd 0x0c047fff8080: fa fa fd fd fa fa 00 00 fa fa 00 fa fa fa fd fa 0x0c047fff8090: fa fa fd fd fa fa 00 00 fa fa fa fa fa fa fa fa 0x0c047fff80a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff80b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff80c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==10888==ABORTING Fix this bug by checking whether `end` points at the trailing NUL byte. Add a test which catches this out-of-bounds read and which demonstrates that we used to write out-of-bounds data into the formatted message. Reported-by: Markus Vervier <markus.vervier@x41-dsec.de> Original-patch-by: Markus Vervier <markus.vervier@x41-dsec.de> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
avar
pushed a commit
that referenced
this pull request
Jan 18, 2023
The return type of both `utf8_strwidth()` and `utf8_strnwidth()` is
`int`, but we operate on string lengths which are typically of type
`size_t`. This means that when the string is longer than `INT_MAX`, we
will overflow and thus return a negative result.
This can lead to an out-of-bounds write with `--pretty=format:%<1)%B`
and a commit message that is 2^31+1 bytes long:
=================================================================
==26009==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000001168 at pc 0x7f95c4e5f427 bp 0x7ffd8541c900 sp 0x7ffd8541c0a8
WRITE of size 2147483649 at 0x603000001168 thread T0
#0 0x7f95c4e5f426 in __interceptor_memcpy /usr/src/debug/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827
#1 0x5612bbb1068c in format_and_pad_commit pretty.c:1763
#2 0x5612bbb1087a in format_commit_item pretty.c:1801
#3 0x5612bbc33bab in strbuf_expand strbuf.c:429
#4 0x5612bbb110e7 in repo_format_commit_message pretty.c:1869
#5 0x5612bbb12d96 in pretty_print_commit pretty.c:2161
git#6 0x5612bba0a4d5 in show_log log-tree.c:781
#7 0x5612bba0d6c7 in log_tree_commit log-tree.c:1117
git#8 0x5612bb691ed5 in cmd_log_walk_no_free builtin/log.c:508
git#9 0x5612bb69235b in cmd_log_walk builtin/log.c:549
git#10 0x5612bb6951a2 in cmd_log builtin/log.c:883
git#11 0x5612bb56c993 in run_builtin git.c:466
git#12 0x5612bb56d397 in handle_builtin git.c:721
git#13 0x5612bb56db07 in run_argv git.c:788
git#14 0x5612bb56e8a7 in cmd_main git.c:923
git#15 0x5612bb803682 in main common-main.c:57
git#16 0x7f95c4c3c28f (/usr/lib/libc.so.6+0x2328f)
git#17 0x7f95c4c3c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349)
git#18 0x5612bb5680e4 in _start ../sysdeps/x86_64/start.S:115
0x603000001168 is located 0 bytes to the right of 24-byte region [0x603000001150,0x603000001168)
allocated by thread T0 here:
#0 0x7f95c4ebe7ea in __interceptor_realloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:85
#1 0x5612bbcdd556 in xrealloc wrapper.c:136
#2 0x5612bbc310a3 in strbuf_grow strbuf.c:99
#3 0x5612bbc32acd in strbuf_add strbuf.c:298
#4 0x5612bbc33aec in strbuf_expand strbuf.c:418
#5 0x5612bbb110e7 in repo_format_commit_message pretty.c:1869
git#6 0x5612bbb12d96 in pretty_print_commit pretty.c:2161
#7 0x5612bba0a4d5 in show_log log-tree.c:781
git#8 0x5612bba0d6c7 in log_tree_commit log-tree.c:1117
git#9 0x5612bb691ed5 in cmd_log_walk_no_free builtin/log.c:508
git#10 0x5612bb69235b in cmd_log_walk builtin/log.c:549
git#11 0x5612bb6951a2 in cmd_log builtin/log.c:883
git#12 0x5612bb56c993 in run_builtin git.c:466
git#13 0x5612bb56d397 in handle_builtin git.c:721
git#14 0x5612bb56db07 in run_argv git.c:788
git#15 0x5612bb56e8a7 in cmd_main git.c:923
git#16 0x5612bb803682 in main common-main.c:57
git#17 0x7f95c4c3c28f (/usr/lib/libc.so.6+0x2328f)
SUMMARY: AddressSanitizer: heap-buffer-overflow /usr/src/debug/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827 in __interceptor_memcpy
Shadow bytes around the buggy address:
0x0c067fff81d0: fd fd fd fa fa fa fd fd fd fa fa fa fd fd fd fa
0x0c067fff81e0: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd
0x0c067fff81f0: fd fa fa fa fd fd fd fa fa fa fd fd fd fa fa fa
0x0c067fff8200: fd fd fd fa fa fa fd fd fd fd fa fa 00 00 00 fa
0x0c067fff8210: fa fa fd fd fd fa fa fa fd fd fd fa fa fa fd fd
=>0x0c067fff8220: fd fa fa fa fd fd fd fa fa fa 00 00 00[fa]fa fa
0x0c067fff8230: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff8240: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff8250: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff8260: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff8270: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==26009==ABORTING
Now the proper fix for this would be to convert both functions to return
an `size_t` instead of an `int`. But given that this commit may be part
of a security release, let's instead do the minimal viable fix and die
in case we see an overflow.
Add a test that would have previously caused us to crash.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
avar
added a commit
that referenced
this pull request
Jan 23, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Feb 1, 2023
For those tests that have 1 occurances of 'test_i18ngrep', replace it with 'grep'. Splitting this incremental conversion by number of occurances in the file is arbitrary, but help so keep the commit size down. The 'test_i18ngrep' wrapper has been deprecated since d162b25 (tests: remove support for GIT_TEST_GETTEXT_POISON, 2021-01-20). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
avar
added a commit
that referenced
this pull request
Feb 2, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Feb 2, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Feb 3, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Feb 3, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Feb 6, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Feb 6, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Feb 6, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Feb 7, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Feb 7, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Feb 8, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Feb 8, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Feb 10, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Mar 6, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Mar 7, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
Mar 7, 2023
* avar/nuke-test_i18ngrep: tests with git#10 test_i18ngrep: replace it with 'grep' tests with git#9 test_i18ngrep: replace it with 'grep' tests with git#8 test_i18ngrep: replace it with 'grep' tests with #7 test_i18ngrep: replace it with 'grep' tests with git#6 test_i18ngrep: replace it with 'grep' tests with #5 test_i18ngrep: replace it with 'grep' tests with #4 test_i18ngrep: replace it with 'grep' tests with #3 test_i18ngrep: replace it with 'grep' tests with #2 test_i18ngrep: replace it with 'grep' tests with #1 test_i18ngrep: replace it with 'grep'
avar
added a commit
that referenced
this pull request
May 1, 2023
Adjust the code added in 1ff21c0 (config: store "git -c" variables using more robust format, 2021-01-12) to avoid allocating a "key" until after we've done the sanity checks on it. There reason for allocating it this in the function is because the "env_name" pointer was about to be incremented, let's instead note our position at that point. The key length is the number of characters before the first "=". As a result of this early allocation we'd have a memory leak as reported by valgrind, just not the "still reachable" kind we usually care about[1] with SANITIZE=leak: $ valgrind --leak-check=full --show-leak-kinds=all ./git --config-env=foo.flag= config --bool foo.flag [...] ==6540== 13 bytes in 1 blocks are still reachable in loss record 3 of 17 ==6540== at 0x48437B4: malloc (vg_replace_malloc.c:381) ==6540== by 0x40278B: do_xmalloc (wrapper.c:51) ==6540== by 0x402884: do_xmallocz (wrapper.c:85) ==6540== by 0x4028C0: xmallocz (wrapper.c:93) ==6540== by 0x4028FD: xmemdupz (wrapper.c:109) ==6540== by 0x402962: xstrndup (wrapper.c:115) ==6540== by 0x342F53: strip_path_suffix (path.c:1300) ==6540== by 0x2B4C89: system_prefix (exec-cmd.c:50) ==6540== by 0x2B5057: system_path (exec-cmd.c:268) ==6540== by 0x2C5E17: git_setup_gettext (gettext.c:109) ==6540== by 0x21DC57: main (common-main.c:44) Since the "key" was reachable when the "die()" ran the semantics of SANITIZE=leak wouldn't show it, but "clang" at higher optimization levels would optimize this to the point of thinking the variable wasn't reachable, e.g. with Debian clang 14.0.6-2 with CFLAGS="-O3 -g": $ ./git --config-env=foo.flag= config --bool foo.flag fatal: missing environment variable name for configuration 'foo.flag' ================================================================= ==18018==ERROR: LeakSanitizer: detected memory leaks Direct leak of 9 byte(s) in 1 object(s) allocated from: #0 0x55e40aad7cd2 in __interceptor_malloc (/home/avar/g/git/git+0x78cd2) (BuildId: b89fa8f797ccb02ef1148beed300071a5f9b9ab1) #1 0x55e40ad41071 in do_xmalloc /home/avar/g/git/wrapper.c:51:8 #2 0x55e40ad41071 in do_xmallocz /home/avar/g/git/wrapper.c:85:8 #3 0x55e40ad41071 in xmallocz /home/avar/g/git/wrapper.c:93:9 #4 0x55e40ad41071 in xmemdupz /home/avar/g/git/wrapper.c:109:16 #5 0x55e40abec960 in git_config_push_env /home/avar/g/git/config.c:521:8 git#6 0x55e40aadb8b9 in handle_options /home/avar/g/git/git.c:268:4 #7 0x55e40aada68d in cmd_main /home/avar/g/git/git.c:896:2 git#8 0x55e40abae219 in main /home/avar/g/git/common-main.c:57:11 git#9 0x7fbb5287e209 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 git#10 0x7fbb5287e2bb in __libc_start_main csu/../csu/libc-start.c:389:3 git#11 0x55e40aaac130 in _start (/home/avar/g/git/git+0x4d130) (BuildId: b89fa8f797ccb02ef1148beed300071a5f9b9ab1) SUMMARY: LeakSanitizer: 9 byte(s) leaked in 1 allocation(s). Aborted Whatever clang has to say about it it makes sense to save ourselves the xmemdupz() if we can help it, but it's worth noting why this came up. The actual meaningful fix here is that we don't need to do this allocation at all. The only reason it's needed is because there hasn't been a variant of "sq_quote_buf()" in quote.c that takes a "len" parameter. In previous commits we added one, and will move to using it in the subsequent commit, but let's first make this smaller change. 1. https://lore.kernel.org/git/220218.861r00ib86.gmgdl@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
avar
added a commit
that referenced
this pull request
May 1, 2023
For those tests that have 1 occurances of 'test_i18ngrep', replace it with 'grep'. Splitting this incremental conversion by number of occurances in the file is arbitrary, but help so keep the commit size down. The 'test_i18ngrep' wrapper has been deprecated since d162b25 (tests: remove support for GIT_TEST_GETTEXT_POISON, 2021-01-20). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi!
I finally got around to update the Swedish translation, as per your request in July. Due to various personal reasons - one of which documented at http://www.softwolves.pp.se/blog/2011-07-04 - it took a bit longer than necessary, sorry about that.
// Peter