grep/fgrep has some bad code that segfaults

[guilt]

Existing issues matching what you're seeing

• I was not able to find an open or closed issue matching what I'm seeing

Git for Windows version

git version 2.49.0.windows.1
cpu: x86_64
built from commit: cca1f38702730b35f52c29efd62864b85e85ddcc
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
feature: fsmonitor--daemon
libcurl: 8.12.1
OpenSSL: OpenSSL 3.2.4 11 Feb 2025
zlib: 1.3.1

Windows version

Windows 11

Windows CPU architecture

x86_64 (64-bit)

Additional Windows version information

Microsoft Windows [Version 10.0.26100.4349]

Options set during installation

Editor Option: Notepad
Custom Editor Path:
Default Branch Option: main
Path Option: BashOnly
SSH Option: ExternalOpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFAlways
Bash Terminal Option: ConHost
Git Pull Behavior Option: FFOnly
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Enabled
Enable FSMonitor: Disabled

Other interesting things

Here is a firsthand reproducible set of commands that anyone can run in Git Bash:

This has been going for so long, I hope you actually ensure grep is up-to-date and fixed in your distribution of Git when shipping to people. There may be other outdated utilities with less than ideal code and it needs to be brought up-to-date.

The expected behavior of fgrep is to actually do case insensitive matching, so
is would still match both is and Isolated. On a Simple WSL Debian instance, you can see this.

Terminal/shell

Git Bash

Commands that trigger the issue

echo 'This is a Isolated test.' | tee test.txt
fgrep is test.txt
fgrep -i is test.txt

Expected behaviour

This is what should appear for the -i command:

This is a Isolated test.

Actual behaviour

Aborted

crash. Multiple times. This can be triggered on the grep binary with -F. fgrep is just a shell wrapper to your grep.

Repository

No response

[dscho]

Please test the latest snapshot.

[guilt]

The latest snapshot does not have this problem. I copied the grep.exe from PortableGit and am using it. Now it works for me. Will report later once if this problem happens again.

[dscho]

I suspect that the MSYS2 runtime fixes are responsible. Please run with v2.50.0-rc2 if the bug fix is urgent, otherwise wait for v2.50.0 (which is due this coming week).

[guilt]

Looking forward. This runtime fix may need to be backported to previous releases if there's a genuine security issue here. Thank you!

[dscho]

This runtime fix may need to be backported to previous releases if there's a genuine security issue here.

No. Git for Windows' security policy is very clear on that:

While Git maintains several release trains (when v2.19.1 was released, there were updates to v2.14.x-v2.18.x, too, for example), Git for Windows follows only the latest Git release. For example, there is no Git for Windows release corresponding to Git v2.16.5 (which was released after v2.19.0).

Git for Windows only services the newest major version.

Besides, you only demonstrated a crash ("Aborted" usually does not mean the same as "Segmentation fault", by the way, a more common cause is a violated assertion such as use-after-free), which is definitely not the same as a security issue.

[guilt]

The heads up was: I don't know what part of the runtime caused it - and if it is known later, an improper use of memory (including use after free) or something worse, could be exploited (often the real issue), it would be appropriate to backport. After reading the policy, it does look like MinGit (which I wasn't aware of until today) does have an exception against it and gets these patches.

Since grep.exe seems to be a part of MinGit, If this issue exists in older versions, which I am fairly certain it will, it might be easy enough for me to pick up any deployed fixes as part of MinGit older versions.

[dscho]

Heads-up: unless I am made aware of security issues with older MinGits' MSYS2 runtimes, MinGit backports won't update the MSYS2 runtime. The idea is that MinGit backports really only get security fixes, avoiding accidental regressions in other parts, minimizing the risk of upgrading older installations.