bugtraq
[Top] [All Lists]

Re: Clarifying integer overflows vs. signedness errors

To: "Steven M. Christey" <coley@mitre.org>
Subject: Re: Clarifying integer overflows vs. signedness errors
From: Pavel Kankovsky <peak@argo.troja.mff.cuni.cz>
Date: Sat, 25 Nov 2006 19:02:16 +0100 (CET)
Cc: bugtraq@securityfocus.com
Delivered-to: sp-com-lists@consult.net
Delivered-to: bugtraq-list@securepoint.com
Delivered-to: mailing list bugtraq@securityfocus.com
Delivered-to: moderator for bugtraq@securityfocus.com
In-reply-to: <200611212153.kALLrYG9009899@faron.mitre.org>
List-help: <mailto:bugtraq-help@securityfocus.com>
List-id: <bugtraq.list-id.securityfocus.com>
List-post: <mailto:bugtraq@securityfocus.com>
List-subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
List-unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
Mailing-list: contact bugtraq-help@securityfocus.com; run by ezmlm
Sender: peak@paddy.troja.mff.cuni.cz
On Tue, 21 Nov 2006, Steven M. Christey wrote:

> I think of an integer overflow as being: "some computation (addition,
> multiplication) would produce an integer value that is too large to be
> stored in the actual memory location, so the integer wraps to some
> other value."  (let's leave integer "underflow" out of this for the
> moment).

The passing of a signed variable called "len" to an unsigned parameter of
copyout() is a (trivial) computation producing a value that does not fit
into the target type. Negative values "wrap around" and monotonicity
(length <= buffer size) is not preserved.

IMHO these two classes of problems grow from one common root.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."



<Prev in Thread] Current Thread [Next in Thread>