Skip to content

gpl: Fix multiple out-of-bounds, null dereference, and UB bugs in MBFF#10750

Open
calewis wants to merge 2 commits into
The-OpenROAD-Project:masterfrom
calewis:fix-mbff-ub-safety
Open

gpl: Fix multiple out-of-bounds, null dereference, and UB bugs in MBFF#10750
calewis wants to merge 2 commits into
The-OpenROAD-Project:masterfrom
calewis:fix-mbff-ub-safety

Conversation

@calewis

@calewis calewis commented Jun 24, 2026

Copy link
Copy Markdown
Collaborator

Fix UB in the mbff code, note I don't full understand what this code is trying to do, I tried to pick what I thought were reasonable fixes in cases like where we would have indexed past the end of an array, but i'm not super confident in my choices so hopefully someone who is comfortable with this code can double check my UB avoiding solutions.

@calewis calewis requested a review from a team as a code owner June 24, 2026 16:33
@calewis calewis requested a review from LucasYuki June 24, 2026 16:33
@calewis calewis force-pushed the fix-mbff-ub-safety branch from d7d8f07 to 64bb23d Compare June 24, 2026 16:33

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces several robustness improvements to src/gpl/src/mbff.cpp to prevent out-of-bounds array accesses and null pointer dereferences during library reading. Key changes include adding checks for null cells, validating slot counts, verifying pin lookups, and simplifying slot coordinate calculations when pins are missing. The review feedback points out that the error-handling check for GetBitIdx returning -1 is redundant because logger_->error already terminates the program, and suggests using float literals (2.0f instead of 2.0) to avoid unnecessary double-precision promotions during coordinate calculations.

Comment thread src/gpl/src/mbff.cpp Outdated
Comment thread src/gpl/src/mbff.cpp
@calewis calewis force-pushed the fix-mbff-ub-safety branch from 64bb23d to 971ef71 Compare June 24, 2026 17:01
- Add bounds checks on output pin vectors in GetPinMapping to handle asymmetric pin configurations.
- Validate that dbToSta and LibertyCell are non-null in ReadLibs before creating temporary test trays.
- Add explicit null checks and graceful warn-and-skip logic on DB ITerms (d_pin, q_pin, qn_pin) in ReadLibs before calling getBBox() to prevent dereferencing null pointers.
- Prevent out-of-bounds access on d vector in ReadLibs by verifying that d.size() is at least num_slots.
- Prevent out-of-bounds access on q and qn vectors in ReadLibs' slot geometry loop by adding bounds checks and falling back to d coordinates.
- Utilize single-precision float division literals (2.0f) in GetTrayCenter and slot geometry calculations to avoid unnecessary double promotions/demotions.

Signed-off-by: Drew Lewis <cannada@google.com>
@calewis calewis force-pushed the fix-mbff-ub-safety branch from 971ef71 to 7de82da Compare June 24, 2026 17:01
@github-actions github-actions Bot added size/S and removed size/M labels Jun 24, 2026
Signed-off-by: Drew Lewis <cannada@google.com>
@maliberty

Copy link
Copy Markdown
Member

@codex review

Comment thread src/gpl/src/mbff.cpp
ret[d_pins[i]] = {nullptr, qn_pins[i]};
}
for (size_t i = 0; i < d_pins.size(); i++) {
// Avoid out-of-bounds access if the cell has asymmetric output pin counts.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How could this happen for an MBFF? The bits are supposed to be symmetric. Is this a real problem or just a hypothetical one from a code analysis tool?

Comment thread src/gpl/src/mbff.cpp
= (p.second.qn ? tmp_tray->findITerm(p.second.qn->name().c_str())
: nullptr);

if (d_pin == nullptr) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this just defensive programming? The tray candidate should never mismatch like this so it seems redundant.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f32e64c5fb

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread src/gpl/src/mbff.cpp
Comment on lines +347 to +350
const sta::LibertyPort* q_pin = (i < q_pins.size()) ? q_pins[i] : nullptr;
const sta::LibertyPort* qn_pin
= (i < qn_pins.size()) ? qn_pins[i] : nullptr;
ret[d_pins[i]] = {q_pin, qn_pin};

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Reject trays with missing output pins

When a tray has both Q and QN overall but fewer pins of one polarity than D, dbNetwork::isValidTray still accepts it because it only requires #D == max(q, qn). This padding records nullptr for the missing per-slot output while GetArrayMask still advertises that the tray supports both outputs, so if the ILP assigns a flop with that missing output to such a slot, ModifyPinConnections later dereferences q_pin/qn_pin while reconnecting the original output net and MBFF can crash instead of rejecting the candidate. Please discard candidates or slots that cannot provide all outputs required by the mask rather than padding them with nulls.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants