* Re: [PATCH] memcpy: use bhs/bls instead of bge/blt (CVE-2020-6096) [BZ #25620]
@ 2020-04-13 13:58 zhuyan (M)
0 siblings, 0 replies; 14+ messages in thread
From: zhuyan (M) @ 2020-04-13 13:58 UTC (permalink / raw)
To: Joseph Myers; +Cc: Carlos O'Donell, libc-alpha
On Fri, 10 Apr 2020, Joseph Myers 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.
I will update the patch and description.
Thank you!
--
Yan Zhu
zhuyan34@huawei.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] memcpy: use bhs/bls instead of bge/blt (CVE-2020-6096) [BZ #25620]
2020-04-09 18:52 ` Robin Miyagi
@ 2020-04-09 19:05 ` Carlos O'Donell
0 siblings, 0 replies; 14+ messages in thread
From: Carlos O'Donell @ 2020-04-09 19:05 UTC (permalink / raw)
To: Robin Miyagi, libc-alpha
On 4/9/20 2:52 PM, Robin Miyagi via Libc-alpha wrote:
> unsubsribe
I have manually handled your request.
The mailing list details including steps to unsubscribe are listed here:
https://sourceware.org/mailman/listinfo/libc-alpha
--
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] memcpy: use bhs/bls instead of bge/blt (CVE-2020-6096) [BZ #25620]
2020-04-09 18:52 ` Robin Miyagi
@ 2020-04-09 18:52 ` Robin Miyagi
2020-04-09 19:05 ` Carlos O'Donell
0 siblings, 1 reply; 14+ messages in thread
From: Robin Miyagi @ 2020-04-09 18:52 UTC (permalink / raw)
To: libc-alpha
unsubsribe
On 9/4/20 11:52 am, Robin Miyagi via Libc-alpha wrote:
> unsubsribe
>
> On 9/4/20 11:51 am, Robin Miyagi via Libc-alpha wrote:
>> 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.
>>>>>>>>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] memcpy: use bhs/bls instead of bge/blt (CVE-2020-6096) [BZ #25620]
2020-04-09 18:51 ` Robin Miyagi
@ 2020-04-09 18:52 ` Robin Miyagi
2020-04-09 18:52 ` Robin Miyagi
0 siblings, 1 reply; 14+ messages in thread
From: Robin Miyagi @ 2020-04-09 18:52 UTC (permalink / raw)
To: libc-alpha
unsubsribe
On 9/4/20 11:51 am, Robin Miyagi via Libc-alpha wrote:
> 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.
>>>>>>>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] memcpy: use bhs/bls instead of bge/blt (CVE-2020-6096) [BZ #25620]
2020-04-09 18:51 ` Robin Miyagi
@ 2020-04-09 18:51 ` Robin Miyagi
2020-04-09 18:52 ` Robin Miyagi
0 siblings, 1 reply; 14+ messages in thread
From: Robin Miyagi @ 2020-04-09 18:51 UTC (permalink / raw)
To: libc-alpha
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.
>>>>>>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] memcpy: use bhs/bls instead of bge/blt (CVE-2020-6096) [BZ #25620]
2020-04-09 18:50 ` Robin Miyagi
@ 2020-04-09 18:51 ` Robin Miyagi
2020-04-09 18:51 ` Robin Miyagi
0 siblings, 1 reply; 14+ messages in thread
From: Robin Miyagi @ 2020-04-09 18:51 UTC (permalink / raw)
To: libc-alpha
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.
>>>>>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] memcpy: use bhs/bls instead of bge/blt (CVE-2020-6096) [BZ #25620]
2020-04-09 18:50 ` Robin Miyagi
@ 2020-04-09 18:50 ` Robin Miyagi
2020-04-09 18:51 ` Robin Miyagi
0 siblings, 1 reply; 14+ messages in thread
From: Robin Miyagi @ 2020-04-09 18:50 UTC (permalink / raw)
To: libc-alpha
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.
>>>>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] memcpy: use bhs/bls instead of bge/blt (CVE-2020-6096) [BZ #25620]
2020-04-09 18:50 ` Robin Miyagi
@ 2020-04-09 18:50 ` Robin Miyagi
2020-04-09 18:50 ` Robin Miyagi
0 siblings, 1 reply; 14+ messages in thread
From: Robin Miyagi @ 2020-04-09 18:50 UTC (permalink / raw)
To: libc-alpha
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.
>>>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] memcpy: use bhs/bls instead of bge/blt (CVE-2020-6096) [BZ #25620]
2020-04-09 18:28 ` Robin Miyagi
@ 2020-04-09 18:50 ` Robin Miyagi
2020-04-09 18:50 ` Robin Miyagi
0 siblings, 1 reply; 14+ messages in thread
From: Robin Miyagi @ 2020-04-09 18:50 UTC (permalink / raw)
To: libc-alpha
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.
>>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] memcpy: use bhs/bls instead of bge/blt (CVE-2020-6096) [BZ #25620]
2020-04-09 18:27 ` Carlos O'Donell
@ 2020-04-09 18:28 ` Robin Miyagi
2020-04-09 18:50 ` Robin Miyagi
0 siblings, 1 reply; 14+ messages in thread
From: Robin Miyagi @ 2020-04-09 18:28 UTC (permalink / raw)
To: libc-alpha
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.
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] memcpy: use bhs/bls instead of bge/blt (CVE-2020-6096) [BZ #25620]
2020-04-09 16:25 ` Joseph Myers
2020-04-09 16:28 ` Robin Miyagi
@ 2020-04-09 18:27 ` Carlos O'Donell
2020-04-09 18:28 ` Robin Miyagi
1 sibling, 1 reply; 14+ messages in thread
From: Carlos O'Donell @ 2020-04-09 18:27 UTC (permalink / raw)
To: Joseph Myers, zhuyan (M); +Cc: libc-alpha
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.
--
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] memcpy: use bhs/bls instead of bge/blt (CVE-2020-6096) [BZ #25620]
2020-04-09 16:25 ` Joseph Myers
@ 2020-04-09 16:28 ` Robin Miyagi
2020-04-09 18:27 ` Carlos O'Donell
1 sibling, 0 replies; 14+ messages in thread
From: Robin Miyagi @ 2020-04-09 16:28 UTC (permalink / raw)
To: libc-alpha
unsubscribe
On 9/4/20 9:25 am, 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.
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] memcpy: use bhs/bls instead of bge/blt (CVE-2020-6096) [BZ #25620]
2020-04-09 14:05 zhuyan (M)
@ 2020-04-09 16:25 ` Joseph Myers
2020-04-09 16:28 ` Robin Miyagi
2020-04-09 18:27 ` Carlos O'Donell
0 siblings, 2 replies; 14+ messages in thread
From: Joseph Myers @ 2020-04-09 16:25 UTC (permalink / raw)
To: zhuyan (M); +Cc: libc-alpha
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.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] memcpy: use bhs/bls instead of bge/blt (CVE-2020-6096) [BZ #25620]
@ 2020-04-09 14:05 zhuyan (M)
2020-04-09 16:25 ` Joseph Myers
0 siblings, 1 reply; 14+ messages in thread
From: zhuyan (M) @ 2020-04-09 14:05 UTC (permalink / raw)
To: libc-alpha
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.
Reference URL: https://sourceware.org/bugzilla/attachment.cgi?id=12334&action=edit
Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
---
sysdeps/arm/armv7/multiarch/memcpy_impl.S | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/sysdeps/arm/armv7/multiarch/memcpy_impl.S b/sysdeps/arm/armv7/multiarch/memcpy_impl.S
index bf4ac7077f..7455bdc6c7 100644
--- a/sysdeps/arm/armv7/multiarch/memcpy_impl.S
+++ b/sysdeps/arm/armv7/multiarch/memcpy_impl.S
@@ -268,7 +268,7 @@ ENTRY(memcpy)
mov dst, dstin /* Preserve dstin, we need to return it. */
cmp count, #64
- bge .Lcpy_not_short
+ bhs .Lcpy_not_short
/* Deal with small copies quickly by dropping straight into the
exit block. */
@@ -351,10 +351,10 @@ ENTRY(memcpy)
1:
subs tmp2, count, #64 /* Use tmp2 for count. */
- blt .Ltail63aligned
+ bls .Ltail63aligned
cmp tmp2, #512
- bge .Lcpy_body_long
+ bhs .Lcpy_body_long
.Lcpy_body_medium: /* Count in tmp2. */
#ifdef USE_VFP
@@ -378,7 +378,7 @@ ENTRY(memcpy)
add src, src, #64
vstr d1, [dst, #56]
add dst, dst, #64
- bge 1b
+ bhs 1b
tst tmp2, #0x3f
beq .Ldone
@@ -412,7 +412,7 @@ ENTRY(memcpy)
ldrd A_l, A_h, [src, #64]!
strd A_l, A_h, [dst, #64]!
subs tmp2, tmp2, #64
- bge 1b
+ bhs 1b
tst tmp2, #0x3f
bne 1f
ldr tmp2,[sp], #FRAME_SIZE
@@ -482,7 +482,7 @@ ENTRY(memcpy)
add src, src, #32
subs tmp2, tmp2, #prefetch_lines * 64 * 2
- blt 2f
+ bls 2f
1:
cpy_line_vfp d3, 0
cpy_line_vfp d4, 64
@@ -494,7 +494,7 @@ ENTRY(memcpy)
add dst, dst, #2 * 64
add src, src, #2 * 64
subs tmp2, tmp2, #prefetch_lines * 64
- bge 1b
+ bhs 1b
2:
cpy_tail_vfp d3, 0
--
2.12.3
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-04-13 13:58 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-13 13:58 [PATCH] memcpy: use bhs/bls instead of bge/blt (CVE-2020-6096) [BZ #25620] zhuyan (M)
-- strict thread matches above, loose matches on Subject: below --
2020-04-09 14:05 zhuyan (M)
2020-04-09 16:25 ` Joseph Myers
2020-04-09 16:28 ` Robin Miyagi
2020-04-09 18:27 ` Carlos O'Donell
2020-04-09 18:28 ` Robin Miyagi
2020-04-09 18:50 ` Robin Miyagi
2020-04-09 18:50 ` Robin Miyagi
2020-04-09 18:50 ` Robin Miyagi
2020-04-09 18:51 ` Robin Miyagi
2020-04-09 18:51 ` Robin Miyagi
2020-04-09 18:52 ` Robin Miyagi
2020-04-09 18:52 ` Robin Miyagi
2020-04-09 19:05 ` Carlos O'Donell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).