From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 768EE3887032; Tue, 7 Apr 2020 20:49:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 768EE3887032 From: "carlos at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/25620] Signed comparison vulnerability in the ARMv7 memcpy() (CVE-2020-6096) Date: Tue, 07 Apr 2020 20:49:03 +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: see_also Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 20:49:04 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D25620 Carlos O'Donell changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.redhat.com | |/show_bug.cgi?id=3D1820331 --- Comment #13 from Carlos O'Donell --- (In reply to Wilco from comment #10) > (In reply to Carlos O'Donell from comment #9) > > (In reply to Richard Earnshaw from comment #8) > > > memcpy is only defined if the regions do not overlap. If the size o= f 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 an= yway. > >=20 > > 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. I= f we > > change the implementation to operate on unsigned values we will eventua= lly > > reach an unmapped page (likely) and crash. Crashing is the best outcome= in > > this case since it prevents the attack from continuing. >=20 > Yes it's better to crash, but I fail to see how it would be a security > issue. Assuming we agree values over 2GB are not used in legal programs, > then it could only happen if the size gets corrupted by a buffer overflow. > If that's the case, an attacker could set it to whatever value they wanted > anyway rather than relying on this bug. We assign a security+ in all issues where the reporter filed a CVE (glibc security policy). The security+ indicates the issue is considered "security relevant" and needs further evaluation (we have 17 such glibc bugs open for review today). The fact that we have a CVE assigned means Red Hat's security had to work through their own analysis here: https://access.redhat.com/security/cve/CVE-2020-6096#cve-cvss-v3 In the case of low or moderate impact we really need to have other factors = to decide to prioritize. I think we all agree this should crash, and if we can make it crash then th= at's a QoI improvement. What is the priority of this fix over other stuff you're working on? That's hard to say, but I would not prioritize this against other bugs and feature= s, and not against the set of "high" or "critical" CVEs since our security tea= ms have evaluated it lower. --=20 You are receiving this mail because: You are on the CC list for the bug.=