RTEMS | fcntl(F_DUP2FD) onto a free descriptor yields a dead descriptor and leaves its iop on the free list (#5670)

[Sang Woo Kim (@physwkim)]

Issue created by Sang Woo Kim: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5670



Found while testing descriptor duplication for an EPICS IOC, measured on arm/xilinx_zynq_a9_qemu (the dup2()/F_DUP2FD paths are untouched by !1381, so this is the behavior of main).

`duplicate2_iop()` in `cpukit/libcsupport/src/fcntl.c` assumes the target descriptor is open. When it is free the call appears to succeed but every step is wrong: the iop is never unlinked from `rtems_libio_iop_free_head` (the free list linked through `iop->data1`), `LIBIO_FLAGS_OPEN` is never set (the F_DUPFD path sets it after the open handler; F_DUP2FD has no equivalent), and no reference is taken.

```c
int s = socket(AF_INET, SOCK_DGRAM, 0);
int f = open("/tmp-probe", O_CREAT | O_RDWR, 0644);
close(f);                     /* f is now on the iop free list */
fcntl(s, F_DUP2FD, f);        /* returns f: "success" */
fcntl(f, F_GETFL);            /* -1, errno = EBADF */
fstat(f, &st);                /* -1, errno = EBADF */
```

So the caller gets back a descriptor that answers EBADF to everything, while the iop keeps the pathinfo cloned from the source descriptor: that location reference is never released, and the iop is still on the free list, so a later allocation hands it out while it holds the stale clone.

This is reachable directly through the BSD-compat F_DUP2FD command today, and becomes the dup2() path the moment #5669 is fixed. The fix needs an allocate-specific-descriptor step (unlink the target iop from the free list, as `rtems_libio_allocate_minimum()` does for F_DUPFD) and must set `LIBIO_FLAGS_OPEN` on success; the open-target case also wants the close to go through proper accounting rather than a bare `close_h` call.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5670
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/4-42plj18jx969x4eis1c4v206z-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260728/0a995aaf/attachment-0001.htm>