[PATCH] memcpy: use bhs/bls instead of bge/blt (CVE-2020-6096) [BZ #25620]
Robin Miyagi
r.miyagi@shaw.ca
Thu Apr 9 18:51:49 GMT 2020
unsubsribe
On 9/4/20 11:51 am, Robin Miyagi via Libc-alpha wrote:
> unsubsribe
>
> On 9/4/20 11:50 am, Robin Miyagi via Libc-alpha wrote:
>> unsubscribe
>>
>> On 9/4/20 11:50 am, Robin Miyagi via Libc-alpha wrote:
>>> unsubscribe
>>>
>>> On 9/4/20 11:50 am, Robin Miyagi via Libc-alpha wrote:
>>>> unsubscribe
>>>>
>>>> On 9/4/20 11:28 am, Robin Miyagi via Libc-alpha wrote:
>>>>> unsubsribe
>>>>>
>>>>> On 9/4/20 11:27 am, Carlos O'Donell via Libc-alpha wrote:
>>>>>> On 4/9/20 12:25 PM, Joseph Myers wrote:
>>>>>>> On Thu, 9 Apr 2020, zhuyan (M) wrote:
>>>>>>>
>>>>>>>> An exploitable signed comparison vulnerability exists in the ARMv7
>>>>>>>> memcpy() implementation of GNU glibc. Calling memcpy() (on ARMv7
>>>>>>>> targets that utilize the GNU glibc implementation) with a negative
>>>>>>>> value for the 'num' parameter results in a signed comparison
>>>>>>>> vulnerability.
>>>>>>>>
>>>>>>>> If an attacker underflows the 'num' parameter to memcpy(), this
>>>>>>>> vulnerability could lead to undefined behavior such as writing to
>>>>>>>> out-of-bounds memory and potentially remote code execution.
>>>>>>>> Furthermore, this memcpy() implementation allows for program
>>>>>>>> execution to continue in scenarios where a segmentation fault or
>>>>>>>> crash should have occurred. The dangers occur in that subsequent
>>>>>>>> execution and iterations of this code will be executed with this
>>>>>>>> corrupted data.
>>>>>>> I don't object to changing to use unsigned comparisons, since
>>>>>>> unsigned
>>>>>>> comparisons are what's logically appropriate here, but the
>>>>>>> commit message
>>>>>>> needs to discuss how it's very questionable whether this
>>>>>>> actually counts
>>>>>>> as a vulnerability, given that interfaces such as malloc cannot
>>>>>>> construct
>>>>>>> objects larger than PTRDIFF_MAX bytes and it's not clear what
>>>>>>> exactly is
>>>>>>> permitted to be done with a larger memory region allocated with
>>>>>>> mmap, so
>>>>>>> it's not clear if there are any cases where these functions can
>>>>>>> validly be
>>>>>>> called with a size argument exceeding PTRDIFF_MAX.
>>>>>>>
>>>>>>> Any case where a size argument is passed that is larger than the
>>>>>>> allocated
>>>>>>> memory region cannot be a security vulnerability in glibc, only
>>>>>>> in the
>>>>>>> application passing the bogus size argument (though of course we
>>>>>>> sometimes
>>>>>>> do choose to improve hardening against buggy applications).
>>>>>>>
>>>>>>> Furthermore, there was a comment in the bug saying a new test
>>>>>>> should be
>>>>>>> added to the testsuite. So either the patch should add a test
>>>>>>> (that fails
>>>>>>> before and passes after the memcpy change is applied) or the commit
>>>>>>> message should justify why this is hard to test in the testsuite.
>>>>>> This change should *absolutely* have a test case so we can see if
>>>>>> there
>>>>>> are other similar problems with memcpy on other architectures. A
>>>>>> synthetic
>>>>>> test case should be possible to construct.
>>>>>>
More information about the Libc-alpha
mailing list