Source: libpcap Version: 1.10.6-2 Severity: important Tags: security upstream X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerabilities were published for libpcap. CVE-2026-0799[0]: | 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. CVE-2026-18238[1]: | 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. CVE-2026-18313[2]: | 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. CVE-2026-31911[3]: | 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. CVE-2026-31912[4]: | 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. CVE-2026-6244[5]: | 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. CVE-2026-6554[6]: | 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. In | particular uncommon use cases a crafted filter program can cause the | interpreter to loop infinitely. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-0799 https://www.cve.org/CVERecord?id=CVE-2026-0799 [1] https://security-tracker.debian.org/tracker/CVE-2026-18238 https://www.cve.org/CVERecord?id=CVE-2026-18238 [2] https://security-tracker.debian.org/tracker/CVE-2026-18313 https://www.cve.org/CVERecord?id=CVE-2026-18313 [3] https://security-tracker.debian.org/tracker/CVE-2026-31911 https://www.cve.org/CVERecord?id=CVE-2026-31911 [4] https://security-tracker.debian.org/tracker/CVE-2026-31912 https://www.cve.org/CVERecord?id=CVE-2026-31912 [5] https://security-tracker.debian.org/tracker/CVE-2026-6244 https://www.cve.org/CVERecord?id=CVE-2026-6244 [6] https://security-tracker.debian.org/tracker/CVE-2026-6554 https://www.cve.org/CVERecord?id=CVE-2026-6554 Regards, Salvatore
