CV-Bowen opened a new pull request, #21091:
URL: https://github.com/apache/nuttx/pull/21091
## Summary
Two drivers compute the CRC over `hdr->len - sizeof(crc)` without first
checking that `hdr->len` can even hold the header, so a frame whose
length field came from line noise makes that subtraction underflow and
`crc16xor()` walks far past the buffer. Both now drop such frames
before the CRC is computed.
- `rpmsg_port_spi`: the DMA completion path and the slave notify path
reject a header whose `len` is smaller than the port header or larger
than the rx queue. Reproduced with a rpmsg socket test on a trunk
build; the coredump shows the sensor core crashing in `crc16xor`
with `rxhdr = {crc=0xaea5, cmd=0xbaae, avail=0x082d, len=0}` and the
ap/cp/audio cores cascading in `rptun_check_peer_status()`. The check
is unconditional because a bad `len` also poisons `txavail` and the
rx queue flow control when the CRC is compiled out.
- `rpmsg_port_uart`: the frame validation at the END delimiter now
requires `len >= sizeof(*hdr)` as its first term. The reachable path
is buffer reuse: a duplicate START resets the parser state but keeps
`hdr`, so a stale `len` from the previous partial frame is still
there, and when it happens to equal the byte count an END is accepted
as a valid frame. With the CRC compiled in, a non-zero stale `crc`
then underflows the length passed to `crc16xor()`; with it compiled
out the frame is queued and the LZF path underflows
`hdr->len - sizeof(*hdr)`.
- `rpmsg_port`: the NS endpoint callback takes the device from its own
`priv` instead of `ept->rdev`. `rpmsg_register_endpoint()` links the
NS endpoint without holding `rdev->lock`, so the RX thread can find it
before `ept->rdev` is visible and dereference NULL in
`metal_mutex_acquire()`.
The first commit only fixes existing nxstyle errors in
`rpmsg_port_uart.c`.
## Impact
Frames with a malformed length header are dropped and logged instead of
being parsed. No API or Kconfig change.
## Testing
Host: Ubuntu 22.04.5 LTS x86_64, QEMU version 10.2.1, sim: cc (Ubuntu
13.1.0-8ubuntu1~22.04) 13.1.0, qemu-armv8a: aarch64-none-elf-gcc (Arm GNU
Toolchain 12.2.Rel1 (Build arm-12.24)) 12.2.1 20221205
The qemu-armv8a server/proxy configurations also bring up the port uart
driver on /dev/ttyV0 (server2 <==> proxy2), so `rpmsg dump all` shows the
second rpmsg device (`Remote: proxy2 state: 1`, `rpmsg_port queue RX/TX`)
and `rpmsg ping all` sends over both the virtio rpmsg device and the port
uart one, covering normal frame flow in the paths touched here.
Baseline (`test.sh`, cases: baseline.yaml):
- host: Ubuntu 22.04.5 LTS x86_64, QEMU version 10.2.1, sim: cc (Ubuntu
13.1.0-8ubuntu1~22.04) 13.1.0, qemu-armv8a: aarch64-none-elf-gcc (Arm GNU
Toolchain 12.2.Rel1 (Build arm-12.24)) 12.2.1 20221205
- tested: nuttx c010e0f3092 apps 0c56297b0
- qemu-armv8a built with test-only overlay: disabled LIBC_ENVPATH
BINFMT_CHECKEXEC
- sim:rpserver + sim:rpproxy: PASS
- [x] `uname -a` (server)
- [x] `rpmsg dump all` (server)
- [x] `rpmsg ping all 10 1024 3 0` (server)
- [x] `uname -a` (proxy)
- [x] `rpmsg ping all 10 1024 3 0` (proxy)
- [x] `mount -t rpmsgfs -o cpu=server,fs=/proc /sp` (proxy)
- [x] `cat /sp/version` (proxy)
- [x] `rpmsg dump all` (proxy)
- qemu-armv8a:rpserver + qemu-armv8a:rpproxy: PASS
- [x] `uname -a` (server)
- [x] `uname -a` (proxy)
- [x] `rpmsg dump all` (server)
- [x] `rpmsg ping all 10 1024 3 0` (server)
- [x] `rpmsg ping all 10 1024 3 0` (proxy)
- [x] `mount -t rpmsgfs -o cpu=server,fs=/proc /sp` (proxy)
- [x] `cat /sp/version` (proxy)
--
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]
