94xhn commented on PR #19390: URL: https://github.com/apache/nuttx/pull/19390#issuecomment-5342595681
Added the Assisted-by trailer (3f8304b7). Sorry for the delay on this. @acassis re: why I didn't add `dev->d_appdata = IPBUF(udpiplen);` — I traced this and it's not needed here. `udp_input_conn()` (called right after, either the next loop iteration or once more after the loop for the last listener) unconditionally does `dev->d_appdata = IPBUF(udpiplen);` as its very first line, before d_appdata is ever read. So d_appdata is always fully re-set before use regardless of what it held going into the call — the original reporter's patch adding it in the loop was fixing the same symptom in a way that happens to be redundant. `d_len` is different: `udp_active()` (the loop condition) doesn't touch it, but the corrupted value survives from one `netdev_iob_replace()` all the way into the next `udp_input_conn()` call, where it does get read (via `udp_datahandler()`) before anything resets it — that's the actual persistence path, which is why fixing d_len alone closes the bug. @linguini1 re: testing on sim — I haven't gotten a full sim board build running yet (this box didn't have kconfig-frontends/genromfs set up, and getting that stood up is more than I've done so far). What I did instead: traced the exact live code path against the current tree and reproduced the byte-level mechanics with a host-side harness that calls the real `iob_copyout`/read-ahead parsing logic to confirm the corrupted d_len does lead to the described stack overflow, and that the fix's effect (the code path exactly restores the pre-corruption value) is correct. I know that's not the same as an actual multi-socket SO_REUSEADDR run on sim — if that's still a hard requirement here, let me know and I'll get the sim environment set up properly rather than keep offering the same kind of evidence. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
