Prevent potential integer overflow when computing PACKET_OID_DATA allocation size

[nidu-ninja]

This change adds a defensive check when computing the allocation size for PACKET_OID_DATA structures used in Windows NPF OID request handling.

The allocation size is computed using:

offsetof(PACKET_OID_DATA, Data) + *lenp

If *lenp were extremely large, the addition could overflow size_t, which could cause malloc() to allocate a buffer smaller than intended.

In practice, lenp is provided by the calling application through the public API and is not derived from external input, so this should not be considered a vulnerability. However, adding an explicit check prevents the arithmetic from overflowing and makes the allocation logic more robust.

[infrastation]

Please clean this up completely and explain why this is not a vulnerability.

[nidu-ninja]

Thank you for the review.

You are correct that this should not be considered a vulnerability. The lenp value is provided by the calling application through the public API and is not derived from external or attacker-controlled input such as packets, files, or driver responses. Because of that, an excessively large value would only occur if the application itself misused the API.

The change simply adds a defensive check before computing the allocation size:

offsetof(PACKET_OID_DATA, Data) + *lenp

If *lenp were extremely large, that arithmetic could overflow size_t, potentially resulting in a smaller allocation than intended. While this situation would require incorrect usage by the caller, the added check ensures the size calculation cannot overflow and makes the allocation logic safer.

I will clean up the patch and description to present this purely as a defensive improvement to the allocation size calculation rather than a security vulnerability.