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
_______________________________________________
bugs mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/bugs
