CVE-2024-32020

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, local clones may end up hardlinking files into the target repository's object database when source and target repository reside on the same disk. If the source repository is owned by a different user, then those hardlinked files may be rewritten at any point in time by the untrusted user. Cloning local repositories will cause Git to either copy or hardlink files of the source repository into the target repository. This significantly speeds up such local clones compared to doing a "proper" clone and saves both disk space and compute time. When cloning a repository located on the same disk that is owned by a different user than the current user we also end up creating such hardlinks. These files will continue to be owned and controlled by the potentially-untrusted user and can be rewritten by them at will in the future. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4.

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.

Security Fix(es):

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, repositories with submodules can be crafted in a way that exploits a bug in Git whereby it can be fooled into writing files not into the submodule's worktree but into a .git/ directory. This allows writing a hook that will be executed while the clone operation is still running, giving the user no opportunity to inspect the code that is being executed. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. If symbolic link support is disabled in Git (e.g. via git config --global core.symlinks false), the described attack won't work. As always, it is best to avoid cloning repositories from untrusted sources.(CVE-2024-32002)

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, an attacker can prepare a local repository in such a way that, when cloned, will execute arbitrary code during the operation. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. As a workaround, avoid cloning repositories from untrusted sources.(CVE-2024-32004)

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, local clones may end up hardlinking files into the target repository's object database when source and target repository reside on the same disk. If the source repository is owned by a different user, then those hardlinked files may be rewritten at any point in time by the untrusted user. Cloning local repositories will cause Git to either copy or hardlink files of the source repository into the target repository. This significantly speeds up such local clones compared to doing a "proper" clone and saves both disk space and compute time. When cloning a repository located on the same disk that is owned by a different user than the current user we also end up creating such hardlinks. These files will continue to be owned and controlled by the potentially-untrusted user and can be rewritten by them at will in the future. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4.(CVE-2024-32020)

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, when cloning a local source repository that contains symlinks via the filesystem, Git may create hardlinks to arbitrary user-readable files on the same filesystem as the target repository in the objects/ directory. Cloning a local repository over the filesystem may creating hardlinks to arbitrary user-owned files on the same filesystem in the target Git repository's objects/ directory. When cloning a repository over the filesystem (without explicitly specifying the file:// protocol or --no-local), the optimizations for local cloning will be used, which include attempting to hard link the object files instead of copying them. While the code includes checks against symbolic links in the source repository, which were added during the fix for CVE-2022-39253, these checks can still be raced because the hard link operation ultimately follows symlinks. If the object on the filesystem appears as a file during the check, and then a symlink during the operation, this will allow the adversary to bypass the check and create hardlinks in the destination objects directory to arbitrary, user-readable files. The problem has been patched in…

Root has patched CVE-2024-32020 in the git package for Root:Debian:11. Multiple fixed versions available.

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, local clones may end up hardlinking files into the target repository's object database when source and target repository reside on the same disk. If the source repository is owned by a different user, then those hardlinked files may be rewritten at any point in time by the untrusted user. Cloning local repositories will cause Git to either copy or hardlink files of the source repository into the target repository. This significantly speeds up such local clones compared to doing a "proper" clone and saves both disk space and compute time. When cloning a repository located on the same disk that is owned by a different user than the current user we also end up creating such hardlinks. These files will continue to be owned and controlled by the potentially-untrusted user and can be rewritten by them at will in the future. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4.

Git is a distributed revision control system with a decentralized architecture. As opposed to centralized version control systems with a client-server model, Git ensures that each working copy of a Git repository is an exact copy with complete revision history. This not only allows the user to work on and contribute to projects without the need to have permission to push the changes to their official repositories, but also makes it possible for the user to work with no network connection.

Security Fix(es):

• git: Recursive clones RCE (CVE-2024-32002)
• git: RCE while cloning local repos (CVE-2024-32004)
• git: additional local RCE (CVE-2024-32465)
• git: insecure hardlinks (CVE-2024-32020)
• git: symlink bypass (CVE-2024-32021)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer the CVE page(s) listed in the References section.

Git is a distributed revision control system with a decentralized architecture. As opposed to centralized version control systems with a client-server model, Git ensures that each working copy of a Git repository is an exact copy with complete revision history. This not only allows the user to work on and contribute to projects without the need to have permission to push the changes to their official repositories, but also makes it possible for the user to work with no network connection.

