subsys: net: ipv6: Unaligned access causes HARD FAULT on ARM CPU

[ThreeEights]

Describe the bug

The function net_ipv6_addr_generate_iid() in zephyr/subsys/net/ip/ipv6.c attempts to read the first two 32-bit words of s6_addr32 from the provided in6_addr (prefix). However, that address is not guaranteed to be aligned on a 32-bit word boundary, causing an unaligned access exception. The problematic code is on lines 965-966 and 981-982:

		UNALIGNED_PUT(prefix->s6_addr32[0], &tmp_addr.s6_addr32[0]);
		UNALIGNED_PUT(prefix->s6_addr32[1], &tmp_addr.s6_addr32[1]);

I'm currently seeing this on a Raspberry Pi Pico W when attempting the wifi connect command.

To Reproduce

1. Apply the changes from pull request drivers: wifi: infineon: Add SPI support to AIROC WiFi driver #78773
2. Prepare the sample zephyr/samples/net/wifi/shell
3. west build -b rpi_pico/rp2040/w
4. west debug -- -DCMAKE_BUILD_TYPE=Debug
5. Connect a console to the Pico W serial port
6. In the debugger, continue
7. In the Pico W shell: `wifi connect -s SSID -k 2 -p PASSWORD
8. If the first attempt does not connect, try again
9. System stops with a HARD FAULT

Expected behavior

The IPv6 address should be copied.

Impact

Logs and console output

Debug console output:

[00:00:37.909,000] <err> os: ***** HARD FAULT *****
[00:00:37.916,000] <err> os: r0/a1:  0x00000001  r1/a2:  0x0000000a  r2/a3:  0x20001030
[00:00:37.927,000] <err> os: r3/a4:  0x00000000 r12/ip:  0x00000002 r14/lr:  0x1002001f
[00:00:37.937,000] <err> os:  xpsr:  0x01000000
[00:00:37.945,000] <err> os: Faulting instruction address (r15/pc): 0x1002001e
[00:00:37.954,000] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:37.964,000] <err> os: Current thread: 0x20001bf0 (rx_q[0])
[00:00:37.973,000] <err> os: Halting system

Looking with the debugger, I see the address of prefix->s6_addr32 is 0x2000ee0e, leading to an address fault.

Environment (please complete the following information):

• OS: Ubuntu 24.04.1
• Toolchain: Zephyr SDK 0.16.8, gcc 13.2.0
• Commit SHA: 6843240

Note: My development tree is rather out of date, but the problematic code is still present in 4.0.0.

Additional context