F0Rw4Rd

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) was 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. This can lead to a crash (denial of service) or potentially arbitrary code execution. Requires establishment of session that needs ADJACENT network access.

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 advanced to the next port, so the request never completes and the device stops responding. A remote unauthenticated attacker can use this to cause a denial of service.

تحدث عملية كتابة خارج الحدود عندما يتم بناء البرنامج مع تفعيل خيار `PNET OPTION AR VENDOR BLOCKS`. تظهر المشكلة أثناء تحليل طلب `ARVendorBlock` حيث يتم استخدام حقل طول البيانات، الذي ليس جزءًا من تعريف الكتلة، كعدد للبايتات المراد نسخها إلى ذاكرة مؤقتة (buffer) ثابتة الحجم، دون مقارنتها بحجم الذاكرة المؤقتة أو طول الكتلة. يمكن أن يؤدي طلب Connect مصمم خصيصًا إلى تحفيز هذا الخلل، مما قد يتسبب في تعطل النظام (حجب الخدمة) أو تنفيذ رمز برمجي عشوائي.

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 (denial of service).

A NULL pointer dereference occurs when the LSS (Layer Setting Services) protocol is used to configure the device. This happens if an object defined by the user application lacks all required subindexes for object `0x1018`. An unauthenticated remote attacker with access to the CAN bus can initiate the LSS protocol on a device with a misconfigured identity object, which may lead to a device crash.

A write protection bypass exists in the SDO (Service Data Object) server implementation within `src/co sdo server.c`. The issue occurs because the system fails to properly validate write permissions when processing download-segment frames. An unauthenticated attacker on the CAN bus can initiate an SDO upload for a read-only Object Dictionary (OD) entry to set a data pointer to that read-only object, and subsequently send download-segment frames to write to that memory location. Because the download-segment handler does not verify if a download session is active, any CANopen node can overwrite read-only OD entries using two SDO frames. The CANopen protocol operates over the CAN bus and lacks built-in authentication mechanisms.