Builder libpcap-solaris11-i386 Build #177

Results:

Build successful

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-libpcap-solaris11-i386' triggered this build

Steps and Logfiles:

1. git update ( 5 mins, 6 secs )
   1. stdio
2. shell './build_matrix.sh' ( 7 hrs, 48 mins, 26 secs )
   1. stdio
   2. config.log
3. trigger triggered trigger-tcpdump-solaris11-i386 ( 3 hrs, 19 mins, 26 secs )
   1. - no logs -
   2. tcpdump-solaris11-i386 #175

Build Properties:

Forced Build Properties:

Responsible Users:

1. Denis Ovsienko

   denisohnoyoudont@ovsienko.info

Timing:

All Changes:

:

1. Change #280844

   Category	libpcap
   Changed by	Denis Ovsienko <denisohnoyoudont@ovsienko.info>
   Changed at	Sat 05 Sep 2026 11:03:46
   Repository	https://git.tcpdump.org/libpcap
   Project	libpcap
   Branch	master
   Revision	2368ad2f49fa7b0c439903b296c0a6fa8a3766d3

   Comments

   Implement testing of arbitrary filter programs.
   In filtertest implement support for cbpf-savefile as an input format for
   filter programs.  In TESTrun implement a cbpf-savefile generator to feed
   filtertest and a minimal BPF assembler to feed the generator.  Introduce
   a new "fcode" test type, which bypasses pcap_compile() and exercises the
   validator and the interpreter directly and independently of each other.

   Changed files

   • testprogs/TESTrun
   • testprogs/filtertest.c

2. Change #280845

   Category	libpcap
   Changed by	Denis Ovsienko <denisohnoyoudont@ovsienko.info>
   Changed at	Sat 05 Sep 2026 11:03:46
   Repository	https://git.tcpdump.org/libpcap
   Project	libpcap
   Branch	master
   Revision	569f8fd3524192acbabf93c9cd704471bb38f84a

   Comments

   CVE-2026-0799: Access M[] safely in the BPF interpreter.
   Include Security identified and reported this problem as a potential
   vulnerability in 2018 (case reference "I7").  Their work was sponsored
   by Mozilla under the Secure Open Source program.  The vulnerability has
   been independently confirmed only recently.
   
   The current revision of pcapint_filter_with_aux_data() can, but does not
   check whether a scratch memory register index is valid in the "ld M[k]",
   "ldx M[k]", "st M[k]" and "stx M[k]" BPF instructions, and assumes this
   is always the case.  This holds for programs that have been generated or
   validated by libpcap.
   
   However, this does not necessarily hold for programs that come via
   pcap_offline_filter() or [deprecated] bpf_filter() from an external
   source and have not been explicitly validated.  If the interpreter
   executes such a program with an invalid index, it will read/write the
   process memory at arbitrary locations starting at the current stack
   frame.  Depending on the address, the memory layout and the OS, this can
   result in stack buffer overflow, SIGSEGV, SIGBUS or other effects.  To
   fix this, in the interpreter reject the packet if the index is invalid.

   Changed files

   • CHANGES
   • bpf_filter.c
   • testprogs/TESTrun

3. Change #280846

   Category	libpcap
   Changed by	Denis Ovsienko <denisohnoyoudont@ovsienko.info>
   Changed at	Sat 05 Sep 2026 11:03:46
   Repository	https://git.tcpdump.org/libpcap
   Project	libpcap
   Branch	master
   Revision	d1209988c74dd9330659898d3b676ee6bbe1c551

   Comments

   CVE-2026-31912: Mind the program bounds in pcap_offline_filter().
   The current revision of pcapint_filter_with_aux_data() does not know the
   number of instructions in the filter program, it assumes the program
   counter always remains within the bounds of the provided filter program
   and always reaches a return instruction.  This holds for programs that
   have been generated or validated by libpcap.
   
   However, this does not necessarily hold for programs that come from an
   external source via pcap_offline_filter() or [deprecated] bpf_filter()
   and have not been explicitly validated.  If the interpreter executes
   such a program and advances the program counter beyond the last
   instruction, it will be interpreting memory space after the filter
   program as BPF instructions, which in the current implementation will
   eventually cause either abort() (another commit addresses that) or
   SIGSEGV.
   
   To fix the latter problem, in pcapint_filter_with_aux_data() add a
   parameter for the number of instructions in the program and reject the
   packet as soon as (or just before) the program counter goes out of
   bounds.  Update all incoming code paths to specify the length; also in
   pcap_offline_filter(3PCAP) make it clear the function now requires the
   'bf_len' member to be set correctly and uses it.

   Changed files

   • CHANGES
   • bpf_filter.c
   • dlpisubs.c
   • pcap-bpf.c
   • pcap-bt-linux.c
   • pcap-bt-monitor-linux.c
   • pcap-dag.c
   • pcap-dbus.c
   • pcap-haiku.c
   • pcap-hurd.c
   • pcap-int.h
   • pcap-linux.c
   • pcap-netfilter-linux.c
   • pcap-netmap.c
   • pcap-npf.c
   • pcap-rdmasniff.c
   • pcap-snf.c
   • pcap-usb-linux.c
   • pcap.c
   • pcap_offline_filter.3pcap
   • savefile.c
   • testprogs/TESTrun

