I believe there is an error in the UDP receive logic when an incoming UDP packet matches multiple UDP connections. The udp_readahead() "unflatten" what should be meta-data, but seems to be the original IP packet. The resulting meta-data is thus garbled, which in my case results in stack corruption when iob_copyout() uses a too large "src_addr_size" to copy into an object on the stack.
My attached patch adds a DEBUGASSERT() to udp_readahead() which gets triggered. I hope it makes clear what happens.
Possible cause
I added some debug logging and noticed that the value of dev->d_len matched the size of the application data before udp_input_conn() was called the 1st time by udp_input(). The second time (for the second UDP connection), the value of dev->d_len was 28 (decimal) larger, which equals the value of udpiplen. dev->d_len was updated by the call to netdev_iob_replace() in udp_input().
My attached patch does an attempt on fixing this, but I have no idea whether it is correct or not (it seems to fix the issue I experience).
Steps to reproduce
I have multiple proprietary hardware devices with STM32H725 (which is not supported upstream) connected in a network. The network traffic is also generated with proprietary application software.
Hence, I have a hard time providing steps to reproduce this issue. So please let me know the best approach in this case, and I will try supply any further information you need.
kk-thrane
commented
2 weeks ago
Description / Steps to reproduce the issue
What I observe
I believe there is an error in the UDP receive logic when an incoming UDP packet matches multiple UDP connections. The udp_readahead() "unflatten" what should be meta-data, but seems to be the original IP packet. The resulting meta-data is thus garbled, which in my case results in stack corruption when iob_copyout() uses a too large "src_addr_size" to copy into an object on the stack. My attached patch adds a DEBUGASSERT() to udp_readahead() which gets triggered. I hope it makes clear what happens.
Possible cause
I added some debug logging and noticed that the value of dev->d_len matched the size of the application data before udp_input_conn() was called the 1st time by udp_input(). The second time (for the second UDP connection), the value of dev->d_len was 28 (decimal) larger, which equals the value of udpiplen. dev->d_len was updated by the call to netdev_iob_replace() in udp_input(). My attached patch does an attempt on fixing this, but I have no idea whether it is correct or not (it seems to fix the issue I experience).
Steps to reproduce
I have multiple proprietary hardware devices with STM32H725 (which is not supported upstream) connected in a network. The network traffic is also generated with proprietary application software. Hence, I have a hard time providing steps to reproduce this issue. So please let me know the best approach in this case, and I will try supply any further information you need.
Related issue?
I am unsure if this bug is an expected consequence of: https://github.com/apache/nuttx/issues/3374
On which OS does this issue occur?
[OS: Linux]
What is the version of your OS?
Ubuntu 24.04
NuttX Version
12.7
Issue Architecture
[Arch: arm]
Issue Area
[Area: Networking]
Verification