Builder libpcap-solaris11-sparc Build #183

Results:

Build successful

SourceStamp:

BuildSlave:

Reason:

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

Steps and Logfiles:

1. git update ( 1 secs )
   1. stdio
2. shell './build_matrix.sh' ( 4 hrs, 57 mins, 15 secs )
   1. stdio
   2. config.log
3. trigger triggered trigger-tcpdump-solaris11-sparc ( 2 hrs, 4 mins, 19 secs )
   1. - no logs -
   2. tcpdump-solaris11-sparc #196

Build Properties:

Forced Build Properties:

Responsible Users:

1. Denis Ovsienko

   denisohnoyoudont@ovsienko.info

Timing:

All Changes:

:

1. 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

2. 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

3. 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

4. Change #280851

   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	c23f659c03ca05d009d0c301486c4ec8fe02805a

   Comments

   Validate BPF opcodes stricter.
   The current revision of pcapint_validate_filter() fails to detect some
   invalid opcodes because, unlike the interpreter (which uses an
   exhaustive list of valid opcodes), it uses bitmask macros to break the
   16-bit opcode into components, then misses specific combinations thereof
   and ignores the most significant byte entirely.
   
   To fix that, factor program-independent instruction validation out to a
   new function, pcapint_valid_insn(), and there use the same exact opcode
   list as in the interpreter.  This way the additional program-dependent
   instruction validation remaining in pcapint_validate_filter() can use
   the bitmasks as before.

   Changed files

   • CHANGES
   • bpf_filter.c
   • pcap-int.h
   • testprogs/CMakeLists.txt
   • testprogs/TESTrun
   • testprogs/enumeratetest.c

5. Change #280852

   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	a17254ee8ed9c229027fe0077eaf6ab9ad91c4a1

   Comments

   For "lsh" and "rsh" guard "#k" as well.
   "lsh x" and "rsh x" in BPF space produce an undefined behaviour in C
   space if X > 31 and commit db833b9 prevents exactly that by adding
   guards to the BPF interpreter.  "lsh #k" and "rsh #k" are a case of the
   same problem, except the value is immediate.  Although in programs that
   have been generated by libpcap these instructions never have k > 31, in
   programs that come from an external source via pcap_offline_filter() or
   [deprecated] bpf_filter() 'k' can have any value.  The validator does
   not catch that even if in use, but UBSan eventually does in the
   interpreter:
   
   bpf_filter.c:455:6: runtime error: shift exponent 32 is too large for
     32-bit type 'unsigned int'
   bpf_filter.c:459:6: runtime error: shift exponent 32 is too large for
     32-bit type 'unsigned int'
   
   Add the missing guards to the validator and the interpreter to fix the
   remaining part of the problem.

   Changed files

   • CHANGES
   • bpf_filter.c
   • optimize.c
   • testprogs/TESTrun

6. Change #280853

   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	26a1c75702b105ac8788014f35f1b5c57fa6043b

   Comments

   CVE-2026-18313: Fix a memory leak in rpcapd.
   This vulnerability was originally reported publicly, hence no credit is
   given.
   
   daemon_unpackapplyfilter() can allocate a temporary buffer for up to
   RPCAP_BPF_MAXINSNS (8192) BPF instructions (65536 bytes) per each
   received RPCAP_MSG_UPDATEFILTER_REQ or RPCAP_MSG_STARTCAP_REQ message.
   It never frees the memory, so repeated messages from a client will
   eventually leak enough memory on the server to cause problems.  This
   holds for all connections that pass the validation and some connections
   that do not.
   
   48 bytes in 1 blocks are definitely lost in loss record 2 of 2
      at 0x4844818: malloc (vg_replace_malloc.c:446)
      by 0x111AAB: daemon_unpackapplyfilter (daemon.c:2372)
      by 0x113279: daemon_msg_startcap_req.constprop.0 (daemon.c:2139)
      by 0x114808: daemon_serviceloop (daemon.c:901)
      by 0x115BC7: accept_connection (rpcapd.c:1321)
      by 0x115BC7: accept_connections (rpcapd.c:1118)
      by 0x115BC7: main_startup (rpcapd.c:709)
      by 0x1112BD: main (rpcapd.c:567)
   
   To fix this, after a successful malloc() return exactly once, after the
   free() call.

   Changed files

   • CHANGES
   • rpcapd/daemon.c

7. Change #280854

   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	2d67e814e8d3791a8b508c359f94688c5669cce9

   Comments

   CVE-2026-18238: Fix RPCAP_MSG_PACKET validation.
   This vulnerability was originally reported publicly, hence no credit is
   given.
   
   When pcap_read_nocb_remote() validates a received message, it does not
   verify that there is a complete RPCAP_MSG_PACKET header in the rpcap
   general payload, also it uses an incorrect value to validate the length
   declared in the RPCAP_MSG_PACKET header.  The latter can lead the
   protocol client to over-read the message buffer by 20 bytes, which in at
   least one scenario can cause a SIGSEGV.
   
   Fix this problem, as well as a potential integer overflow in the UDP
   code path on 32-bit architectures.  To make message encoding and
   validation easier to follow, re-jig a few variables and update comments.

   Changed files

   • CHANGES
   • pcap-rpcap.c