Builder libpcap-solaris10-sparc Build #3307

Results:

Build successful

SourceStamp:

BuildSlave:

Reason:

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

Steps and Logfiles:

1. git update ( 2 secs )
   1. stdio
2. shell Set developer mode ( 0 secs )
   1. stdio
3. shell_1 './autogen.sh' ( 29 secs )
   1. stdio
4. shell_2 './configure' ( 1 mins, 14 secs )
   1. stdio
   2. config.log
5. shell_3 'gmake' ( 1 mins, 3 secs )
   1. stdio
6. shell_4 'gmake check' ( 22 mins, 23 secs )
   1. stdio
7. shell_5 'rm -rf ...' ( 0 secs )
   1. stdio
8. shell_6 'gmake install ...' ( 4 secs )
   1. stdio
9. trigger triggered trigger-tcpdump-solaris10-sparc ( 22 mins, 50 secs )
   1. - no logs -
   2. tcpdump-solaris10-sparc #6283

Build Properties:

Forced Build Properties:

Responsible Users:

1. Denis Ovsienko

   denisohnoyoudont@ovsienko.info

Timing:

All Changes:

:

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

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

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

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