Bug 27960 - Memset-vec-unaligned-erms.S has a potential overflow bug.
Summary: Memset-vec-unaligned-erms.S has a potential overflow bug.
Status: RESOLVED NOTABUG
Alias: None
Product: glibc
Classification: Unclassified
Component: string (show other bugs)
Version: 2.34
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-07 17:17 UTC by Noah Goldstein
Modified: 2021-06-09 22:08 UTC (History)
1 user (show)

See Also:
Host:
Target: x86_64
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Noah Goldstein 2021-06-07 17:17:16 UTC
In Commit:

author	Noah Goldstein <goldstein.w.n@gmail.com>	
Thu, 20 May 2021 17:13:51 +0000 (13:13 -0400)
commit	6abf27980a947f9b6e514d6b33b83059d39566ae

The loop bound calculation was changed to essentially the following pseudo code:

void * end = dst + length;
while(dst < end) {
   // Copy Bytes
}

This can potentially be an issue as if length + dst overflows end will be less than dst and the loop will exit on the first iteration.

So for example under certain conditions memset(ptr, c, SIZE_MAX) would not throw a Segmentation Fault

An example can be found here: https://godbolt.org/z/K1hE5cKvf

Some things worth noting.

1) This bug is also present in nearly all wcsmbs string/memory function implementations on x86_64 because they almost always execute `salq $2, %rdx` to adjust length which would cause overflow if the input is above 2 ^ ((sizeof(size_t) - 2).

2) This bug only affects CPUs without ERMS as any value that will cause overflow is also surely greater than __x86_rep_stosb_threshold.
Comment 1 Noah Goldstein 2021-06-09 22:08:11 UTC
This is not a bug. Passing a length that would cause overflow is undefined behavior.

https://marc.info/?l=glibc-alpha&m=162308797213313&w=2