4. Change #280847

   Category	libpcap
   Changed by	Denis Ovsienko <denisohnoyoudont@ovsienko.info>
   Changed at	Sat 05 Sep 2026 11:03:46
   Repository	https://git.tcpdump.org/libpcap
   Project	libpcap
   Branch	master
   Revision	4ccb54bf4946d31a248ec93bdbeaabd97fb9d8f7

   Comments

   CVE-2026-31911: Fail opcodes safely in the BPF interpreter.
   This vulnerability has been discovered by FuzzAnything Organization.
   
   The current revision of pcapint_filter_with_aux_data() calls abort() if
   the current instruction opcode is invalid, and assumes this never to be
   the case.  This holds for programs that have been generated by libpcap.
   
   However, this does not necessarily hold for programs that come from an
   external source via pcap_offline_filter() or [deprecated] bpf_filter().
   Furthermore, this does not necessarily hold for programs that have been
   validated by libpcap because the current revision of the validator has
   gaps in the checks and accepts a number of invalid opcodes (another
   commit addresses that).
   
   Thus in pcapint_filter_with_aux_data(), when the instruction opcode is
   invalid, just reject the packet.

   Changed files

   • CHANGES
   • bpf_filter.c
   • testprogs/TESTrun

5. Change #280849

   Category	libpcap
   Changed by	Denis Ovsienko <denisohnoyoudont@ovsienko.info>
   Changed at	Sat 05 Sep 2026 11:03:46
   Repository	https://git.tcpdump.org/libpcap
   Project	libpcap
   Branch	master
   Revision	0b2b1ad4a1796513613ff68e9dc09049cc8e0af4

   Comments

   CVE-2026-6244: Avoid division by zero via pcap_offline_filter().
   The current revision of pcapint_filter_with_aux_data() for "div x" and
   "mod x" correctly rejects the packet if X is zero, but for "div #k" and
   "mod #k" it assumes that k is never zero.  This holds for programs that
   have been generated or validated by libpcap.
   
   However, this does not necessarily hold for programs that come from an
   external source via pcap_offline_filter() or [deprecated] bpf_filter()
   and have not been explicitly validated.  If the interpreter executes
   such a program, it can attempt a division by zero, which will typically
   terminate the process via SIGFPE.
   
   To fix this problem, in pcapint_filter_with_aux_data() treat "div #k"
   and "mod #k" the same way as "div x" and "mod x".

   Changed files

   • CHANGES
   • bpf_filter.c
   • testprogs/TESTrun

6. Change #280850

   Category	libpcap
   Changed by	Denis Ovsienko <denisohnoyoudont@ovsienko.info>
   Changed at	Sat 05 Sep 2026 11:03:46
   Repository	https://git.tcpdump.org/libpcap
   Project	libpcap
   Branch	master
   Revision	63c005c25aeabf1404968add49fc885da3e127e0

   Comments

   CVE-2026-6554: Limit "ja L" looping in pcap_offline_filter().
   This vulnerability has been discovered by Kaixuan LI.
   
   The current revision of pcapint_filter_with_aux_data() assumes that any
   "ja L" instruction in a filter program does not jump to itself or to a
   prior instruction that is guaranteed to reach the same "ja L" again.
   This holds for programs that have been generated by libpcap.
   
   However, this does not necessarily hold for programs that come from an
   external source via pcap_offline_filter() or [deprecated] bpf_filter().
   If the interpreter executes such a program, upon reaching such an
   instruction it will begin looping infinitely.
   
   To mitigate this problem, in pcapint_filter_with_aux_data() enforce a
   hard-coded limit on the number of backward jumps per packet.  Ibid., and
   in pcapint_validate_filter() as well, reject the only immediately
   detectable case of an infinite loop.

   Changed files

   • CHANGES
   • bpf_filter.c
   • testprogs/TESTrun
   • tests/filter/ipv6_ext_headers.pcap