CVE-2023-48229 is a high severity (CVSS 7.0) out-of-bounds write in the 802.15.4 radio driver for nRF platforms in Contiki-NG, in versions up to 4.9. There was no tagged release with the fix when advised. Update your develop branch or apply pull request 2741.
What's affected
The affected component is the read_frame function in arch/cpu/nrf/net/nrf-ieee-driver-arch.c. It validates the payload length of a received radio frame against the maximum transmission unit, but not against the size of the buffer the packet is copied into. The weakness is CWE-787 (Out-of-bounds Write).
The GitHub advisory GHSA-rcwv-xwc9-5hp2, published on 14 February 2024, lists affected versions as 4.9 and earlier, and patched versions as none, because the fix landed in the develop branch and was expected in a later release. Users who cannot upgrade are told to apply the changes in pull request 2741. I could not verify whether a tagged release since then contains the fix, so check the project's releases.
There is a severity difference. The record scores it 7.0 (High) with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H. The GitHub advisory labels it Moderate. Both come from the same facts, so plan on the higher score if the device sits where outsiders can send radio traffic. The record does not flag the CVE as exploited in the wild.
How to check if you're exposed
This applies to firmware you build, so check your source tree and build configuration rather than a package manager.
git -C contiki-ng describe --tags
git -C contiki-ng log --oneline -3 -- arch/cpu/nrf/net/nrf-ieee-driver-arch.c
Confirm that your build targets an nRF platform and uses the IEEE 802.15.4 driver in that file. If it targets other platforms, this CVE does not apply to those images. Then check whether the change from pull request 2741 is present in the driver file.
Inventory the field devices too. Firmware images are rarely updated, so list which hardware runs which build.
What to do now
- Merge the current develop branch of Contiki-NG, or a later tagged release that includes the fix, into your firmware tree.
- If you cannot upgrade, apply the changes from pull request 2741 to the driver file by hand.
- Rebuild and reflash the affected nRF devices, and record the new firmware version per device.
- Limit who can send radio traffic to the devices where physical placement allows it.
- Add a build time check so the driver file is compared against the fixed version in future.
Why it matters
The driver checks that a length fits the general packet limit, then copies the data into a smaller buffer. Passing the first check does not prove the second. When the length comes from a radio frame, a nearby sender controls it, so the copy can write past the end of the buffer.
Embedded operating systems are a hard case for supply chain work because the code is compiled into the device image, and there is no package manager to update. Knowing which of your devices include a given source file is the difference between a quick fix and a long search. See the Safeguard Gold page for this CVE for the record.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is there a released version with the fix?
The advisory says the fix is in the develop branch and lists no patched release. Check the project releases for a newer tag.
Which platforms are affected?
The nRF platforms, through the IEEE 802.15.4 driver in the nrf-ieee-driver-arch.c file.
Sources
Last reviewed: 19 October 2026.