Security Fix(es):

• git: Recursive clones RCE (CVE-2024-32002)
• git: RCE while cloning local repos (CVE-2024-32004)
• git: additional local RCE (CVE-2024-32465)
• git: insecure hardlinks (CVE-2024-32020)
• git: symlink bypass (CVE-2024-32021)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer the CVE page(s) listed in the References section.

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, local clones may end up hardlinking files into the target repository's object database when source and target repository reside on the same disk. If the source repository is owned by a different user, then those hardlinked files may be rewritten at any point in time by the untrusted user. Cloning local repositories will cause Git to either copy or hardlink files of the source repository into the target repository. This significantly speeds up such local clones compared to doing a "proper" clone and saves both disk space and compute time. When cloning a repository located on the same disk that is owned by a different user than the current user we also end up creating such hardlinks. These files will continue to be owned and controlled by the potentially-untrusted user and can be rewritten by them at will in the future. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4.

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, local clones may end up hardlinking files into the target repository's object database when source and target repository reside on the same disk. If the source repository is owned by a different user, then those hardlinked files may be rewritten at any point in time by the untrusted user. Cloning local repositories will cause Git to either copy or hardlink files of the source repository into the target repository. This significantly speeds up such local clones compared to doing a "proper" clone and saves both disk space and compute time. When cloning a repository located on the same disk that is owned by a different user than the current user we also end up creating such hardlinks. These files will continue to be owned and controlled by the potentially-untrusted user and can be rewritten by them at will in the future. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4.

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, local clones may end up hardlinking files into the target repository's object database when source and target repository reside on the same disk. If the source repository is owned by a different user, then those hardlinked files may be rewritten at any point in time by the untrusted user. Cloning local repositories will cause Git to either copy or hardlink files of the source repository into the target repository. This significantly speeds up such local clones compared to doing a "proper" clone and saves both disk space and compute time. When cloning a repository located on the same disk that is owned by a different user than the current user we also end up creating such hardlinks. These files will continue to be owned and controlled by the potentially-untrusted user and can be rewritten by them at will in the future. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4.

• SECURITY UPDATE: When performing a local clone of a repository we end up either copying or hardlinking the source repository into the target repository.
  • debian/patches/CVE-2024-32020.patch: builtin/clone: refuse local clones of unsafe repositories
  • CVE-2024-32020

• SECURITY UPDATE: When performing a local clone of a repository we end up either copying or hardlinking the source repository into the target repository.
  • debian/patches/CVE-2024-32020.patch: builtin/clone: refuse local clones of unsafe repositories
  • CVE-2024-32020

• CVE-2024-32020: fix issue where local clones may hardlink files into target repository's object database when owned by different user
• CVE-2024-32021: fix issue with hardlinks to arbitrary user-readable files when cloning local source repository containing symlinks

• CVE-2024-32020: refuse local clones of unowned repositories to prevent TOCTOU race conditions

Updated Git to version 2.41.1 to fix CVE-2024-32002 CVE-2024-32004 CVE-2024-32020 CVE-2024-32021 CVE-2024-32465

These are all security issues fixed in the git-2.45.1-1.1 package on the GA media of openSUSE Tumbleweed.

Git is a distributed revision control system with a decentralized architecture. As opposed to centralized version control systems with a client-server model, Git ensures that each working copy of a Git repository is an exact copy with complete revision history. This not only allows the user to work on and contribute to projects without the need to have permission to push the changes to their official repositories, but also makes it possible for the user to work with no network connection.

Security Fix(es):

• git: Recursive clones RCE (CVE-2024-32002)

• git: RCE while cloning local repos (CVE-2024-32004)

• git: additional local RCE (CVE-2024-32465)

• git: insecure hardlinks (CVE-2024-32020)

• git: symlink bypass (CVE-2024-32021)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer the CVE page(s) listed in the References section.

Git is a distributed revision control system with a decentralized architecture. As opposed to centralized version control systems with a client-server model, Git ensures that each working copy of a Git repository is an exact copy with complete revision history. This not only allows the user to work on and contribute to projects without the need to have permission to push the changes to their official repositories, but also makes it possible for the user to work with no network connection.

Security Fix(es):

• git: Recursive clones RCE (CVE-2024-32002)

• git: RCE while cloning local repos (CVE-2024-32004)

• git: additional local RCE (CVE-2024-32465)

