I'm not talking about game rendering, but multiplayer games and game servers might be affected. I mean, the requested size must come from an external source.
>(...) could allow an attacker to execute arbitrary code with the privileges of the current user.
>The vulnerability occurs when reading the header of the Pack200 compressed Jar file during decompression. To calculate the size of a heap buffer, the code multiplies and adds several 32-bit integers. The bounds of these values are not checked, and the arithmetic operations can overflow. This results in an undersized buffer being allocated, which leads to a heap-based buffer overflow.
I remember there was a similar bug in some other decompression library.
The original version is not only bug prone. In some scenarios, both versions have a potential vulnerability. Can you spot it?
In a scenario where users can access elements of a joint array of requested size without limitations, they can access memory outside the array. Memory block's total requested size may overflow size_t. Fortunately, overflow prevention is easy to add to the generic version.
Here's an example with a better description: https://www.verisign.com/en_US/security-services/security-in...
>(...) could allow an attacker to execute arbitrary code with the privileges of the current user.
>The vulnerability occurs when reading the header of the Pack200 compressed Jar file during decompression. To calculate the size of a heap buffer, the code multiplies and adds several 32-bit integers. The bounds of these values are not checked, and the arithmetic operations can overflow. This results in an undersized buffer being allocated, which leads to a heap-based buffer overflow.
I remember there was a similar bug in some other decompression library.