input: fix OOM handling in wl_read_pipe and rwebinput_keyboard_cb

Two independent real OOM bugs in input-path buffer-growth code.

=== input/common/wayland_common.c: wl_read_pipe ===

The function reads one PIPE_BUF-sized chunk off a Wayland clipboard
/ drag-and-drop pipe into '*buffer', growing it per-call.  The
caller's loop pattern is:

    while (wl_read_pipe(pipefd[0], &buffer, length, null_terminate) > 0);

i.e. keep reading until bytes_read <= 0 (0 = EOF, <0 = error).

Pre-patch, when the malloc / realloc inside the function failed,
the else-branch of the 'if (output_buffer)' alloc check was
missing entirely.  The flow was:

    pos              = *total_length;
    *total_length   += bytes_read;        /* committed early */
    ...
    output_buffer = realloc(*buffer, _len);
    if (output_buffer) { memcpy(...); *buffer = output_buffer; }
    /* else: fall through, return bytes_read (positive!) */

On OOM:
  - The bytes we just read off the pipe are silently dropped
    (temp[] is a stack buffer, overwritten on the next read()).
  - *total_length has already been incremented, so the caller
    believes the buffer has grown.
  - *buffer is unchanged - on realloc failure it still points at
    the old, smaller allocation.  So the invariant 'size of
    *buffer is *total_length' is broken: the recorded length is
    larger than the actual allocation.
  - Return value is bytes_read > 0, so the caller's while-loop
    continues.  Next iteration:
      pos = *total_length          /* over-sized */
      *total_length += bytes_read
      output_buffer = realloc(*buffer, _len)
    If that one succeeds, the memcpy at offset 'pos' writes past
    the end of what was actually in *buffer - corrupting arbitrary
    heap memory if realloc gave us a buffer exactly sized to the
    caller's new *total_length but missing the gap from the
    failed iteration.

Fix: on allocation failure, rewind *total_length to pos (the
pre-increment value) and return -1.  The caller's while-loop
then terminates; the partial data already stored in *buffer
remains valid and consistent with the (now-un-incremented)
*total_length.  The current-iteration's bytes_read are lost,
which is the same failure mode as any other mid-transfer pipe
read error (not worse).

=== input/drivers/rwebinput_input.c: rwebinput_keyboard_cb ===

The Emscripten rwebinput driver grows its pending-keyboard-event
ring on demand inside the keyboard callback:

    if (rwebinput->keyboard.count >= rwebinput->keyboard.max_size)
    {
       size_t new_max = MAX(1, rwebinput->keyboard.max_size << 1);
       rwebinput->keyboard.events = realloc(rwebinput->keyboard.events,
          new_max * sizeof(rwebinput->keyboard.events[0]));
       rwebinput->keyboard.max_size = new_max;
    }
    rwebinput->keyboard.events[rwebinput->keyboard.count].type = event_type;
    memcpy(&rwebinput->keyboard.events[...].event, key_event, ...);

Two bugs:

(1) 'events = realloc(events, ...)' is the classic realloc-assign-
    self leak: on OOM realloc returns NULL but leaves the original
    buffer valid; the self-assign overwrites the only pointer to
    it, leaking the entire pending-event ring (and any events
    already in it that weren't yet consumed).

(2) max_size is updated unconditionally after the realloc, before
    the return value is inspected.  Then the field-write and
    memcpy below dereference the now-NULL events pointer - a
    NULL-deref crash.  Any state that survived would claim
    'max_size holds 2N events' while actually holding zero.

Fix: realloc into a temp, NULL-check, and only commit both
events-pointer and max_size on success.  On OOM drop this one
event on the floor and return EM_TRUE (the Emscripten callback
convention); losing a single key event in a memory-starved
browser tab is survivable - the pre-patch form was going to
crash the whole page.

=== Thread-safety ===

Neither path's locking changes.  wl_read_pipe runs on whatever
thread services the Wayland event loop; rwebinput_keyboard_cb
runs on the Emscripten main thread.

=== Reachability ===

wl_read_pipe fires on every clipboard paste / drag-and-drop drop
onto a Wayland-native RetroArch window.  rwebinput_keyboard_cb
fires on every keyboard event in the web build; the ring-growth
path triggers only when the input consumer falls behind (rare
under normal play, common during loading screens where the main
thread is blocked).

Author: LibretroAdmin

input/common/wayland_common.c

@@ -900,6 +900,27 @@ static ssize_t wl_read_pipe(int fd, void** buffer, size_t* total_length,
 
             *buffer = output_buffer;
          }
+         else
+         {
+            /* Allocation failed.  Previously this branch silently
+             * dropped the bytes_read data, left *total_length
+             * incremented (so the caller thought the buffer had
+             * grown), and returned a positive bytes_read - the
+             * caller's 'while (wl_read_pipe(...) > 0)' loop then
+             * continued and the next iteration wrote at offset
+             * 'pos = *total_length' which sat past the end of the
+             * still-unchanged *buffer, corrupting whatever lived
+             * there.  On realloc failure *buffer is also left
+             * pointing at the old (smaller) allocation, so the
+             * old data is still valid, but the length accounting
+             * is a lie.
+             *
+             * Restore the invariant by rewinding *total_length
+             * and reporting -1 to the caller so its while-loop
+             * terminates. */
+            *total_length = pos;
+            bytes_read    = -1;
+         }
       }
    }
 

input/drivers/rwebinput_input.c

@@ -261,10 +261,33 @@ static EM_BOOL rwebinput_keyboard_cb(int event_type,
 
    if (rwebinput->keyboard.count >= rwebinput->keyboard.max_size)
    {
-      size_t new_max = MAX(1, rwebinput->keyboard.max_size << 1);
-      rwebinput->keyboard.events = realloc(rwebinput->keyboard.events,
+      size_t new_max                   = MAX(1, rwebinput->keyboard.max_size << 1);
+      void  *tmp                       = realloc(rwebinput->keyboard.events,
          new_max * sizeof(rwebinput->keyboard.events[0]));
-      rwebinput->keyboard.max_size = new_max;
+      /* Two bugs in the pre-patch form.
+       *
+       * (1) 'events = realloc(events, ...)' is the classic realloc-
+       *     assign-self leak: on OOM realloc returns NULL but the
+       *     original buffer is still valid; the self-assign
+       *     overwrites the only pointer to it, leaking the whole
+       *     pending-event ring.
+       * (2) max_size was being updated unconditionally after the
+       *     realloc, before the return value was even inspected.
+       *     On OOM we then walked into the field writes below
+       *     which NULL-deref'd 'events' - but the recorded
+       *     max_size claimed the larger size, so any surviving
+       *     state said 'the buffer can hold 2N events' while
+       *     actually holding zero.
+       *
+       * On OOM drop this one event on the floor (the keyboard
+       * event ring is bounded and the loss of a single input
+       * event in a memory-starved system is survivable; we were
+       * going to crash previously).  Both max_size and events
+       * stay at their pre-realloc values. */
+      if (!tmp)
+         return EM_TRUE;
+      rwebinput->keyboard.events       = tmp;
+      rwebinput->keyboard.max_size     = new_max;
    }
 
    rwebinput->keyboard.events[rwebinput->keyboard.count].type = event_type;