NetBSD Problem Report #43825

From www@NetBSD.org  Wed Sep  1 08:12:26 2010
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id E663E63BC45
	for <gnats-bugs@gnats.NetBSD.org>; Wed,  1 Sep 2010 08:12:25 +0000 (UTC)
Message-Id: <20100901081225.9F8B963BBC7@www.NetBSD.org>
Date: Wed,  1 Sep 2010 08:12:25 +0000 (UTC)
From: guy@alum.mit.edu
Reply-To: guy@alum.mit.edu
To: gnats-bugs@NetBSD.org
Subject: p->cc can go negative in libpcap
X-Send-Pr-Version: www-1.0

>Number:         43825
>Category:       lib
>Synopsis:       p->cc can go negative in libpcap
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Sep 01 08:15:01 +0000 2010
>Closed-Date:    Mon Nov 10 20:49:08 +0000 2025
>Last-Modified:  Mon Nov 10 20:49:08 +0000 2025
>Originator:     Guy Harris
>Release:        Top of tree
>Organization:
>Environment:
>Description:
In pcap_read_bpf(), ep is set based on the return value of read(), but read() from a BPF device doesn't necessarily return a value that's a multiple of the alignment value for BPF_WORDALIGN(). However, whenever we increment bp, we round up the increment value by a value rounded up by BPF_WORDALIGN(), so we could increment bp past ep after processing the last packet in the buffer.

(The patch also fixes the case where it returns due to a pcap_breakloop() call, so it doesn't re-process packets.)
>How-To-Repeat:
Run a program that opens a capture device with a timeout of 0, in a loop, calls pcap_dispatch() with a cnt argument of 1, and reports when it returns a value of 0. The timeout of 0 means that the read() that libpcap does shouldn't return until there's packet data, so a timeout won't cause pcap_dispatch() to return 0. Do a large amount of network data transfer, to fill up the BPF bucket; notice that, on occasion, the program will report that pcap_dispatch() returns 0.
>Fix:

--- pcap-bpf.c.dist	2010-09-01 01:09:26.000000000 -0700
+++ pcap-bpf.c	2010-09-01 01:10:50.000000000 -0700
@@ -248,14 +248,28 @@
 		 * return the number of packets we've processed so far.
 		 */
 		if (p->break_loop) {
+			p->bp = bp;
+			p->cc = ep - bp;
+			/*
+			 * ep is set based on the return value of read(),
+			 * but read() from a BPF device doesn't necessarily
+			 * return a value that's a multiple of the alignment
+			 * value for BPF_WORDALIGN().  However, whenever we
+			 * increment bp, we round up the increment value by
+			 * a value rounded up by BPF_WORDALIGN(), so we
+			 * could increment bp past ep after processing the
+			 * last packet in the buffer.
+			 *
+			 * We treat ep < bp as an indication that this
+			 * happened, and just set p->cc to 0.
+			 */
+			if (p->cc < 0)
+				p->cc = 0;
 			if (n == 0) {
 				p->break_loop = 0;
 				return (-2);
-			} else {
-				p->bp = bp;
-				p->cc = ep - bp;
+			} else
 				return (n);
-			}
 		}

 		caplen = bhp->bh_caplen;
@@ -306,6 +320,11 @@
 			if (++n >= cnt && cnt > 0) {
 				p->bp = bp;
 				p->cc = ep - bp;
+				/*
+				 * See comment above about p->cc < 0.
+				 */
+				if (p->cc < 0)
+					p->cc = 0;
 				return (n);
 			}
 		} else {

>Release-Note:

>Audit-Trail:
From: Guy Harris <gharris@sonic.net>
To: "gnats-bugs@netbsd.org" <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: lib/43825
Date: Mon, 10 Nov 2025 11:20:23 -0800

 NetBSD's libpcap is now tracking tcpdump.org's libpcap, and has picked =
 up its fix for this issue. This issue can be closed.=

State-Changed-From-To: open->closed
State-Changed-By: wiz@NetBSD.org
State-Changed-When: Mon, 10 Nov 2025 20:49:08 +0000
State-Changed-Why:
Fixed by merging from upstream, thanks for the update!


>Unformatted:

Home	PR Database Search