CVE-2026-111736

P-Net before 1.0.3, when built with PNET_OPTION_AR_VENDOR_BLOCKS enabled, parses a data length from an ARVendorBlock request field that is not part of the block definition and uses it as the number of bytes to copy into a fixed-size buffer without comparing it to the buffer size or block length. A crafted Connect request causes an out-of-bounds write, potentially leading to a crash (denial of service) or arbitrary code execution. This option is disabled by default.

P-Net before 1.0.3 does not check that a complete block header is present in 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 next block's length is read past the buffer. Additionally, a DCP Set block shorter than the two-byte block qualifier causes a length underflow, processing the block as 65534 bytes. This can cause a crash (denial of service) or disclose a small amount of memory. Requires adjacent network access.

P-Net before 1.0.3 passes the application alarm callback a data length derived from the variable part length field of a received RTA alarm frame without checking it against the length of the received frame. A short frame can make the callback receive a length of up to 65507 bytes. An application that copies the reported number of bytes reads past the end of the receive buffer. The attacker must have established an Application Relationship and requires ADJACENT network access. Applications that do not use the alarm data are not affected.

P-Net before 1.0.3 does not release the RPC session allocated for a request naming an unknown interface or object UUID and does not start a timeout for it. Repeated requests with different UUIDs exhaust available sessions, after which the device stops answering new RPC requests, including Endpoint Mapper Lookup and Connect, until restarted.

P-Net before 1.0.3 does not release the Application Relationship (AR) and the RPC session when an RPC request is rejected due to incorrect endianness of its data representation. The session and its AR remain allocated, so repeated requests exhaust available sessions, after which the device stops answering new RPC requests, including Connect, until restarted.

P-Net before 1.0.3 contains an integer underflow in pf_cpm_c_data_ind(). When handling a received cyclic data frame while the consumer is in the FRUN or RUN state, the APDU status offset was computed as the frame length minus 4 using 16-bit arithmetic, without checking that the frame is long enough. A crafted short frame makes the offset wrap around, so the function reads outside the receive buffer.

P-Net before 1.0.3 does not validate the length of a received Ethernet frame in pf_eth_recv() before reading the EtherType, VLAN tags and PROFINET FrameID. The VLAN tag loop has no upper bound, so a truncated frame or a frame consisting only of VLAN tags causes a read past the end of the receive buffer.

P-Net before 1.0.3 dereferences a NULL AR pointer when handling an implicit read request without a valid target AR UUID for a record index that requires an AR (AR specific indices 0xE000-0xEFFF, and the expected identification data of a slot or subslot). A remote unauthenticated attacker can send such a request to crash the device.

P-Net before 1.0.3 enters an infinite loop when handling a read request for the PDPortDataCheck record with subslot 0 (whole module). The loop over the ports never advances to the next port, so the request never completes and the device stops responding.

P-Net before 1.0.3 does not validate the LengthPeerStationName field of a CheckPeers block in get_check_peer(). The received length (up to 255) is used to copy data into the 241-byte peer station name buffer and to place the terminating NUL byte, so a crafted block writes up to 15 bytes past the end of the buffer.