PIPE-10452 Regex fix in DSAclean#10
Draft
SB-PawanN wants to merge 1 commit into
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description:
Resolves SAST finding PIPE-10452 (CWE-1333 / CWE-400 / CWE-730) — Inefficient Regular Expression susceptible to catastrophic backtracking (ReDoS).
Root Cause:
The regex on line 23 used a nested quantifier pattern (.\w*)* where a group with * is wrapped in another *. This creates exponential backtracking paths on non-matching inputs, leading to potential CPU exhaustion / denial of service.
Changes:
Replaced the vulnerable regex re.compile("label(\s*)=(\s*)"\s%tmp(.\w*)(\s)"") with a safe, pre-compiled version.
Moved re.compile() outside the loop to avoid recompilation on every iteration (performance improvement).
Removed unnecessary capturing groups.
Why this is safe:
[.\w]* uses a character class (linear-time matching) instead of nested quantifiers — no backtracking ambiguity.
. inside [.\w] is a literal dot, matching the same real-world inputs as the original pattern. LLVM DSA dot output only produces identifier-like tmp labels (dots, letters, digits, underscores), so the slight semantic difference (e.g., permitting consecutive dots) has no practical impact.
The surrounding anchors (label\s*=\s*"\s%tmp) prevent false positives.
Loop logic (skip label line + next line, or write current line) is preserved exactly as before.
Testing:
Verified regex matches all valid DSA tmp label patterns: %tmp, %tmp.1, %tmp.foo.bar, %tmp.1.i.3
Confirmed no behavioral change for real-world LLVM DSA dot output.
Validated with SAST tooling that the new pattern is not flagged.