infinte loop in libpcap before 1.10.7

libpcap BPF interpreter treats the offset in the 'ja L' BPF instruction as a signed integer to implement looping via backward jumps, but it does not limit the number of loop iterations. A crafted filter program or the 'protochain' primitive used on a crafted network packet can cause the interpreter to loop infinitely.

division by zero in libpcap before 1.10.7

libpcap BPF interpreter for the 'div #k' and 'mod #k' ALU instructions does not check whether the immediate value is zero. In particular uncommon use cases a crafted filter program can cause a division by zero.

OOBR and OOBW in libpcap before 1.10.7

In BPF instructions that load/store a value from/to a scratch memory register the register index is an unsigned 32-bit integer and must not exceed 15, but libpcap BPF interpreter does not validate the value. In particular uncommon use cases a crafted filter program can cause the interpreter to try reading and writing the OS process memory in the 16GiB starting at the current stack frame on 64-bit architectures and in the entire address space on 32-bit architectures.

abort() in libpcap before 1.10.7 on an invalid BPF opcode

libpcap BPF interpreter calls abort() if it encounters a BPF instruction that has an invalid opcode. In particular uncommon use cases a crafted filter program can terminate the OS process.

rpcapd memory leak in libpcap before 1.10.7

rpcapd can allocate up to 65536 bytes per each RPCAP_MSG_UPDATEFILTER_REQ or RPCAP_MSG_STARTCAP_REQ message received from the client, but it never frees the memory, so it leaks memory even under normal use. A malicious client can cause the server to leak memory substantially faster.

OOBR in rpcap client in libpcap before 1.10.7

The rpcap client code that processes a RPCAP_MSG_PACKET message received from the server incorrectly validates its headers. A malicious server can send a crafted message and cause the client to treat up to 20 bytes of the client process memory beyond the end of the buffer as if it was a part of the captured packet.

OOBR in libpcap before 1.10.7

libpcap BPF interpreter detects neither reaching the end of the filter program buffer due to lack of a return instruction nor executing a jump instruction with an offset that translates to a pointer outside of the buffer. In particular uncommon use cases a crafted filter program can cause the interpreter to try reading the OS process memory in the 32GiB around the buffer on 64-bit architectures and in the entire address space on 32-bit architectures.

OOBR and OOBW in pcap_ether_aton() in libpcap

pcap_ether_aton() is an auxiliary function in libpcap, it takes a string argument and returns a fixed-size allocated buffer. The string argument must be a well-formed MAC-48 address in one of the supported formats, but this requirement has been poorly documented. If an application calls the function with an argument that deviates from the expected format, the function can read data beyond the end of the provided string and write data beyond the end of the allocated buffer.

OOBW in utf_16le_to_utf_8_truncated() in libpcap

On Windows only, if libpcap needs to convert a Windows error message to UTF-8 and the message includes characters that UTF-8 represents using 4 bytes, utf_16le_to_utf_8_truncated() can write data beyond the end of the provided buffer.

libpcap: Resource exhaustion during PHB header length validation

sf-pcapng.c in libpcap before 1.9.1 does not properly validate the PHB header length before allocating memory.

pcap-linux.c in libpcap 1.1.1 before commit ea9432fabdf4b33cbc76d9437200e028f1c47c93 when snaplen is set may truncate packets, which might allow remote attackers to send arbitrary data while avoiding detection via crafted packets.

libpcap: Server side request forgery in rpcapd/daemon.c

rpcapd/daemon.c in libpcap before 1.9.1 allows SSRF because a URL may be provided as a capture source.

libpcap: Null pointer dereference in rpcapd/daemon.c

rpcapd/daemon.c in libpcap before 1.9.1 allows attackers to cause a denial of service (NULL pointer dereference and daemon crash) if a crypt() call fails.

libpcap: Information disclosure in rpcapd/daemon.c

rpcapd/daemon.c in libpcap before 1.9.1 on non-Windows platforms provides details about why authentication failed, which might make it easier for attackers to enumerate valid usernames.

libpcap: Mishandled length values in reused variables

rpcapd/daemon.c in libpcap before 1.9.1 mishandles certain length values because of reuse of a variable. This may open up an attack vector involving extra data at the end of a request.

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

In affected libpcap versions during the setup of a remote packet capture the internal function sock_initaddress() calls getaddrinfo() and possibly freeaddrinfo(), but does not clearly indicate to the caller function whether freeaddrinfo() still remains to be called after the function returns. This makes it possible in some scenarios that both the function and its caller call freeaddrinfo() for the same allocated memory block. A similar problem was reported in Apple libpcap, to which Apple assigned CVE-2023-40400.

NULL pointer dereference in libpcap before 1.10.5 with remote packet capture support

Remote packet capture support is disabled by default in libpcap. When a user builds libpcap with remote packet capture support enabled, one of the functions that become available is pcap_findalldevs_ex(). One of the function arguments can be a filesystem path, which normally means a directory with input data files. When the specified path cannot be used as a directory, the function receives NULL from opendir(), but does not check the return value and passes the NULL value to readdir(), which causes a NULL pointer derefence.