CVE-2026-37532
Received Received - Intake
Heap Buffer Over-read in AGL agl-service-can-low-level

Publication date: 2026-05-01

Last updated on: 2026-05-01

Assigner: MITRE

Description
AGL agl-service-can-low-level thru 17.1.12 contains a heap buffer over-read in the isotp-c library. In isotp_continue_receive (receive.c:87-89), the payload_length for a Single Frame is extracted from a 4-bit nibble in the CAN frame data, yielding values 0-15. However, a standard CAN frame is only 8 bytes, with payload starting at data[1] (7 bytes available). When payload_length exceeds the available data (e.g., nibble=15 but only 7 payload bytes exist), memcpy(message.payload, &data[1], payload_length) reads up to 8 bytes past the end of the data buffer.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-01
Last Modified
2026-05-01
Generated
2026-05-07
AI Q&A
2026-05-01
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
agl agl-service-can-low-level From 17.1.12 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-126 The product reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations after the targeted buffer.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the AGL agl-service-can-low-level software up to version 17.1.12, specifically in the isotp-c library. It involves a heap buffer over-read caused by improper handling of the payload length in CAN frames. The code extracts the payload length from a 4-bit nibble, which can indicate values from 0 to 15. However, a standard CAN frame only contains 8 bytes, with 7 bytes available for payload starting at data[1]. If the payload length exceeds the actual available data (for example, if the nibble indicates 15 but only 7 bytes are present), the memcpy operation reads beyond the allocated buffer, potentially accessing up to 8 bytes past the end of the data buffer.


How can this vulnerability impact me? :

This vulnerability can lead to a heap buffer over-read, which may cause application crashes or undefined behavior. According to the CVSS score (7.1), it has a high impact on availability (A:H) but only a low impact on confidentiality (C:L) and no impact on integrity (I:N). An attacker with access to the CAN network could exploit this flaw to disrupt the normal operation of the affected software, potentially causing denial of service or other stability issues.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The provided information does not specify any direct impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability involves a heap buffer over-read in the isotp-c library when processing CAN frames with an invalid payload length in a Single Frame. Detection would involve monitoring CAN traffic for frames where the payload length nibble exceeds the actual available data bytes.

Specifically, you can capture CAN frames and inspect the first nibble of the data field to verify if the indicated payload length is greater than 7 bytes, which is the maximum available payload in a standard CAN frame starting at data[1].

Commands to detect such frames might include using tools like can-utils on Linux:

  • Use `candump` to capture CAN traffic: `candump can0`
  • Filter frames and analyze payload length nibble in the first byte of the data field to identify frames with payload_length > 7.
  • Custom scripts or tools can parse the CAN frames and flag those where the 4-bit nibble indicating payload length exceeds 7.

What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include preventing the processing of malformed CAN frames that specify a payload length exceeding the actual available data bytes.

This can be done by applying input validation patches or updates from the vendor that fix the heap buffer over-read in the isotp-c library.

If patches are not yet available, consider implementing network-level filtering to block suspicious CAN frames with invalid payload lengths.

Additionally, monitor CAN traffic closely and restrict access to the CAN service API to trusted sources only.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart