From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6E7073887016; Tue, 7 Apr 2020 18:50:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6E7073887016 From: "wdijkstr at arm 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 18:50:37 +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: wdijkstr at arm 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: 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 18:50:38 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D25620 --- Comment #12 from Wilco --- (In reply to Florian Weimer from comment #11) > (In reply to Wilco from comment #10) > > 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 overfl= ow. > > If that's the case, an attacker could set it to whatever value they wan= ted > > anyway rather than relying on this bug. >=20 > I think the relevant case is when the size is set to -1 (or something else > close to zero) statically due to a size computation that went wrong as the > result of a logic error, and not some arbitrary attacker-controlled value. Compilers warn if memcpy size is constant and over 2GB, so it's unlikely su= ch a glaring mistake would go unnoticed. It would need to be runtime underflow w= hich means you'd likely call malloc to allocate the buffer, and that would fail = on -1. > Maybe we can change __memcpy_chk to call __chk_fail if the most significa= nt > bit of the dynamic length argument is set, independently of the value of = the > destination length? Then at least applications built with -D_FORTIFY_SOUR= CE > would benefit from that kind of belt-and-suspenders hardening. Yes, and it would be even better to check for overlap, that includes this c= ase and would find quite a few real bugs. --=20 You are receiving this mail because: You are on the CC list for the bug.=