gfx/gfx_thumbnail: fix four heap-safety issues found during audit pass

Four independent issues found during a focused audit of gfx/
gfx_thumbnail.c, the subsystem touched by all four menu drivers
(xmb, ozone, materialui, rgui).  Same audit class as the recent
xmb (9a27e66), ozone (d56c728), and materialui (d5e598a) commits.

* gfx_thumbnail_get_path: missing break on LEFT case
  (gfx/gfx_thumbnail.c)

  The switch in gfx_thumbnail_get_path() that selects which path
  to return based on thumbnail_id is missing a `break` after the
  GFX_THUMBNAIL_LEFT case.  When a caller asks for the LEFT
  thumbnail and *path_data->left_path is empty, control falls
  through to GFX_THUMBNAIL_ICON; if *path_data->icon_path is
  populated, the function returns the icon path *as if it were
  the left thumbnail*.  The caller then loads the icon as the
  left thumbnail texture.

  Wrong-content substitution rather than memory corruption, but
  silent and reachable on any menu where left thumbnails are
  unset but icons are configured (the default for most playlist
  configurations on xmb/ozone/materialui).  Add the missing
  break.

* gfx_thumbnail_get_content_dir: stack buffer overflow on long
  directory paths (gfx/gfx_thumbnail.c)

  The function extracts the basename of the directory portion of
  path_data->content_path by copying that prefix into a local
  tmp_buf[NAME_MAX_LENGTH] and then calling
  path_basename_nocompression() on the copy.  The strlcpy size
  passed is the directory-portion length _len, which is bounded
  only by `_len < PATH_MAX_LENGTH` (i.e. up to 2047) -- but
  tmp_buf is only NAME_MAX_LENGTH (256) bytes.  Whenever the
  directory portion exceeds 255 chars, strlcpy writes up to
  _len-1 bytes into the smaller tmp_buf and corrupts the stack
  past it.

  Reachable on systems with deep folder hierarchies; content_path
  is set from runtime_content_path_basename and other content
  paths capped at PATH_MAX_LENGTH, so 500+ char directory
  prefixes are entirely plausible (a savefile path nested under
  the user's home directory plus a deep ROM organisation
  scheme).

  Fix: anchor the copy at the latest position that still lets
  the directory's last segment fit in tmp_buf, then take the
  basename from there.  We never needed the full prefix in
  tmp_buf -- only its tail -- so dropping the leading bytes when
  _len > sizeof(tmp_buf) gives the same answer without the
  overflow.

* gfx_savestate_thumbnail_get_path: _len underflow in path
  build (gfx/gfx_thumbnail.c)

  Same unsafe pattern that the recent strlcpy_append sweep
  (78c52ab / 25ade82 / e446242 / d5e598a) was created to
  replace, applied here to a mixed strlcpy + snprintf chain:

      _len  = strlcpy(s, state_name, len);
      if (state_slot > 0)
         _len += snprintf(s + _len, len - _len, "%d", state_slot);
      ...
      strlcpy(s + _len, FILE_PATH_PNG_EXTENSION, len - _len);

  Both strlcpy and snprintf return their would-be length on
  truncation, so when state_name approaches @len, _len overshoots
  @len, the next `len - _len` subtraction underflows size_t to
  ~SIZE_MAX, and subsequent calls treat the destination as
  essentially infinite.

  Reachable: state_name is runloop_st->name.savestate which is
  sized PATH_MAX_LENGTH; on a deep ROM directory the savestate
  name itself can fill the buffer, and the slot suffix or .png
  extension push the running total past @len.

  Add explicit truncation guards after each step so the chain
  stays inside the buffer.  Also add the missing `!s || !len`
  guard at the top -- the historical s[0] = '\0' before the
  NULL check was a latent NULL-deref.

* gfx_thumbnail_path_init: malloc -> calloc to zero
  playlist_index (gfx/gfx_thumbnail.c)

  gfx_thumbnail_path_init() allocates the path_data struct via
  malloc and then calls gfx_thumbnail_path_reset(), which
  resets the string buffers and the three playlist_*_mode
  fields but leaves playlist_index untouched -- garbage from
  malloc until the first set_content_*() call writes it.  Read
  sites in xmb (xmb_set_title at xmb.c:2566 and the related
  fallback at xmb.c:7462) sample
  thumbnail_path_data->playlist_index before any setter has
  necessarily run, then pass it to playlist_get_index().  The
  callee bounds-checks against the playlist's size, so a
  garbage index just produces a stale pl_entry rather than a
  crash, but the code is latently UB.

  Switch to calloc.  Cheaper than touching path_reset's API
  and forecloses the issue for any future read site that
  doesn't replicate the bounds-check defence.

Author: LibretroAdmin

gfx/gfx_thumbnail.c

@@ -300,6 +300,7 @@ static bool gfx_thumbnail_get_path(
                *path          = path_data->left_path;
                return true;
             }
