Buffer overflow in ovt_packet.cpp`– Buffer Overflow / Invalid Packet Size Handling

[NoorahSmith]

---

🐛 Buffer Overflow in ovt_packet — Invalid Packet Size Handling

Describe the bug

A buffer overflow / unsafe buffer handling issue occurs in ovt_packet.cpp at line 61 during packet depacketization.

Although the error is currently logged as an invalid packet, the underlying problem is a buffer size mismatch that can lead to unsafe buffer access (overread / overflow) when malformed or truncated packets are received.

The issue is reproducible and causes repeated depacketizer errors followed by client disconnects.

---

To Reproduce

Steps to reproduce the behavior:

1. Start OvenMediaEngine with OVT enabled (port 9000)
2. Send malformed or truncated OVT packets where the buffer length does not match the expected packet structure
3. Observe repeated depacketizer errors and client disconnects

📎 I can provide a POC.py script to reliably reproduce the issue if needed.

---

Expected behavior

• The packet parser should strictly validate buffer length before parsing packet fields
• Packets with insufficient or malformed buffer sizes should be rejected safely without unsafe memory access
• Repeated malformed packets should not destabilize the server or cause cascading disconnects

---

Actual behavior

• The depacketizer receives a buffer (e.g. 51 bytes) that does not match the required packet size (e.g. 18 bytes)
• Packet fields are accessed based on header assumptions before full validation
• Errors such as the following are logged repeatedly:

ERROR | ovt_packet.cpp:61 | Version: 48
OvtDepacketizer | ovt_depacketizer.cpp:50 |
Packet is invalid : buffer size (51) required size : 18

• Clients are subsequently disconnected
• Under load or malicious input, this represents a potential memory safety issue, not just a protocol error

---

Logs

Please upload the entire OvenMediaEngine.log.
(You may remove any sensitive or personal information.)

---

Server (please complete the following information)

• OS: Ubuntu24 LTS
• OvenMediaEngine Version: Docker image latest

---

Player (please complete the following information)

NA

Additional context

• The issue appears when using non-blocking TCP sockets with rapid connect/disconnect cycles
• Packet framing assumptions may not hold under partial TCP reads
• Adding explicit buffer length guards before parsing at or before ovt_packet.cpp:61 should prevent this issue entirely

If helpful, I can:

• Share a minimal reproducer POC
• Propose a defensive patch
• Test a fix on the affected branch

---

[getroot]

Do you see the same issue when testing with 0.20.0? 0.20.0 addresses an issue related to OVT depacketizing.

[NoorahSmith]

The server is running the latest docker image which has ome version 0.20.0

[getroot]

• Understood. What you are describing appears to be about how the OVT Provider should handle the following situation:

Send malformed or truncated OVT packets where the buffer length does not match the expected packet structure.

• Based on the current logs, in this situation the code correctly performs a length check, reports the packet as invalid, and then closes the connection.

• You may be expecting that, if 18 bytes are required and 51 bytes are received, the implementation should simply consume or trim the first 18 bytes and continue processing.

• However, the log indicates that although 51 bytes were received, the header could not be parsed correctly. This clearly indicates a corrupted packet. Please refer to the code below.
  https://github.com/OvenMediaLabs/OvenMediaEngine/blob/master/src/projects/modules/ovt_packetizer/ovt_depacketizer.cpp#L42

• Therefore, the current behavior (rejecting the packet and closing the connection) is an intentional defensive response to invalid protocol input, rather than unsafe buffer handling.

If my understanding is incorrect, please explain in more detail which part of the packet parsing you believe is unsafe, and under what specific condition the buffer is accessed incorrectly.

[NoorahSmith]

@getroot On the server , its showing error that packet is dropped when its corrupted but the response received shows that there is some internal server error . The internal server error coming is not coming from the dropped packet . Can you investigate it .

[NoorahSmith]

@getroot I can provide the POC over the email that i have prepared, if you need it for investigation on the dev side

[getroot]

Is this an issue that occurs between the same versions of OME Origin and OME Edge? I still don’t understand what the problem is. Please explain what you are trying to do and what is not working, and share the log files and the Server.xml.

[NoorahSmith]

I am trying to get my hands on the server.xml and the log files for your analysis . During recent engagement , oven media server was tested for any vulnerabilites . The server is responding ( Server Internals Error ) on invalid packet size . The server in question is a media server which streams

[getroot]

As the title of this issue suggests, if a buffer overflow occurs, that's an issue. However, I don't think properly detecting malformed packets and responding with an Internal Error is a problem. Furthermore, the OVT protocol isn't open for third-party implementation. (Of course, anyone can implement it by looking at the code.)
I'll move this issue to the Discussion section until it's clarified.