The remote Fedora 38 host has packages installed that are affected by multiple vulnerabilities as referenced in the FEDORA-2023-d486d13cfd advisory.

  - stb_image is a single file MIT licensed library for processing images. A crafted image file may trigger     out of bounds memcpy read in `stbi__gif_load_next`. This happens because two_back points to a memory     address lower than the start of the buffer out. This issue may be used to leak internal memory allocation     information. (CVE-2023-45661)

  - stb_image is a single file MIT licensed library for processing images. When     `stbi_set_flip_vertically_on_load` is set to `TRUE` and `req_comp` is set to a number that doesn't match     the real number of components per pixel, the library attempts to flip the image vertically. A crafted     image file can trigger `memcpy` out-of-bounds read because `bytes_per_pixel` used to calculate     `bytes_per_row` doesn't match the real image array dimensions. (CVE-2023-45662)

  - stb_image is a single file MIT licensed library for processing images. The stbi__getn function reads a     specified number of bytes from context (typically a file) into the specified buffer. In case the file     stream points to the end, it returns zero. There are two places where its return value is not checked: In     the `stbi__hdr_load` function and in the `stbi__tga_load` function. The latter of the two is likely more     exploitable as an attacker may also control the size of an uninitialized buffer. (CVE-2023-45663)

  - stb_image is a single file MIT licensed library for processing images. A crafted image file can trigger     `stbi__load_gif_main_outofmem` attempt to double-free the out variable. This happens in     `stbi__load_gif_main` because when the `layers * stride` value is zero the behavior is implementation     defined, but common that realloc frees the old memory and returns null pointer. Since it attempts to     double-free the memory a few lines below the first free, the issue can be potentially exploited only in     a multi-threaded environment. In the worst case this may lead to code execution. (CVE-2023-45664)

  - stb_image is a single file MIT licensed library for processing images. It may look like     `stbi__load_gif_main` doesn't give guarantees about the content of output value `*delays` upon failure.
    Although it sets `*delays` to zero at the beginning, it doesn't do it in case the image is not recognized     as GIF and a call to `stbi__load_gif_main_outofmem` only frees possibly allocated memory in `*delays`     without resetting it to zero. Thus it would be fair to say the caller of `stbi__load_gif_main` is     responsible to free the allocated memory in `*delays` only if `stbi__load_gif_main` returns a non null     value. However at the same time the function may return null value, but fail to free the memory in     `*delays` if internally `stbi__convert_format` is called and fails. Thus the issue may lead to a memory     leak if the caller chooses to free `delays` only when `stbi__load_gif_main` didn't fail or to a double-     free if the `delays` is always freed (CVE-2023-45666)

  - stb_image is a single file MIT licensed library for processing images. If `stbi__load_gif_main` in     `stbi_load_gif_from_memory` fails it returns a null pointer and may keep the `z` variable uninitialized.
    In case the caller also sets the flip vertically flag, it continues and calls `stbi__vertical_flip_slices`     with the null pointer result value and the uninitialized `z` value. This may result in a program crash.
    (CVE-2023-45667)

  - Double Free vulnerability in Nothings Stb Image.h v.2.28 allows a remote attacker to cause a denial of     service via a crafted file to the stbi_load_gif_main function. (CVE-2023-43281)

  - stb_vorbis is a single file MIT licensed library for processing ogg vorbis files. A crafted file may     trigger out of bounds write in `f->vendor[len] = (char)'\0';`. The root cause is that if the len read in     `start_decoder` is `-1` and `len + 1` becomes 0 when passed to `setup_malloc`. The `setup_malloc` behaves     differently when `f->alloc.alloc_buffer` is pre-allocated. Instead of returning `NULL` as in `malloc` case     it shifts the pre-allocated buffer by zero and returns the currently available memory block. This issue     may lead to code execution. (CVE-2023-45675)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

Detections

Analytics

Fedora 38 : stb / usd (2023-d486d13cfd)

critical Nessus Plugin ID 184401

Version 1.0