Builder libpcap-solaris11-sparc Build #182

Results:

Build successful

SourceStamp:

BuildSlave:

Reason:

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

Steps and Logfiles:

1. git update ( 10 secs )
   1. stdio
2. shell './build_matrix.sh' ( 4 hrs, 9 mins, 2 secs )
   1. stdio
   2. config.log
3. trigger triggered trigger-tcpdump-solaris11-sparc ( 1 hrs, 20 mins, 39 secs )
   1. - no logs -
   2. tcpdump-solaris11-sparc #195

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