+            break;
          case GFX_THUMBNAIL_ICON:
             if (*path_data->icon_path)
             {
@@ -1316,8 +1317,20 @@ void gfx_thumbnail_path_reset(gfx_thumbnail_path_data_t *path_data)
  * Note: Returned object must be free()d */
 gfx_thumbnail_path_data_t *gfx_thumbnail_path_init(void)
 {
+   /* Use calloc rather than malloc.  gfx_thumbnail_path_reset()
+    * resets the string buffers and the playlist_*_mode fields
+    * but does NOT touch playlist_index, leaving it as garbage
+    * from malloc until the first set_content_*() call.  Read
+    * sites in xmb (xmb_set_title) sample
+    * thumbnail_path_data->playlist_index before any setter has
+    * necessarily run, then pass it to playlist_get_index() --
+    * which is bounds-checked, so a garbage index just returns
+    * a stale pl_entry rather than crashing, but the code is
+    * latently UB and a future read site without the same defence
+    * would inherit a real bug.  Zero-init via calloc closes
+    * the window without churning path_reset's API. */
    gfx_thumbnail_path_data_t *path_data = (gfx_thumbnail_path_data_t*)
-      malloc(sizeof(*path_data));
+      calloc(1, sizeof(*path_data));
    if (!path_data)
       return NULL;
 
@@ -1915,14 +1928,32 @@ size_t gfx_thumbnail_get_content_dir(gfx_thumbnail_path_data_t *path_data,
    size_t _len;
    char *last_slash;
    char tmp_buf[NAME_MAX_LENGTH];
+   const char *dir_start;
    if (!path_data || !*path_data->content_path)
       return 0;
    if (!(last_slash = find_last_slash(path_data->content_path)))
       return 0;
    _len = last_slash + 1 - path_data->content_path;
    if (!((_len > 1) && (_len < PATH_MAX_LENGTH)))
       return 0;
-   strlcpy(tmp_buf, path_data->content_path, _len * sizeof(char));
+   /* The historical implementation copied the whole directory
+    * portion of content_path into tmp_buf and then took its
+    * basename.  But content_path is sized PATH_MAX_LENGTH (2048)
+    * and tmp_buf only NAME_MAX_LENGTH (256), so a directory
+    * portion longer than 255 chars (reachable on systems with
+    * deep folder hierarchies) caused strlcpy to write up to
+    * _len-1 bytes into the 256-byte tmp_buf -- a stack overflow.
+    *
+    * Since the goal is the *basename* of the directory (i.e.
+    * the segment between the second-to-last and last slashes),
+    * skip the prefix copy: we only need the tail.  Anchor the
+    * copy at the latest position that still lets the segment
+    * fit in tmp_buf, then take its basename. */
+   dir_start = path_data->content_path;
+   if (_len > sizeof(tmp_buf))
+      dir_start = last_slash + 1 - sizeof(tmp_buf);
+   strlcpy(tmp_buf, dir_start,
+         (last_slash - dir_start + 1) * sizeof(char));
    return strlcpy(s, path_basename_nocompression(tmp_buf), len);
 }
 
@@ -1934,17 +1965,49 @@ void gfx_savestate_thumbnail_get_path(
 {
    size_t _len;
 
+   if (!s || !len)
+      return;
+
    s[0] = '\0';
 
    if (!state_name || !*state_name)
       return;
 
    _len = strlcpy(s, state_name, len);
 
+   /* The historical implementation accumulated _len from
+    * strlcpy / snprintf returns and used `len - _len` as the
+    * size for subsequent calls.  That pattern is NOT
+    * self-bounding: strlcpy returns strlen(@src), and snprintf
+    * returns the would-be length on truncation, so on any
+    * truncating call _len overshoots @len, the next len-_len
+    * subtraction underflows size_t to ~SIZE_MAX, and the
+    * subsequent strlcpy treats the destination as essentially
+    * infinite.  Reachable when state_name approaches PATH_MAX_LENGTH
+    * (e.g. content loaded from a deep directory tree, since
+    * runloop_st->name.savestate is sized PATH_MAX_LENGTH) and
+    * the slot suffix or extension push the total past @len.
+    *
+    * Clamp _len after each truncation so the chain stays inside
+    * the buffer instead of running off the end. */
+   if (_len >= len)
+      _len = len - 1;
+
    if (state_slot > 0)
-      _len += snprintf(s + _len, len - _len, "%d", state_slot);
+   {
+      int n = snprintf(s + _len, len - _len, "%d", state_slot);
+      if (n < 0)
+         return;
+      _len += (size_t)n;
+      if (_len >= len)
+         _len = len - 1;
+   }
    else if (state_slot < 0)
-      _len  = fill_pathname_join_delim(s, state_name, "auto", '.', len);
+   {
+      _len = fill_pathname_join_delim(s, state_name, "auto", '.', len);
+      if (_len >= len)
+         _len = len - 1;
+   }
 
    strlcpy(s + _len, FILE_PATH_PNG_EXTENSION, len - _len);
 }