Bug: RTT/WDT callback setup can let overflow or early-warning IRQs use new callback state before setup finishes

[andrewlihhh]

Description

These RTT/WDT paths share the same basic issue: callback/context is updated first, while pending IRQ or peripheral event state may still fire.

Common sequence:

1. thread context updates overflow or early-warning callback state
2. pending IRQ or peripheral event state is not fully cleared yet
3. overflow / early-warning IRQ arrives in that window
4. ISR uses the new callback/context before setup has finished

Related issues:

• Tracking issue: #22405
• See also #22384, which discusses a similar issue shape in another RIOT driver.

Scope

• RIOT source snapshot: bbe5252d00f98658fc6493ede1a3e9f8f4102f9d (2026-06-08)
• Affected files:
  • cpu/esp32/periph/rtt.c
  • cpu/nrf5x_common/periph/rtt.c
  • cpu/sam0_common/periph/wdt.c
• Grouped cases:
  • esp32-rtt-unique-1-rtt-counter-overflow-cb
  • esp32-rtt-unique-2-rtt-counter-overflow-arg
  • esp32-rtt-unique-3-rtt-counter-overflow-cb
  • nrf5x-rtt-overflow-reinit-bug
  • samd5x-wdt-reinit-bug

Representative code paths

• ESP32 RTT: rtt_set_overflow_cb() / _rtt_update_hw_alarm() -> _rtt_isr()
• nRF5x RTT: rtt_set_overflow_cb() -> ISR()
• SAM0 WDT: wdt_setup_reboot_with_callback() -> isr_wdt()

Representative source snippets

cpu/esp32/periph/rtt.c updates overflow callback/context state:

void rtt_set_overflow_cb(rtt_cb_t cb, void *arg)
{
    rtt_counter.overflow_cb = cb;
    rtt_counter.overflow_arg = arg;
    _rtt_update_hw_alarm();
}

The RTT ISR later consumes that callback/context:

if (rtt_counter.overflow_cb) {
    rtt_counter.overflow_cb(rtt_counter.overflow_arg);
}

cpu/nrf5x_common/periph/rtt.c has the same overflow callback/context pattern:

void rtt_set_overflow_cb(rtt_cb_t cb, void *arg)
{
    overflow_cb = cb;
    overflow_arg = arg;
}

overflow_cb(overflow_arg);

cpu/sam0_common/periph/wdt.c stores early-warning callback/context before the WDT ISR consumes it:

cb = wdt_cb;
cb_arg = arg;

if (cb != NULL) {
    cb(cb_arg);
}

Expected results

Overflow or early-warning IRQ handlers should not use the new callback/context before callback setup has finished.

Actual results

Overflow or early-warning IRQ handlers may use the new callback/context too early.

Analysis

These drivers update callback/context first, while pending overflow or early-warning IRQ state may still fire.

That lets the ISR observe new callback/context even though the pending interrupt condition has not been fully cleared yet.

Suggested Fix

• disable overflow/early-warning IRQ delivery before replacing callback/context
• clear pending interrupt/event state before re-enabling
• re-enable only after callback/context and rest of setup are complete
• if reconfiguration is unsupported for same instance, document that clearly

[AnnsAnns]

The amount of issues that were posted in the same minute is a bit ... fascinating?

How did you come across all these issues, can you give us some backstory to that so we can understand your thought process, how much of these issues is human written / how much was discovered and/or written by AI and lastly, why did you post all of them at once as a giant wall of text(s)? @andrewlihhh

[andrewlihhh]

Thanks for taking a look and for asking this! I am happy to explain the backstory.

These reports came from an experiment with gvap-fuzz, a dynamic analysis tool I have been developing for interrupt-driven MCU firmware. The tool looks for thread/main -> ISR -> thread/main shared-state access patterns, and I then manually review the candidates against the RIOT driver source.

These were not produced by static AI code auditing. The workflow was roughly:

1. build small host-side harnesses around unmodified upstream RIOT peripheral driver code,
2. run them with controlled interrupt injection and runtime memory-access tracing,
3. collect candidate shared-state windows where an ISR can run between two thread-side accesses,
4. filter out harness artifacts and weak candidates,
5. manually inspect the remaining cases against the RIOT source code.

The host-side harness is not a full board-level emulator. It is useful for exposing driver-level ordering windows in the upstream source code, but I agree that hardware or board-level validation is a separate step where needed.

Regarding AI usage: the discovery side was driven by my scripts and manual source review. AI mainly helped me organize the reports and draft the issue text. I reviewed the final text and source snippets before posting, and I take responsibility for the reports.

About the number of issues: once I noticed that several candidates had the same underlying shape, I got excited and tried to group and submit them while the context was still fresh. My intention was to make the pattern visible to maintainers and get feedback on whether this class of issue is valid in RIOT. In hindsight, posting all grouped issues at once still created a wall of reports. Sorry for that.

I also noticed the issues are currently marked as State: Action by the author of the PR is required. I will prepare the corresponding PRs within two working days, starting from the grouped issues that look most actionable.

[AnnsAnns]

Hallo, thank you for your answer and your interest in RIOT. We are glad to hear that this work is legit, the massive amount of issues created at the same time scared us for a bit. We would also happily accept PRs for the issues described, thank you :)

[andrewlihhh]

Thank you for the clarification, and sorry again for the sudden burst of issues.

I will start preparing focused PRs for the clearest cases first, keeping each PR small and linked to the corresponding issue. I will also avoid opening more grouped reports before getting maintainer feedback.