Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Stack-overflow via deep JSON array nesting under ASan+-O0, below CJSON_NESTING_LIMIT

オープン 初心者向け
  • 何か問題がありますか？
#1,093 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 12 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
68/100
issue の種類
ドキュメント
明瞭さ
おおむね明確
活発さ
活発
技術スタック
c
領域
documentation

調査の方向性

cJSON.cでCJSON_NESTING_LIMITと、それに関する既存のドキュメントまたはコメントを探すところから始めてください。報告されたsanitizerの再現コードとビルドの詳細を確認し、実効的な安全なネスト深度はビルド構成、特に-O0およびASan下での構成に依存することを文書化してください。fuzzingおよびsanitizerのユーザーにこの前提が明確に伝わるよう、制限のドキュメントに記載できたら作業完了です。

索引モデルが issue の本文から書いたものです。

説明

Summary

Under an ASan + -O0 build (the standard configuration for fuzzing/CI sanitizer runs), a deeply nested JSON array triggers a native stack overflow before CJSON_NESTING_LIMIT (1000) is ever reached, because the limit bounds the number of recursive parser calls but not the size of each call's stack frame, and ASan instrumentation plus disabled optimization inflate that frame size substantially.

This is not an exploitable issue in a normal optimized release build (verified below) — filing this as a robustness/documentation note, not a security report.

Repro

Minimized input: a JSON value consisting of 755 consecutive [ bytes, no closing brackets, no other content.

$ ./cjson_asan_o0 < deepnest_755.json
==PID==ERROR: AddressSanitizer: stack-overflow on address 0x...
    <empty stack>
SUMMARY: AddressSanitizer: stack-overflow

(No symbolized backtrace — ASan's own crash-reporting code cannot run once the stack is this exhausted, which is typical for pure stack-overflow crashes as opposed to heap-buffer-overflow.)

Build used to reproduce: cJSON.c compiled with -O0 -fsanitize=address -g, default thread/process stack size (8 MiB on the Linux machine used here). Binary search found the exact boundary on that machine: 754 levels of [ is parsed/rejected cleanly (cJSON_ParseWithLength returns NULL), 755 crashes.

Why the existing limit does not catch it here

CJSON_NESTING_LIMIT counts recursive calls, not stack bytes consumed. Under -O0, every local gets its own stack slot (no register allocation), and ASan adds redzone padding around each stack allocation. The combined per-call frame size under this build is large enough that the process stack is exhausted well before the 1000-call counter would reject the input.

Confirms it is release-build-safe

The same inputs (780, 1000, 1500, 5000, 50000 levels of [) were tested against an identical harness built -O2, no sanitizers: all are rejected cleanly, exit code 0, no crash, in every case. The nesting limit does its job as documented in a normal build; the gap only appears under sanitizer instrumentation.

Suggested fix

Options, roughly in order of effort:

  • Note in the CJSON_NESTING_LIMIT documentation that the effective safe depth is build-configuration-dependent (much lower under -O0/ASan/MSan than in an optimized release build), so people fuzzing or testing cJSON with sanitizers know a stack-overflow at a shallower depth than 1000 is expected, not a new bug.
  • Optionally lower the default limit, or make it configurable relative to a measured/available stack size, if protecting sanitizer/debug builds against this specific crash is a goal.

Happy to share the exact harness and inputs if useful. Reported by an independent fuzzing exercise, no CVE requested given the release-build behavior is correct.

主要言語
C
スター
13k
フォーク
3.5k
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

DaveGamble/cJSON のほかの issue

DaveGamble/cJSON の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。