git, branch v2.43.7

Git 2.43.7

2025-05-28T18:42:12Z

Signed-off-by: Taylor Blau

Merge branch 'tb/wincred-buffer-overflow' into maint-2.43

2025-05-28T18:33:35Z

This merges in the fix for CVE-2025-48386. * tb/wincred-buffer-overflow: wincred: avoid buffer overflow in wcsncat() Signed-off-by: Taylor Blau

wincred: avoid buffer overflow in wcsncat()

2025-05-28T16:57:36Z

The wincred credential helper uses a static buffer ("target") as a unique key for storing and comparing against internal storage. It does this by building up a string is supposed to look like: git:$PROTOCOL://$USERNAME@$HOST/@PATH However, the static "target" buffer is declared as a wide string with no more than 1,024 wide characters. The first call to wcsncat() is almost correct (it copies no more than ARRAY_SIZE(target) wchar_t's), but does not account for the trailing NUL, introducing an off-by-one error. But subsequent calls to wcsncat() have an additional problem on top of the off-by-one. They do not account for the length of the existing wide string being built up in 'target'. So the following: $ perl -e ' my $x = "x" x 1_000; print "protocol=$x\nhost=$x\nusername=$x\npath=$x\n" ' | C\:/Program\ Files/Git/mingw64/libexec/git-core/git-credential-wincred.exe get will result in a segmentation fault from over-filling buffer. This bug is as old as the wincred helper itself, dating back to a6253da0f3 (contrib: add win32 credential-helper, 2012-07-27). Commit 8b2d219a3d (wincred: improve compatibility with windows versions, 2013-01-10) replaced the use of strncat() with wcsncat(), but retained the buggy behavior. Fix this by using a "target_append()" helper which accounts for both the length of the existing string within the buffer, as well as the trailing NUL character. Reported-by: David Leadbeater Helped-by: David Leadbeater Helped-by: Jeff King Signed-off-by: Taylor Blau

Merge branch 'jt/config-quote-cr' into maint-2.43

2025-05-28T16:55:15Z

This merges in the fix for CVE-2025-48384. * jt/config-quote-cr: config: quote values containing CR character Signed-off-by: Taylor Blau

Merge branch 'ps/bundle-uri-arbitrary-writes' into maint-2.43

2025-05-28T16:54:03Z

This merges in the fix for CVE-2025-48385. * ps/bundle-uri-arbitrary-writes: bundle-uri: fix arbitrary file writes via parameter injection Signed-off-by: Taylor Blau

Merge branch 'js/gitk-git-gui-harden-exec-open' into maint-2.43

2025-05-28T16:48:38Z

This merges in fixes for CVE-2025-27614, CVE-2025-27613, CVE-2025-46334, and CVE-2025-46835 targeting Gitk and Git GUI. * js/gitk-git-gui-harden-exec-open: (41 commits) git-gui: sanitize 'exec' arguments: convert new 'cygpath' calls git-gui: do not mistake command arguments as redirection operators git-gui: introduce function git_redir for git calls with redirections git-gui: pass redirections as separate argument to git_read git-gui: pass redirections as separate argument to _open_stdout_stderr git-gui: convert git_read*, git_write to be non-variadic git-gui: override exec and open only on Windows gitk: sanitize 'open' arguments: revisit recently updated 'open' calls git-gui: use git_read in githook_read git-gui: sanitize $PATH on all platforms git-gui: break out a separate function git_read_nice git-gui: assure PATH has only absolute elements. git-gui: remove option --stderr from git_read git-gui: cleanup git-bash menu item git-gui: sanitize 'exec' arguments: background git-gui: avoid auto_execok in do_windows_shortcut git-gui: sanitize 'exec' arguments: simple cases git-gui: avoid auto_execok for git-bash menu item git-gui: treat file names beginning with "|" as relative paths git-gui: remove unused proc is_shellscript git-gui: remove git config --list handling for git < 1.5.3 git-gui: remove special treatment of Windows from open_cmd_pipe git-gui: remove HEAD detachment implementation for git < 1.5.3 git-gui: use only the configured shell git-gui: remove Tcl 8.4 workaround on 2>@1 redirection git-gui: make _shellpath usable on startup git-gui: use [is_Windows], not bad _shellpath git-gui: _which, only add .exe suffix if not present gitk: encode arguments correctly with "open" gitk: sanitize 'open' arguments: command pipeline gitk: collect construction of blameargs into a single conditional gitk: sanitize 'open' arguments: simple commands, readable and writable gitk: sanitize 'open' arguments: simple commands with redirections gitk: sanitize 'open' arguments: simple commands gitk: sanitize 'exec' arguments: redirect to process gitk: sanitize 'exec' arguments: redirections and background gitk: sanitize 'exec' arguments: redirections gitk: sanitize 'exec' arguments: 'eval exec' gitk: sanitize 'exec' arguments: simple cases gitk: have callers of diffcmd supply pipe symbol when necessary gitk: treat file names beginning with "|" as relative paths ... Signed-off-by: Taylor Blau

bundle-uri: fix arbitrary file writes via parameter injection

2025-05-23T21:09:48Z

