net: socket: udp: net.socket.udp* fail

[katgiadla]

Describe the bug The tests:

• net.socket.udp
• net.socket.udp.preempt
• net.socket.udp.ipv6_fragment
• net.socket.udp.pktinfo

fail.

Observed for:

• nrf5340dk_nrf5340_cpuapp_ns
• nrf9160dk_nrf9160_ns

To Reproduce Steps to reproduce the behavior:

1. have nrf9160dk_nrf9160 connected
2. go to your zephyr dir
3. call ./scripts/twister -T tests/net/socket/udp -p nrf9160dk_nrf9160_ns --device-testing --device-serial /dev/ttyACM0 -v --inline-logs
4. See console output with error

Expected behavior Valid console output

Impact Not clear

Logs and console output

*** Booting Zephyr OS build zephyr-v3.5.0-2237-gc2dc103101a5 ***
Running TESTSUITE net_socket_udp
===================================================================
START - test_01_send_recv_2_sock
PASS - test_01_send_recv_2_sock in 0.004 seconds
===================================================================
START - test_02_v4_sendto_recvfrom
PASS - test_02_v4_sendto_recvfrom in 0.108 seconds
===================================================================
START - test_03_v6_sendto_recvfrom
PASS - test_03_v6_sendto_recvfrom in 0.108 seconds
===================================================================
START - test_04_v4_bind_sendto
PASS - test_04_v4_bind_sendto in 0.107 seconds
===================================================================
START - test_05_v6_bind_sendto
PASS - test_05_v6_bind_sendto in 0.107 seconds
===================================================================
START - test_06_so_type
PASS - test_06_so_type in 0.003 seconds
===================================================================
START - test_06_v6_sendmsg_recvfrom_connected
PASS - test_06_v6_sendmsg_recvfrom_connected in 0.004 seconds
===================================================================
START - test_07_so_priority
PASS - test_07_so_priority in 0.002 seconds
===================================================================
START - test_08_so_txtime
PASS - test_08_so_txtime in 0.002 seconds
===================================================================
START - test_09_so_rcvtimeo
PASS - test_09_so_rcvtimeo in 0.703 seconds
===================================================================
START - test_10_so_sndtimeo
PASS - test_10_so_sndtimeo in 0.002 seconds
===================================================================
START - test_11_so_protocol
PASS - test_11_so_protocol in 0.003 seconds
===================================================================
START - test_12_v4_sendmsg_recvfrom
PASS - test_12_v4_sendmsg_recvfrom in 0.004 seconds
===================================================================
START - test_13_v4_sendmsg_recvfrom_no_aux_data
PASS - test_13_v4_sendmsg_recvfrom_no_aux_data in 0.004 seconds
===================================================================
START - test_14_v6_sendmsg_recvfrom
PASS - test_14_v6_sendmsg_recvfrom in 0.004 seconds
===================================================================
START - test_15_v4_sendmsg_recvfrom_connected
PASS - test_15_v4_sendmsg_recvfrom_connected in 0.004 seconds
===================================================================
START - test_17_setup_eth
PASS - test_17_setup_eth in 0.001 seconds
===================================================================
START - test_18_v6_sendmsg_with_txtime
PASS - test_18_v6_sendmsg_with_txtime in 0.002 seconds
===================================================================
START - test_19_v4_msg_trunc
PASS - test_19_v4_msg_trunc in 0.004 seconds
===================================================================
START - test_20_v6_msg_trunc
PASS - test_20_v6_msg_trunc in 0.004 seconds
===================================================================
START - test_21_v4_dgram_overflow
PASS - test_21_v4_dgram_overflow in 0.003 seconds
===================================================================
START - test_22_v6_dgram_fragmented_or_overflow
PASS - test_22_v6_dgram_fragmented_or_overflow in 0.003 seconds
===================================================================
START - test_23_v6_dgram_overflow
PASS - test_23_v6_dgram_overflow in 0.003 seconds
===================================================================
START - test_24_v4_dgram_connected
PASS - test_24_v4_dgram_connected in 0.024 seconds
===================================================================
START - test_25_v6_dgram_connected
PASS - test_25_v6_dgram_connected in 0.024 seconds
===================================================================
START - test_26_recvmsg_invalid
E: syscall k_usermode_alloc_from_copy failed check: Memory region 0 (size 0) read access denied
E: syscall k_usermode_alloc_from_copy failed check: Memory region 0 (size 0) read access denied

Environment (please complete the following information):

• OS: Ubuntu 20.04.1 LTS
• Toolchain Zephyr SDK 0.16.1
• Commit SHA or Version used: zephyr-v3.5.0-2237-gc2dc103101a5

[rlubos]

I did some debugging of this, the problem seems to be related to userspace memory address validation.

test_26_recvmsg_invalid test sets some presumably invalid addresses in the struct msghdr provided to the recvmsg() call and expects that z_vrfy_zsock_recvmsg() will catch that, but it doesn't seem to be the case on nRF platforms.

K_SYSCALL_MEMORY_READ() called from k_usermode_alloc_from_copy() does not report that address provided (0x01) is not ok to copy from, which ends up with memcpy() from that address. nrf9160dk_nrf9160_ns crashes while doing memcpy(), same issue on nrf9160dk_nrf9160 but it does not end up in crash.

[MaureenHelm]

@rlubos please check the priority

[carlescufi]

@anangl please take a look at @rlubos's description of the issue to see if you can figure out what is wrong here.

[axelnxp]

Hi I'm been facing an issue in our Matter over wifi enablement since the recvmsg implementation in zephyr. On Matter side, there is a function that calls recvmsg to populate a msghdr. Then, it iterates through this struct to process control messages cmsghdr, using CMSG macros. The exit condition is the pointer to the control header to be null, but this never happens and the device is stuck indefinitely.

I'm wondering if this issue is related, as @rlubos says the msghdr is somehow corrupted ?

Here is a dump of data for both control header and message header:

Pointer to the matter code: https://github.com/project-chip/connectedhomeip/blob/master/src/inet/UDPEndPointImplSockets.cpp#L643

This is where the device is stuck.

Previously, on Matter side, we where using a custom implementation of recvmsg which ignored the control header, so the for loop was never exercised. See: https://github.com/project-chip/connectedhomeip/blob/master/src/inet/ZephyrSocket.h#L34

[axelnxp]

after some investigation on my side, it seems recvmsg doesn't fulfill all requirements described in linux manpage. I opened a dedicated issue: https://github.com/zephyrproject-rtos/zephyr/issues/68352

[github-actions[bot]]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[github-actions[bot]]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.