From owner-freebsd-hackers Mon Nov 10 20:02:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA22995 for hackers-outgoing; Mon, 10 Nov 1997 20:02:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA22988 for ; Mon, 10 Nov 1997 20:02:47 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id UAA01268 for ; Mon, 10 Nov 1997 20:02:40 -0800 (PST) Date: Mon, 10 Nov 1997 20:02:39 -0800 (PST) From: "Jamil J. Weatherbee" To: hackers@freebsd.org Subject: Possible Kernel Bug? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I may be dead wrong about this but it is worth a try: void *data; void *data_end; lets say you are passed a struct buf with a data buffer bp->b_data and bp->b_bcount = 1000; if you say data = bp->b_data /* this is fine */ what about data_end = bp->b_data + bp->b_bcount /* this pointer could point to something nonexistent??? */ so dereferencing it is definetly a no no (and that is not being done) but I see places where data compared to data_end , now since caddr_t is defined as , such as while (data < data_end) typedef char *caddr_t; which i assume is represented as a 32 bit unsigned integer are you guaranteed that the byte 0xffffffff is never allocated? this should be true in addition to 0x00000000 never being allocated.