We fetch bundle URIs via `download_https_uri_to_file()`. The logic to fetch those bundles is not handled in-process, but we instead use a separate git-remote-https(1) process that performs the fetch for us. The information about which file should be downloaded and where that file should be put gets communicated via stdin of that process via a "get" request. This "get" request has the form "get $uri $file\n\n". As may be obvious to the reader, this will cause git-remote-https(1) to download the URI "$uri" and put it into "$file". The fact that we are using plain spaces and newlines as separators for the request arguments means that we have to be extra careful with the respective vaules of these arguments: - If "$uri" contained a space we would interpret this as both URI and target location. - If either "$uri" or "$file" contained a newline we would interpret this as a new command. But we neither quote the arguments such that any characters with special meaning would be escaped, nor do we verify that none of these special characters are contained. If either the URI or file contains a newline character, we are open to protocol injection attacks. Likewise, if the URI itself contains a space, then an attacker-controlled URI can lead to partially-controlled file writes. Note that the attacker-controlled URIs do not permit completely arbitrary file writes, but instead allows an attacker to control the path in which we will write a temporary (e.g., "tmp_uri_XXXXXX") file. The result is twofold: - By adding a space in "$uri" we can control where exactly a file will be written to, including out-of-repository writes. The final location is not completely arbitrary, as the injected string will be concatenated with the original "$file" path. Furthermore, the name of the bundle will be "tmp_uri_XXXXXX", further restricting what an adversary would be able to write. Also note that is not possible for the URI to contain a newline because we end up in `credential_from_url_1()` before we try to issue any requests using that URI. As such, it is not possible to inject arbitrary commands via the URI. - By adding a newline to "$file" we can inject arbitrary commands. This gives us full control over where a specific file will be written to. Potential attack vectors would be to overwrite hooks, but if an adversary were to guess where the user's home directory is located they might also easily write e.g. a "~/.profile" file and thus cause arbitrary code execution. This injection can only become possible when the adversary has full control over the target path where a bundle will be downloaded to. While this feels unlikely, it is possible to control this path when users perform a recursive clone with a ".gitmodules" file that is controlled by the adversary. Luckily though, the use of bundle URIs is not enabled by default in Git clients (yet): they have to be enabled by setting the `bundle.heuristic` config key explicitly. As such, the blast radius of this parameter injection should overall be quite contained. Fix the issue by rejecting spaces in the URI and newlines in both the URI and the file. As explained, it shouldn't be required to also restrict the use of newlines in the URI, as we would eventually die anyway in `credential_from_url_1()`. But given that we're only one small step away from arbitrary code execution, let's rather be safe and restrict newlines in URIs, as well. Eventually we should probably refactor the way that Git talks with the git-remote-https(1) subprocess so that it is less fragile. Until then, these two restrictions should plug the issue. Reported-by: David Leadbeater Based-on-patch-by: David Leadbeater Signed-off-by: Patrick Steinhardt Signed-off-by: Taylor Blau

config: quote values containing CR character

2025-05-23T21:07:55Z

When reading the config, values that contain a trailing CRLF are stripped. If the value itself has a trailing CR, the normal LF that follows results in the CR being unintentionally stripped. This may lead to unintended behavior due to the config value written being different when it gets read. One such issue involves a repository with a submodule path containing a trailing CR. When the submodule gets initialized, the submodule is cloned without being checked out and has "core.worktree" set to the submodule path. The git-checkout(1) that gets spawned later reads the "core.worktree" config value, but without the trailing CR, and consequently attempts to checkout to a different path than intended. If the repository contains a matching path that is a symlink, it is possible for the submodule repository to be checked out in arbitrary locations. This is extra bad when the symlink points to the submodule hooks directory and the submodule repository contains an executable "post-checkout" hook. Once the submodule repository checkout completes, the "post-checkout" hook immediately executes. To prevent mismatched config state due to misinterpreting a trailing CR, wrap config values containing CR in double quotes when writing the entry. This ensures a trailing CR is always separated for an LF and thus prevented from getting stripped. Note that this problem cannot be addressed by just quoting each CR with "\r". The reading side of the config interprets only a few backslash escapes, and "\r" is not among them. This fix is sufficient though because it only affects the CR at the end of a line and any literal CR in the interior is already preserved. Co-authored-by: David Leadbeater Signed-off-by: Justin Tobler Signed-off-by: Taylor Blau

Merge branch 'js/fix-open-exec'

2025-05-23T21:04:31Z

This addresses CVE-2025-46835, Git GUI can create and overwrite a user's files: When a user clones an untrusted repository and is tricked into editing a file located in a maliciously named directory in the repository, then Git GUI can create and overwrite files for which the user has write permission. Signed-off-by: Johannes Sixt

Merge branch 'ml/replace-auto-execok'

2025-05-23T21:04:30Z

This addresses CVE-2025-46334, Git GUI malicious command injection on Windows. A malicious repository can ship versions of sh.exe or typical textconv filter programs such as astextplain. Due to the unfortunate design of Tcl on Windows, the search path when looking for an executable always includes the current directory. The mentioned programs are invoked when the user selects "Git Bash" or "Browse Files" from the menu. Signed-off-by: Johannes Sixt