exec: fix use-after-free on concurrent calls

[xyzmean]

What this fixes

rpcd can be terminated by SIGSEGV through a use-after-free in exec.c when
several of its methods run at the same time. The two commits fix the two
independent halves of it.

1. The epoll registration is never removed

rpc_exec_process_cb() closes the stdout/stderr pipe descriptors and then sets
the stored descriptor to -1:

	close(c->opipe.fd.fd);
	close(c->epipe.fd.fd);

	/* ustream_free() does not reset the fd, and rpc_exec_reply() closes it
	 * again later.  Mark the descriptors as consumed so that the second
	 * close() cannot accidentally close an unrelated, meanwhile reused fd. */
	c->opipe.fd.fd = -1;
	c->epipe.fd.fd = -1;

The intent of that -1 is sound, but the unregistration from uloop only happens
afterwards, in rpc_exec_reply() via ustream_free() → uloop_fd_delete().
By then the descriptor field is -1, so the epoll_ctl(EPOLL_CTL_DEL, -1)
performed there fails with EBADF. No caller checks that return value, so the
failure is silent and the registration stays in the epoll set, still pointing at
&c->opipe.fd — memory that rpc_exec_reply() frees a few lines later with
free(c).

2. Children inherit the pipes of their siblings

The pipes are created with plain pipe(), without O_CLOEXEC. A child forked
for one call therefore inherits every pipe belonging to the calls that are still
in flight, and passes them on to whatever it execs.

When it surfaces

Neither half is enough on its own, which is why this is easy to miss.

Normally the stale registration is harmless: closing the last descriptor of an
open file description drops its epoll registrations as a side effect, so the
kernel cleans up what uloop_fd_delete() failed to remove.

That only holds while nobody else has a copy of the pipe. With concurrent calls
somebody does — see (2). A sibling child keeps the file description of an already
finished call alive, so the stale registration stays valid past free(c). When
the pipe finally reports EPOLLHUP, uloop_fetch_events() picks the dangling
uloop_fd out of epoll_event.data.ptr, writes to it (u->error = true) and
dereferences it further.

So the crash needs two calls to overlap, and it needs one of them to finish while
the other is still running. Single, serialized calls never trigger it — which is
why it tends to show up under web frontends that issue several ubus calls in
parallel while a page is open, and not in manual ubus call testing. The visible
symptom is rpcd dying and being restarted by procd; since sessions live in its
memory, every logged-in user is asked to log in again.

The mechanism can be reproduced without rpcd at all:

int ep = epoll_create1(0), p[2];
pipe(p);
struct epoll_event ev = { .events = EPOLLIN, .data.ptr = (void *)0xDEADBEEF };
epoll_ctl(ep, EPOLL_CTL_ADD, p[0], &ev);

int copy = dup(p[0]);          /* stands in for the inherited descriptor */
close(p[1]);
close(p[0]);                   /* the registered descriptor is gone ... */

epoll_ctl(ep, EPOLL_CTL_DEL, -1, NULL);   /* what uloop ends up doing: EBADF */

struct epoll_event got[4];
epoll_wait(ep, got, 4, 200);
/* -> 1 event, events=0x10 (EPOLLHUP), data.ptr=0xdeadbeef
      i.e. the registration outlived the close() and still hands back the
      pointer that rpcd has meanwhile freed */

Closing copy afterwards makes the registration disappear on its own, which is
exactly why the bug is invisible without concurrency.

The fix

• Call uloop_fd_delete() for both pipes in rpc_exec_process_cb() before
  closing them, while the descriptors are still valid. The existing -1
  assignment and the double-close protection it provides are left untouched.
• Create the pipes with pipe2(..., O_CLOEXEC).

Either change alone removes the crash. Keeping both is deliberate: the first
fixes the actual lifetime bug, the second removes the condition that makes it
reachable, and additionally stops leaking descriptors into every process spawned
by exec-based plugins. dup2() onto 0/1/2 in the child does not carry the flag
over, so the child's own pipes are unaffected.

Testing

Built against 25.12-SNAPSHOT and run on a ramips/mt7621 device
(OpenWrt 25.12.5, musl). A script issuing the same burst of parallel calls that a
web frontend makes crashes stock rpcd on the first round; with these commits it
completed 40 rounds without a crash.

The original diagnosis came from a core dump on that device: pc in
uloop_run_timeout(), with the epoll_event array holding
{events=0x10, data.ptr=0x77c21780} where that address is not mapped in the
dump at all.