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