From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 909FD385DC3E; Tue,  7 Apr 2020 13:15:32 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 909FD385DC3E
From: "carlos at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/25620] Signed comparison vulnerability in the ARMv7
 memcpy() (CVE-2020-6096)
Date: Tue, 07 Apr 2020 13:15:32 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.3.1
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: carlos at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security+
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-25620-131-JvmVTIhZW1@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-25620-131@http.sourceware.org/bugzilla/>
References: <bug-25620-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: glibc-bugs@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Glibc-bugs mailing list <glibc-bugs.sourceware.org>
List-Unsubscribe: <http://sourceware.org/mailman/options/glibc-bugs>,
 <mailto:glibc-bugs-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/glibc-bugs/>
List-Help: <mailto:glibc-bugs-request@sourceware.org?subject=help>
List-Subscribe: <http://sourceware.org/mailman/listinfo/glibc-bugs>,
 <mailto:glibc-bugs-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Apr 2020 13:15:32 -0000

https://sourceware.org/bugzilla/show_bug.cgi?id=3D25620

--- Comment #9 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Richard Earnshaw from comment #8)
> memcpy is only defined if the regions do not overlap.   If the size of the
> copy is more than half the address space, this can never be true, so any
> copy that is mis-interpreted as a negative value must be undefined anyway.

In many cases the implementation chooses what behaviour happens in the
undefined case, and it is always better if we crash early rather than to
continue to operate having copied less data than expected by the API. If we
change the implementation to operate on unsigned values we will eventually
reach an unmapped page (likely) and crash. Crashing is the best outcome in =
this
case since it prevents the attack from continuing.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=