LibBSD | kqueue: the hold is still leaked when fget() fails, and closefp() drops the wrong descriptor's knotes (#102)

Sang Woo Kim (@sngwkim915) gitlab at rtems.org
Tue Jul 28 06:46:24 UTC 2026



Issue created by Sang Woo Kim: https://gitlab.rtems.org/rtems/pkg/rtems-libbsd/-/work_items/102



## Summary

Two things remain in the area #41 / #42 / #43 closed, both on the current `7-freebsd-14` and `6-freebsd-14`. Found by reading the code while working on #101, not by a failing test.

`50d0f16d` (!70) drops the hold only when `fget()` succeeds:

```c
if (iop == NULL) {
        error = fget(td, ffd, &cap_event_rights, &fp);
        if (!error) {
                rtems_bsd_libio_iop_drop(kev->ident);
        }
}
```

`rtems_bsd_libio_iop_hold(kev->ident, &iop)` has already taken the reference by then, whatever `fget()` does next, so a failing `fget()` leaks it and the descriptor can never be closed — #41's symptom on a narrower path. The drop belongs outside the `if`.

Second, `closefp_impl()` passes `knote_fdclose()` a BSD descriptor, but `kqueue_register()` indexes a knote by the identifier the caller passed, which for a libbsd descriptor is the libio one. It misses the closing file's knotes, leaving the reference they hold on `fp`, and drops the knotes of whichever unrelated libio descriptor has that number. This is only observable once a file can have more than one descriptor, so it comes with #101.

`testsuite/selectpollkqueue01` passes on `arm/xilinx_zynq_a9_qemu` before and after this change with identical output, so it says nothing about #69 either way.

Fix: [7-freebsd-14](https://github.com/physwkim/rtems-libbsd/commit/92df493d1e5418da8c4bdda8dc2c40dabb2bc616) · [6-freebsd-14](https://github.com/physwkim/rtems-libbsd/commit/d27be17071d3183be8f15979c0b104c0fb9e45e7) · [6-freebsd-12](https://github.com/physwkim/rtems-libbsd/commit/6cef9d5992b42eea2eca9180dda72de6c16a4d76)

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/pkg/rtems-libbsd/-/work_items/102
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/4-ap3pcitxyafpq7vlydkz85dks-k/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/611898a1/attachment.htm>


More information about the bugs mailing list