memcpy: use bhs/bls instead of bge/blt (CVE-2020-6096) [BZ #25620]

  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(-)

       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
  

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.
  

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.
>
  

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.
  

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.
>
  

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.
>>
  

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.
>>>
  

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.
>>>>
  

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.
>>>>>
  

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.
>>>>>>
  

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.
>>>>>>>
  

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.
>>>>>>>>
  

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