Bump pinned Zephyr for ba0bd94d4e9: mDNS listener poll arrays are stack-allocated (intermittent total mDNS death)

[mikeysklar]

Our pinned Zephyr carries a stack-use-after-return in the mDNS responder that kills all
mDNS answering intermittently, with no user code involved. Fixed upstream on 2026-08-06 by
ba0bd94d4e9 ("Use static storage for listener poll arrays"), which is not in our pin.

subsys/net/lib/dns/mdns_responder.c in our pin declares the arrays inside
init_listener():

1643:  struct zsock_pollfd ipv6_fds[MAX_IPV6_IFACE_COUNT];   automatic storage
1753:  struct zsock_pollfd ipv4_fds[MAX_IPV4_IFACE_COUNT];   automatic storage
1741:  register_dispatcher(&v6_ctx[i], &v6_svc, ..., ipv6_fds, ARRAY_SIZE(ipv6_fds));
1851:  register_dispatcher(&v4_ctx[i], &v4_svc, ..., ipv4_fds, ARRAY_SIZE(ipv4_fds));
1512:  ctx->dispatcher.fds = fds;                            pointer retained

and the retained pointer is dereferenced after the frame dies, at dispatcher.c:398 and in
the ctx->fds[i].fd reads at dispatcher.c:278-288 and 335-349.

Trap for anyone verifying: net_socket_service_register() itself copies the fds
(svc->pev[i].event = fds[i]), so that function looks safe in isolation. The retention is
one level up, via ctx->dispatcher.fds.

Symptom is intermittent, which is the signature: fine while the freed frame happens to be
intact, dead once it is reused. A board can answer nothing from a fresh boot with no Python
object in existence, then answer correctly after the next reset.

Verified on hardware. Applying the upstream commit as a local test patch:

.bss +32 bytes exactly, confirming the arrays moved to file scope

5 hard-reset cycles, 3 probe rounds each, no user mdns.Server
declared pass criterion >=2 of 3 rounds per cycle
result: 3/3, 3/3, 3/3, 3/3, 3/3 -- not one silent round in fifteen

pre-patch, same probe: one healthy window then 0/6, fresh-reset baseline 0

Not landable as a direct edit. tannewt pins Zephyr by SHA in west.yml, so this has to go
through adafruit/zephyr plus a pin bump.

Worth considering a bump rather than a single pick: DNS/mDNS churned nine commits upstream
between 2026-08-04 and 2026-08-11, including 748a0b1b023 (multi-homed A/AAAA and DNS-SD
response interface selection), 19289bd7529 (DNS port per family) and d7859a7117a
(getsockname failure handling). A bump costs a wider retest.

Separate from #51, which survives this fix and is a genuine port bug.

[mikeysklar]

Qualifying the claim in this issue. The 15/15 result stands for exactly what it measured — that specific probe sequence, five reset cycles, against a pre-declared threshold, with no silent round. It does not support the broader statement that the intermittency is gone.

A later run on the same patched build produced a silent baseline: zero packets before any Python touched the board.

baseline                 : 0 packets
after construct          : 0
after re-advertise       : 0

The procedural difference between the two harnesses is that the later one sent Ctrl-C to interrupt code.py after reset, while the passing harness went reset -> wait -> HTTP -> probe with no interrupt. So there is at least one uncontrolled variable, and at least one path that still produces total mDNS silence on the patched build.

What is unaffected: the mechanism in the report above is a real stack-use-after-return, verified line by line in our pinned source, and fixed upstream. The .bss +32 confirms the patch does what it says. The case for taking ba0bd94d4e9 is unchanged.

What is weakened: "this makes mDNS reliable". It demonstrably improves the tested sequence; whether it is sufficient on its own is not established.

[mikeysklar]

Now landable on our forks, verified from the committed form rather than a loose patch.

Two branches

Zephyr: mikeysklar/zephyr branch siwx917/mdns-static-poll-arrays, commit 33ff09e8976b9cce91957f9254178f639703364f — upstream ba0bd94d4e9 cherry-picked onto our pin 1f5ee1ce103. One file, +11/-3. Upstream authorship preserved:

author:    Robert Lubos <robert.lubos@nordicsemi.no>
committer: Mikey Sklar <mikeysklar@gmail.com>
subject:   net: mdns_responder: Use static storage for listener poll arrays

CircuitPython: siwx917/bump-zephyr-mdns-poll-arrays, commit 839e6872630da1d064dcb4b165cae327289fcd59, off siwx917/integration-rebase. One line:

-      revision: 1f5ee1ce1034e76fbe636888efddde19ba07be87
+      revision: 33ff09e8976b9cce91957f9254178f639703364f

Verified on hardware from the pin, not the patch

Symbol-level confirmation the bump took effect, rather than trusting the build system:

000096b4 00000008 b ipv4_fds
000096a8 00000008 b ipv6_fds

Both now file-scope .bss statics rather than stack-local inside init_listener().

mDNS reliability, criterion declared before running — 5 hard-reset cycles, 3 probe rounds each, no user mdns.Server, pass = every cycle answers in >=2 of 3:

cycle 1: 3/3   cycle 2: 3/3   cycle 3: 3/3   cycle 4: 3/3   cycle 5: 3/3   PASS

15/15, no silent round. Matches the earlier working-tree-patch result exactly.

FLASH 869,120 B (82.89%), RAM 198,818 B (60.86%). Flashed zephyr.rps sha256 71a46bd1eb851bfc8098245bb6879905ba0b7e95a0a89ad612bb6097333fd46e.

What upstream has to do — not ours to do

1. ba0bd94d4e9 has to reach adafruit/zephyr. We cannot push there. Either someone with access cherry-picks it, or adafruit merges upstream far enough forward to include it. The commit is already in upstream Zephyr, so this is only the fork chain catching up.
2. The west.yml pin then moves to the adafruit/zephyr SHA, not ours. Our bump points at mikeysklar/zephyr, which is correct for our testing and wrong for upstream.
3. tannewt pins by SHA, so step 2 cannot precede step 1.

Trap for anyone building this

There is a single shared Zephyr checkout behind the parent repo and its worktrees, and it has been restored to 1f5ee1ce103 so it agrees with siwx917/integration. That means it disagrees with the pin in the bump branch. Checking out siwx917/bump-zephyr-mdns-poll-arrays and building from that shared workspace will silently produce a build with the old Zephyr unless you west update or check out siwx917/mdns-static-poll-arrays first.

Both states cannot be satisfied at once. Verify with the nm check above rather than assuming the branch name determines the contents.

[mikeysklar]

Clarification: this fixes a real bug, but it does not fix #51.

Earlier discussion pointed at this commit as a possible cause of the mDNS-dies-after-serial-contact failure. Tested properly, with the web workflow enabled so the failure actually reproduces, it does not fix it — arm B remained 0/4 across 5 of 5 valid cycles with the pin bump applied.

The fix does do what it claims, verified on the same board in the same session:

                                  WITHOUT fix          WITH fix
                              healthy   failed    healthy   failed
v4_ctx[0].dispatcher.fds[0].fd   -1    151380         2        2
ipv4_fds[0].fd                   n/a      n/a         2        2

Without it the retained pointer reads as garbage after a soft reboot. With it, ipv4_fds is a proper file-scope static and the fd is valid. The stack-use-after-return is real and this commit addresses it.

So the case for taking this bump is unchanged and stands on its own merits. It simply is not the cure for #51, and the two should not be filed as one.