• git: insecure hardlinks (CVE-2024-32020)

• git: symlink bypass (CVE-2024-32021)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer the CVE page(s) listed in the References section.

This update for git fixes the following issues:

• CVE-2024-32002: Fixed recursive clones on case-insensitive filesystems that support symbolic links are susceptible to case confusion (bsc#1224168).
• CVE-2024-32004: Fixed arbitrary code execution during local clones (bsc#1224170).
• CVE-2024-32020: Fixed file overwriting vulnerability during local clones (bsc#1224171).
• CVE-2024-32021: Fixed git may create hardlinks to arbitrary user-readable files (bsc#1224172).
• CVE-2024-32465: Fixed arbitrary code execution during clone operations (bsc#1224173).

This update for git fixes the following issues:

• CVE-2024-32002: Fixed recursive clones on case-insensitive filesystems that support symbolic links are susceptible to case confusion (bsc#1224168).
• CVE-2024-32004: Fixed arbitrary code execution during local clones (bsc#1224170).
• CVE-2024-32020: Fixed file overwriting vulnerability during local clones (bsc#1224171).
• CVE-2024-32021: Fixed git may create hardlinks to arbitrary user-readable files (bsc#1224172).
• CVE-2024-32465: Fixed arbitrary code execution during clone operations (bsc#1224173).

This update for git fixes the following issues:

• CVE-2024-32002: Fixed case confusion with recursive clones on case-insensitive filesystems that support symbolic links (bsc#1224168)
• CVE-2024-32004: Fixed arbitrary code execution during local clones (bsc#1224170)
• CVE-2024-32020: Fixed file overwriting vulnerability during local clones (bsc#1224171)
• CVE-2024-32021: Fixed issue where git created hardlinks to arbitrary user-readable files (bsc#1224172)
• CVE-2024-32465: Fixed arbitrary code execution during clone operations (bsc#1224173)

This update for git fixes the following issues:

• CVE-2024-32002: Fix recursive clones on case-insensitive filesystems that support symbolic links are susceptible to case confusion. (bsc#1224168)
• CVE-2024-32004: Fixed arbitrary code execution during local clones. (bsc#1224170)
• CVE-2024-32020: Fix file overwriting vulnerability during local clones. (bsc#1224171)
• CVE-2024-32021: Git may create hardlinks to arbitrary user-readable files. (bsc#1224172)
• CVE-2024-32465: Fixed arbitrary code execution during clone operations. (bsc#1224173)

This update for git fixes the following issues:

• CVE-2024-32002: Fix recursive clones on case-insensitive filesystems that support symbolic links are susceptible to case confusion. (bsc#1224168)
• CVE-2024-32004: Fixed arbitrary code execution during local clones. (bsc#1224170)
• CVE-2024-32020: Fix file overwriting vulnerability during local clones. (bsc#1224171)
• CVE-2024-32021: Git may create hardlinks to arbitrary user-readable files. (bsc#1224172)
• CVE-2024-32465: Fixed arbitrary code execution during clone operations. (bsc#1224173)
• CVE-2024-50349: Passwords for trusted sites could be sent to untrusted sites (bsc#1235600).
• CVE-2024-52006: Carriage Returns via the credential protocol to credential helpers (bsc#1235601).

This update for git fixes the following issues:

git was updated to 2.45.1:

• CVE-2024-32002: recursive clones on case-insensitive filesystems that support symbolic links are susceptible to case confusion (bsc#1224168)
• CVE-2024-32004: arbitrary code execution during local clones (bsc#1224170)
• CVE-2024-32020: file overwriting vulnerability during local clones (bsc#1224171)
• CVE-2024-32021: git may create hardlinks to arbitrary user- readable files (bsc#1224172)
• CVE-2024-32465: arbitrary code execution during clone operations (bsc#1224173)

Update to 2.45.0:

• Improved efficiency managing repositories with many references ("git init --ref-format=reftable")
• "git checkout -p" and friends learned that that "@" is a synonym for "HEAD"
• cli improvements handling refs
• Expanded a number of commands and options, UI improvements
• status.showUntrackedFiles now accepts "true"
• git-cherry-pick(1) now automatically drops redundant commits with new --empty option
• The userdiff patterns for C# has been updated.

Update to 2.44.0:

• "git checkout -B <branch>" now longer allows switching to a branch that is in use on another worktree. The users need to use "--ignore-other-worktrees" option.
• Faster server-side rebases with git replay
• Faster pack generation with multi-pack reuse
• rebase auto-squashing now works in non-interactive mode
• pathspec now understands attr, e.g. ':(attr:~binary) for selecting non-binaries, or builtin_objectmode for selecting items by file mode or other properties
• Many other cli UI and internal improvements and extensions

• Do not replace apparmor configuration, fixes bsc#1216545

Update to 2.43.2:

• https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.43.2.txt
• Update to a new feature recently added, "git show-ref --exists".
• Rename detection logic ignored the final line of a file if it is an incomplete line.
• "git diff --no-rename A B" did not disable rename detection but did not trigger an error from the command line parser.
• "git diff --no-index file1 file2" segfaulted while invoking the external diff driver, which has been corrected.
• A failed "git tag -s" did not necessarily result in an error depending on the crypto backend, which has been corrected.
• "git stash" sometimes was silent even when it failed due to unwritable index file, which has been corrected.
• Recent conversion to allow more than 0/1 in GIT_FLUSH broke the mechanism by flipping what yes/no means by mistake, which has been corrected.

Update to 2.43.1:

• https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.43.1.txt

• gitweb AppArmor profile: allow reading etc/gitweb-common.conf (bsc#1218664)

• git moved to /usr/libexec/git/git, update AppArmor profile accordingly (bsc#1218588)

Update to 2.43.0:

• The "--rfc" option of "git format-patch" used to be a valid way to override an earlier "--subject-prefix=<something>" on the command line and replace it with "[RFC PATCH]", but from this release, it merely prefixes the string "RFC " in front of the given subject prefix. If you are negatively affected by this change, please use "--subject-prefix=PATCH --rfc" as a replacement.
• In Git 2.42, "git rev-list --stdin" learned to take non-revisions (like "--not") from the standard input, but the way such a "--not" was handled was quite confusing, which has been rethought. The updated rule is that "--not" given from the command line only affects revs given from the command line that comes but not revs read from the standard input, and "--not" read from the standard input affects revs given from the standard input and not revs given from the command line.
• A message written in olden time prevented a branch from getting checked out, saying it is already checked out elsewhere. But these days, we treat a branch that…

It was discovered that Git incorrectly handled certain submodules. An attacker could possibly use this issue to execute arbitrary code. This issue was fixed in Ubuntu 22.04 LTS, Ubuntu 23.10 and Ubuntu 24.04 LTS. (CVE-2024-32002)

It was discovered that Git incorrectly handled certain cloned repositories. An attacker could possibly use this issue to execute arbitrary code. (CVE-2024-32004)

It was discovered that Git incorrectly handled local clones with hardlinked files/directories. An attacker could possibly use this issue to place a specialized repository on their target's local system. (CVE-2024-32020)

It was discovered that Git incorrectly handled certain symlinks. An attacker could possibly use this issue to impact availability and integrity creating hardlinked arbitrary files into users repository's objects/directory. (CVE-2024-32021)

It was discovered that Git incorrectly handled certain cloned repositories. An attacker could possibly use this issue to execute arbitrary code. (CVE-2024-32465)

Maxime Escourbiac and Yassine Bengana discovered that Git incorrectly handled some gettext machinery. An attacker could possibly use this issue to allows the malicious placement of crafted messages. This issue was fixed in Ubuntu 16.04 LTS. (CVE-2023-25815)

It was discovered that Git incorrectly handled certain submodules. An attacker could possibly use this issue to execute arbitrary code. This issue was fixed in Ubuntu 18.04 LTS. (CVE-2024-32002)

It was discovered that Git incorrectly handled certain cloned repositories. An attacker could possibly use this issue to execute arbitrary code. This issue was fixed in Ubuntu 18.04 LTS. (CVE-2024-32004, CVE-2024-32465)

It was discovered that Git incorrectly handled local clones with hardlinked files/directories. An attacker could possibly use this issue to place a specialized repository on their target’s local system. This issue was fixed in Ubuntu 18.04 LTS. (CVE-2024-32020)

It was discovered that Git incorrectly handled certain symlinks. An attacker could possibly use this issue to impact availability and integrity creating hardlinked arbitrary files into users repository’s objects/directory. This issue was fixed in Ubuntu 18.04 LTS. (CVE-2024-32021)