Hacker News new | ask | show | jobs
by grisBeik 602 days ago
Sorry for being a party pooper, but it didn't take me 5 minutes to find an integer overflow in this code (which I've never seen before), as of commit 2443ff581ccd.

The public function nsfb_set_geometry() takes "width" and "height" as "int" values. Assume those are positive. Then we pass them to nsfb->surface_rtns->geometry().

Assume our surface is implemented by "surface/ram.c"; thus the call is made to ram_set_geometry(). There we store the passed-in "int" params into fields of "nsfb" (also ints). Then we do

    /* reallocate surface memory if necessary */
    endsize = (nsfb->width * nsfb->height * nsfb->bpp) / 8;
Unchecked multiplication between signed integers (nsfb->width * nsfb->height); not only can it overflow and yield a bogus result, if that happens, it's even undefined behavior.

It's naive code.

4 comments

It sounds like your concern is that if the caller of the public function nsfb_set_geometry() passes in certain arguments, they can invoke undefined behavior, because the function doesn't correctly handle the case where the desired framebuffer is larger than 256 mebibytes (assuming 32-bit ints), and it may suffer an integer arithmetic overflow.

That doesn't seem very surprising; nearly any function in C can be crashed by passing it invalid arguments. For example, printf((char)37), free((char)main), or memcpy(argv[0], argv[1], 10485760).

Perhaps your concern is that the 256-mebibyte limitation isn't documented? libnsfb in general has very little documentation; this is the only documentation I see for nsfb_set_geometry():

    /** Alter the geometry of a surface
     *
     * @param nsfb The context to alter.
     * @param width The new display width.
     * @param height The new display height.
     * @param format The desired surface format.
     */
    int nsfb_set_geometry(nsfb_t *nsfb, int width, int height, enum nsfb_format_e format);
The README says:

  API documentation
  -----------------

  Currently, there is none. However, the code is well commented and the 
  public API may be found in the "include" directory. The testcase sources 
  may also be of use in working out how to use it.
So I would say that, if you're concerned about documentation, there are much greater deficiencies in documentation than the documentation of this particular limitation.

Perhaps your concern is that 256 mebibytes is actually a reasonable size for a framebuffer, not an invalid argument? With the 32-bit formats all modern displays seem to use, that would be 8192 × 8192. That seems like a colorable argument; I've worked with some images larger than that since last millennium. But it still seems serviceable for most purposes.

With 16-bit ints, it could fail if the framebuffer was larger than 4096 bytes, which seems like a more serious problem, but I don't know if libnsfb can be built on 16-bit and 8-bit platforms.

Sorry, that's printf((char*)37) and free((char*)main).
These are being passed by whoever is using the library. They should be checked before being passed to the function.
Do you prove that every line of arithmetic in your program will not overflow for all possible inputs?

Are you aware that no screen is 64k x 64k?

> Do you prove that every line of arithmetic in your program will not overflow for all possible inputs?

If inputs come from outside, a vehement Yes!

In this particular case they wouldn't. But yes, C is a problem.
It’s a register based computer problem, not a C problem.
Not checking for overflow is a developer problem
Do you suggest branching after every operation?

a = b + c

if err { // … }

>Are you aware that no screen is 64k x 64k?

AmigaOS, I believe from 2.0 onwards, could do that[0].

Width and Height being 16bit attributes of the struct for the requested screen.

I haven't seen an actual monitor able to display the whole thing at once, but that's fine, because you can make your screen gigantic yet set the video output to a much lower resolution.

Intuition will let you scroll through it by moving the mouse pointer past the edge.

0. http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodo...

Does this library serve Amiga developers?
If you mean intuition, it is one of the libraries included in the operating system (usually part of the kickstart ROM).

If you mean amigadev.elowar.com, it is indeed mostly referenced by Amiga developers.

libNSFB, the library being discussed and accused of being low quality because of this range assumption
I mean the integer overflow is the least of your problems. If you try to create a 64000*64000 texture most drivers are going to bark at you anyways in the best case.
>If you try to create a 64000*64000 texture

Huge texture was a quite famous Linux NVIDIA driver vulnerability.