What if a VNC server could make your viewer believe it had a ~4 GB framebuffer… while actually allocating only 128 KB?

That’s the core of this TightVNC vulnerability.

A malicious server can announce a crafted 32768 × 32769 screen at 32bpp, causing the framebuffer size calculation to overflow. The allocation wraps down to 128 KB, but the viewer continues using the original, much larger dimensions when calculating pixel writes.

The result is a server-controlled out-of-bounds write in the viewer.

It’s a good example of how a relatively small integer-overflow mistake can become a powerful memory-corruption primitive when different parts of the application disagree about the true size of a buffer.