Re: [SECURITY ADVISORY] curl: CVE-2025-0665: eventfd double close

Demi Marie Obenour <[email protected]>
Newsgroups gmane.comp.security.oss.general,gmane.comp.web.curl.general,gmane.comp.web.curl.library
Message-ID <Z6OcuMJupHURWFvR@itl-email>
On Wed, Feb 05, 2025 at 09:21:39AM +0100, Daniel Stenberg wrote:
> eventfd double close
> ====================
> 
> Project curl Security Advisory, February 5th 2025 -
> [Permalink](https://curl.se/docs/CVE-2025-0665.html)
> 
> VULNERABILITY
> -------------
> 
> libcurl would wrongly close the same eventfd file descriptor twice when taking
> down a connection channel after having completed a threaded name resolve.
> 
> INFO
> ----
> 
> This flaw requires libcurl to get built with the threaded resolver
> 
> It requires that *eventfd* is used in the curl build. This feature is only
> used on 64-bit architectures.
> 
> The eventfd socket is used for inter-thread messaging and since the
> communication was originally written to use `socketpair()` only, there was two
> `close()` calls done and the superfluous one was left accidentally used
> because of an `#ifdef` mistake.
> 
> This bug was reported (and fixed) immediately after the 8.11.1 release, but
> the security impact was not considered until later. This bug causes libcurl to
> act unreliably which many users will have noticed and either avoided eventfd
> or the vulnerable version, thus somewhat reducing the impact of this problem.
> 
> It can also be worth noting that both `close()` calls are typically called
> within a few dozens of instructions, severely limiting the ability for an
> external party to control which other file descriptor this can be made to
> affect.
> 
> This bug is **not** considered a *C mistake*. It is not likely to have been
> avoided had we not been using C.

I think this is actually a C mistake.  In most higher-level languages,
it is idiomatic to use higher-level APIs that prevent closing the same
file descriptor multiple times, and Rust enforces this in the type
system.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmejnLQACgkQszaHOrMp
8lP+aw/9G0CSIg6DzfYtUnc5SMvOpdwkbxHGir1fjKfhomH2PdYEJx8CzKtOyjwW
S3WjvaKYTytD41Jry1Uvt7m/7LAnC+RxwjuuHxBK73YhS+gDC2N0zwSBH4y2NTrJ
VsfXAbhrq9fjT4uJVPMzqou/+SjR472KUiJkv541ml/bv5tVfbvGPadstCvSG9Ac
7MOq+fHIu2t1RIhYa5vvXsfiMeftUS96srg2DXjYe3bW4a5IzDjVEudCHsGqmV6A
Y6d3MBgKVZ+LzrdvkuuDVeEyhJUzZrtoIy/kh9Si0LF0jyDyuYZa/QroDiGnPG+Y
ZcprvG9Boj7Nj0A+afn10RuJ4Pndgf2K0qVcskOLDcZM39RSX5fTDDKMCVz290Rb
ha4wDa89HtQ8OV1rPN2gdaKrxs+SKB2otXCZD1eIpJlLN5lsSivYgxKEVxCHCn/5
s7wyOcMduPEwJGGYCe9dU/btJ25nnT64ytINLOuwiHtKdMSpz4sP/tYfSOz/DnXg
VHoceW1tina6VtiJwer5OmaoTwjZZmS6tNjFUnPYd9BpO23I2+7oOdUbN1v0jTpU
SopMiFk/H4wG93zpvkDc46MnjgUhNYUbJt4Xmwcym2O6C5HiihRDjdDdiWMcJe6/
n3C+ddEg9DQW+/UpWB+4HGCPjzhwizfUCXTYe1SXKXRJdr/P7Gw=
=zqLX
-----END PGP SIGNATURE-----
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.