eventfd double close

Vulnerability

In curl versions 8.11.1 built with the threaded resolver and eventfd support (64-bit architectures only), libcurl incorrectly closes the same eventfd file descriptor twice when tearing down a connection channel after a threaded name resolution completes. The double-close results from an #ifdef mistake that left a superfluous close() call originally written for socketpair-based inter-thread messaging. This vulnerability is assigned CWE-1341 (Multiple Releases of Same Resource or Handle) and affects only curl 8.11.1; versions before 8.11.1 and from 8.12.0 onward are not affected [1].

Exploitation

An attacker would need no special privileges but must rely on the race window where the second close() occurs within a few dozen instructions after the first. Because the window is extremely narrow, controlled exploitation to cause a specific file descriptor to be closed in place of the eventfd is considered unlikely. The vulnerability is reachable automatically whenever libcurl performs a threaded name resolution, without user interaction beyond making a curl request that triggers a DNS lookup [1].

Impact

Successful double-close leads to unreliable behavior in libcurl, potentially causing the library to close an unrelated file descriptor that may have been opened between the two close() calls. This could result in interference with the application's file descriptor table, but the limited race window makes arbitrary code execution or information disclosure improbable. The curl command-line tool is also affected when built similarly [1].

Mitigation

Upgrade to curl version 8.12.0, released on February 5, 2025, which contains the fix [1]. Users of curl 8.11.1 who cannot upgrade immediately may apply the patch from commit ff5091aa9f55 or avoid building with eventfd on 64-bit systems. No workaround exists for the vulnerable version other than upgrading or rebuilding without eventfd. This vulnerability is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog as of publication [1].