Out-of-bounds read of DCP block header in DCP Set and Identify request parsing
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 1.0.3
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
P-Net, an open-source Profinet device stack used in industrial automation equipment, is affected by this flaw in how it parses DCP Set and Identify requests. An attacker on the same local network can send crafted packets that cause the device to crash or leak a small amount of its memory contents.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
P-Net before 1.0.3 does not check that a complete block header is present in the received data before reading the next block in DCP Set and Identify requests. If the last block ends at the end of the receive buffer, the block length of the following block is read past the end of the buffer. In addition, a DCP Set block with a length smaller than the two-byte block qualifier makes the length underflow, so the block is processed with a length of 65534 bytes. This can cause a crash (denial of service) or disclose a small amount of memory content. Requires ADJACENT network access.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- RT-Labs P-Net
fixed in 1.0.3