[Bug 297557] fts_close: file descriptor leak if fts_read was never called

[email protected]
Newsgroups gmane.os.freebsd.bugs
Message-ID <[email protected]/bugzilla/>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297557

            Bug ID: 297557
           Summary: fts_close: file descriptor leak if fts_read was never
                    called
           Product: Base System
           Version: 16.0-CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: bin
          Assignee: [email protected]
          Reporter: [email protected]

I just discovered another file descriptor leak, accidentally introduced in
4bd01d6ae01632501b63438b8d9a401db9744a78 .  If a user calls fts_open and then
fts_close without either fts_read or fts_children, the root entry's fts_dirfd
will be leaked.

The leak happens in fts_close, in this section:

        if (sp->fts_cur) {
                for (p = sp->fts_cur; p->fts_level >= FTS_ROOTLEVEL;) {
                        freep = p;
                        p = p->fts_link != NULL ? p->fts_link : p->fts_parent;
                        free(freep);
                }
                if (p->fts_dirfd >= 0)
                        (void)_close(p->fts_dirfd);
                free(p);
        }

What happens is that if sp->fts_cur->fts_dirfd is >= 0 and p->fts_cur >= 0,
then the first free line will free sp->fts_cur, without ever closing fts_dird. 
Then the p pointer will advance, losing the reference to the file descriptor.

STEPS TO REPRODUCE
==================
pkg install valgrind
cd /usr/tests/lib/libc/gen
sudo valgrind --track-fds=yes --trace-children=yes ./fts_set_test
invalid_options

-- 
You are receiving this mail because:
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.