libcurl: pooled TLS connection outlives its easy handle and reuses a freed OpenSSL library context

Impact

libcurl attaches an allocated OpenSSL library context to an easy handle without taking an ownership reference, but a pooled TLS connection can outlive that handle. Destroying the easy handle frees the context while a live connection still holds the pointer, so later I/O or post-handshake work on that connection is a heap use-after-free. On a GPU fleet libcurl is not a user-facing app but a dependency inside the daemons that move data - registry and model pulls, object-store and telemetry clients, cluster agents - so the crash or memory corruption lands in a long-running process on the node rather than in a short CLI invocation. The record does not establish attacker-controlled exploitation; the observable consequence stated is a use-after-free on subsequent I/O, and the affected configuration is specific (multi interface plus an OpenSSL 3 provider configuration).

Who can reach it

Not directly reachable by an unauthenticated remote party per this record. It requires a process that uses libcurl's multi interface against an OpenSSL 3 provider configuration and releases easy handles while pooled connections remain; a peer that keeps a connection alive and continues post-handshake traffic is in a position to hit the freed context. No authentication step is described.

What to do

Update the system libcurl/curl package to the fixed release named in curl's own advisory (curl.se/docs/CVE-2026-80229.html) - the NVD record carries no fixed version, so take it from the vendor page. Because libcurl is loaded into long-lived processes, a package update alone is not enough: restart every daemon and container image that links it, and rebuild any image that vendors a static libcurl. No node reboot or drain is required; rolling daemon and pod restarts are sufficient.

References

Related entries

• Linux kernel CephFS client: readers hang indefinitely after cap revocation leaves stale mds_wantedCVE-2026-80527 · Linux kernel CephFS client (__ceph_get_caps / ceph_renew_caps, stale cap->mds_wanted)Unscored
• Linux kernel CephFS client: reclaim during MDS reply handling crashes the kernel via ext4 journal_infoCVE-2026-80528 · Linux kernel CephFS client (handle_reply / current->journal_info vs direct reclaim)Unscored
• Linux kernel libceph: out-of-bounds read in decode_watchers() from a zero-length struct_lenCVE-2026-80557 · Linux kernel libceph (decode_watchers(), CEPH_OSD_OP_LIST_WATCHERS reply parsing)Unscored
• Linux kernel libceph: unvalidated primary_temp OSD index causes out-of-bounds array readsCVE-2026-80558 · Linux kernel libceph (get_temp_osds(), unvalidated primary_temp OSD index)Unscored
• Linux kernel libceph: unchecked decodes in decode_locker() let a malicious OSD read out of boundsCVE-2026-80561 · Linux kernel libceph (cls_lock_client decode_locker)Unscored
• Linux kernel AMD LBR: user-only branch sampling leaks kernel addresses to unprivileged usersCVE-2026-80602 · Linux kernel perf/x86/amd/lbr (AMD LBR v2 branch stack filtering)Unscored