RIOT is an open-source microcontroller operating system, designed to match the requirements of Internet of Things (IoT) devices and other embedded devices. A malicious actor can send a IEEE 802.15.4 packet with spoofed length byte and optionally spoofed FCS, which eventually results into an endless loop on a CC2538 as receiver. Before PR #20998, the receiver would check for the location of the CRC bit using the packet length byte by considering all 8 bits, instead of discarding bit 7, which is what the radio does. This then results into reading outside of the RX FIFO. Although it prints an error when attempting to read outside of the RX FIFO, it will continue doing this. This may lead to a discrepancy in the CRC check according to the firmware and the radio. If the CPU judges the CRC as correct and the radio is set to `AUTO_ACK`, when the packet requests and acknowledgment the CPU will go into the state `CC2538_STATE_TX_ACK`. However, if the radio judged the CRC as incorrect, it will not send an acknowledgment, and thus the `TXACKDONE` event will not fire. It will then never return to the state `CC2538_STATE_READY` since the baseband processing is still disabled. Then the CPU will be in an endless loop. Since setting to idle is not forced, it won't do it if the radio's state is not `CC2538_STATE_READY`. A fix has not yet been made.
Metrics
Affected Vendors & Products
References
History
Mon, 02 Dec 2024 11:15:00 +0000
Type | Values Removed | Values Added |
---|---|---|
First Time appeared |
Riot-os
Riot-os riot |
|
CPEs | cpe:2.3:o:riot-os:riot:*:*:*:*:*:*:*:* | |
Vendors & Products |
Riot-os
Riot-os riot |
|
Metrics |
ssvc
|
Fri, 29 Nov 2024 19:00:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Description | RIOT is an open-source microcontroller operating system, designed to match the requirements of Internet of Things (IoT) devices and other embedded devices. A malicious actor can send a IEEE 802.15.4 packet with spoofed length byte and optionally spoofed FCS, which eventually results into an endless loop on a CC2538 as receiver. Before PR #20998, the receiver would check for the location of the CRC bit using the packet length byte by considering all 8 bits, instead of discarding bit 7, which is what the radio does. This then results into reading outside of the RX FIFO. Although it prints an error when attempting to read outside of the RX FIFO, it will continue doing this. This may lead to a discrepancy in the CRC check according to the firmware and the radio. If the CPU judges the CRC as correct and the radio is set to `AUTO_ACK`, when the packet requests and acknowledgment the CPU will go into the state `CC2538_STATE_TX_ACK`. However, if the radio judged the CRC as incorrect, it will not send an acknowledgment, and thus the `TXACKDONE` event will not fire. It will then never return to the state `CC2538_STATE_READY` since the baseband processing is still disabled. Then the CPU will be in an endless loop. Since setting to idle is not forced, it won't do it if the radio's state is not `CC2538_STATE_READY`. A fix has not yet been made. | |
Title | Spoofed length byte traps CC2538 in endless loop | |
Weaknesses | CWE-835 | |
References |
|
|
Metrics |
cvssV4_0
|
MITRE
Status: PUBLISHED
Assigner: GitHub_M
Published: 2024-11-29T18:56:57.584Z
Updated: 2024-12-02T11:06:19.121Z
Reserved: 2024-11-25T23:14:36.379Z
Link: CVE-2024-53980
Vulnrichment
Updated: 2024-12-02T11:05:27.872Z
NVD
Status : Received
Published: 2024-11-29T19:15:09.993
Modified: 2024-11-29T19:15:09.993
Link: CVE-2024-53980
Redhat
No data.