You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug] pin_api_attach_irq legacy path publishes hdr and args without IRQ protection #11784
This issue affects any board where the GPIO controller does not implement the pin_attach_irq operation, forcing the code to fall back to the legacy ISR handler path.
Develop Toolchain
Other
Describe the bug
In components/drivers/pin/dev_pin_dm.c, when gpio->ops->pin_attach_irq is NULL (legacy fallback path), the function pin_api_attach_irq() writes the handler pair without masking IRQs:
legacy_isr->hdr=hdr;
legacy_isr->args=args;
Meanwhile, pin_pic_handle_isr() reads these fields from ISR context:
if (legacy_isr->hdr)
{
legacy_isr->hdr(legacy_isr->args);
}
Steps to reproduce the behavior
Race condition scenario:
Application calls pin_api_attach_irq() to update the pin interrupt handler
The function writes legacy_isr->hdr = new_handler
Before writing legacy_isr->args = new_args, a pin interrupt fires
pin_pic_handle_isr() executes and calls new_handler(old_args) with mismatched arguments
This can lead to:
Incorrect argument being passed to the new handler
Potential crashes if the new handler expects a different argument type/structure
Unpredictable behavior
Expected behavior
The handler function pointer and its argument should be updated atomically. Either both should reflect the old values, or both should reflect the new values. No intermediate state should be visible to the ISR.
Other additional context
Affected code path: This bug only applies to the legacy fallback path when the GPIO controller does not implement the pin_attach_irq operation. Modern controllers that provide this operation are not affected.
Root cause: The two stores (hdr and args) are not atomic. On any architecture, an interrupt can occur between them.
Suggested fix: Protect the critical section with IRQ masking:
For clarification, #11783 is the initial version of this report. I closed it after realizing that it did not follow the repository's bug issue template, and resubmitted the issue here using the proper template.
I can think of only two scenarios where you would call pin_api_attach_irq:
You are requesting a pin IRQ for the first time: this happens either when the target PIN is currently disabled, or when there is a bug in the existing implementation that needs to be fixed.
You are replacing an existing ISR: in this case, users are expected to disable the old IRQ before attaching the new ISR.
As long as the API is invoked correctly by the user, pin_api_attach_irq should always operate in an IRQ-safe state.
Activity
github-actions commentedon Sep 7, 2026
如需认领并处理此 Issue,请评论
/claim。To claim and work on this issue, comment
/claim.github-actions commentedon Sep 7, 2026
以下 Issue 可能与当前问题相关;这是自动检索结果,尚未确认重复:
The following issues may be related. These automated suggestions are not confirmed duplicates:
andrewlihhh commentedon Sep 7, 2026
For clarification, #11783 is the initial version of this report. I closed it after realizing that it did not follow the repository's bug issue template, and resubmitted the issue here using the proper template.
#11784 should be treated as the current report.
GuEe-GUI commentedon Sep 9, 2026
I can think of only two scenarios where you would call
pin_api_attach_irq:As long as the API is invoked correctly by the user,
pin_api_attach_irqshould always operate in an IRQ-safe state.