Double-free in libpcap before 1.10.5 with remote packet capture support.

Vulnerability

In affected versions of libpcap, the internal function sock_initaddress() calls getaddrinfo() and possibly freeaddrinfo() but does not clearly indicate to the caller whether freeaddrinfo() still needs to be called after the function returns. This ambiguity leads to a double-free vulnerability when both the function and its caller attempt to free the same addrinfo structure. The issue is present in the remote packet capture (rpcap) subsystem. Affected versions include those prior to the commits that changed the return type of sock_initaddress() (e.g., prior to commit 262e4f34979872d822ccedf9f318ed89c4d31c03). [1][2]

Exploitation

An attacker must be able to trigger the rpcap setup sequence in a way that exercises the double-free code path. This may require network access to initiate a remote capture session. The vulnerability is triggered when sock_initaddress() returns without freeing the addrinfo list, but the caller also calls freeaddrinfo() based on a previous convention. The double-free occurs during the network address resolution phase of setting up a remote packet capture connection. [1][2]

Impact

A double-free of a heap-allocated addrinfo structure can corrupt the heap, leading to a denial of service (application crash) or potentially arbitrary code execution in the context of the process using libpcap. The exact impact depends on the heap allocator implementation and the application. The vulnerability is rated with a CVSS v3.1 score of 7.5 (High) due to potential for remote code execution or crash. [1][2]

Mitigation

The fix was committed to the libpcap repository in commits 2aa69b04d8173b18a0e3492e0c8f2f7fabdf642d and 262e4f34979872d822ccedf9f318ed89c4d31c03. These change sock_initaddress() to return the addrinfo pointer directly (or NULL on failure), making the ownership clear to the caller. Users should upgrade to a version of libpcap containing these commits. No workaround is publicly available. [1][2]