linux-kernel - seccomp: epoll issues post addfd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAFfSco9ZiTAej66dmRjXEpoOECkK7tuterP0rNQvewyA4c1scw@mail.gmail.com>
Date:   Thu, 15 Jul 2021 23:39:42 -0700
From:   Alok Tiagi <atiagi@...flix.com>
To:     linux-kernel@...r.kernel.org
Cc:     rodrigo@...volk.io, alban@...volk.io, sargun@...gun.me,
        Keerti Lakshminarayan <keerti@...flix.com>
Subject: seccomp: epoll issues post addfd

We are using seccomp to intercept syscalls like connect() and using
addfd to install new file descriptors into the client program. We are
running into an issue where any operations by epoll_ctl in the client
programs returns an ENOENT (No such file or directory) after the
syscall interception.

Example:
fd = socket(AF_INET, ...)
epoll_ctl(epoll_fd, EPOLL_CTL_ADD, fd, &event)
connect(fd, ...)

Post interception of the connect() syscall, the file descriptor
registered with epoll is no longer valid and any further epoll_ctl
operations in the client program fail. This is happening because the
original fd is closed causing it to be removed from the epoll
instance.

As a workaround, after addfd and before unblocking the client
program's syscall we traverse the client programs /proc to find all
epoll file descriptors that have the original fd as their target. We
then use pidfd_getfd() to get the client programs epoll_fd and perform
an EPOLL_CTL_ADD operation with the new fd that we installed using
addfd. Before EPOLL_CTL_ADD we ensure that the new fd's number matches
that of the original fd by calling dup2(). This helps further
epoll_ctl operations in the client program to find the fd.

It would be nice if this was handled in the kernel after addfd and I
am wondering if this is an issue which others are facing and if any
solutions have been thought of.

Thanks
Alok