On Sun, 1 Feb 2026 at 10:09, Guy Harris <[email protected]> wrote: > > On Jan 31, 2026, at 7:48 PM, Amit via austin-group-l at The Open Group > <[email protected]> wrote: > > > I can't convince people here unless people agree that """"they don't > > want to satisfy a minority of people at the expense of the majority of > > people."""" > > And, prior to that, they would also need to agree that not imposing size > limits will be at the expense of the majority of people. > > You have not provided any evidence to demonstrate that imposing those size > limits would increase system security; you will need to do so before people > will even consider this to be a case where, to benefit the majority, you will > have to impose limits on a minority. > > > If people want to satisfy everyone, then obviously we can't put limits > > on the arguments and in that case things will remain as they are now > > and the world will remain insecure as it is now. > > Again, you have failed to demonstrate that, for example, imposing limits on > the size of an array to be processed by qsort(), or on the size of a string > to be copied by strlcpy(), will, in any way, shape, or form, make the world > any more secure. > > First demonstrate *that, with concrete evidence. Then we can proceed. The > goal here is not to find arbitrary forms of validation for function > arguments, so that we can check "added validation requirements for this > function argument" checkboxes; the goal is to find cases where certain > argument values can be shown to cause security or other bugs, and add *those* > requirements.
I searched google for "glibc security issues". Please go through this URL: https://www.google.com/search?q=glibc+security+issues&oq=glibc+security+issues&gs_lcrp=EgZjaHJvbWUyBggAEEUYOdIBCDU3ODRqMGo3qAIAsAIA&sourceid=chrome&ie=UTF-8 I also searched for "list of all vulnerabilities in glibc". Please go through this URL also: https://www.google.com/search?q=list+of+all+vulnerabilities+in+glibc&oq=list+of+all+vulnerabilities+in+glibc&gs_lcrp=EgZjaHJvbWUyBggAEEUYOdIBCTEwODkxajBqN6gCALACAA&sourceid=chrome&ie=UTF-8 ---------- Issues: ---------- https://openssf.org/blog/2024/02/05/cve-2023-6246-root-access-vulnerability-in-glibc: Heap based buffer overflow because no limits were put on the size of the buffer. """"All buffer overflow issues mean that no limits were put on the size of the buffer."""" https://blog.qualys.com/vulnerabilities-threat-research/2023/10/03/cve-2023-4911-looney-tunables-local-privilege-escalation-in-the-glibcs-ld-so: Buffer overflow vulnerability in GNU C Library’s dynamic loader’s processing of the GLIBC_TUNABLES environment variable. CVE-2023-6246: A heap-based buffer overflow in the __vsyslog_internal() function that could allow local privilege escalation to root access. CVE-2024-33599: nscd Stack-based Overflow CVE-2015-7547: getaddrinfo() Buffer Overflow CVE-2025-0395: assert() Overflow There are many more of them but I am not listing them here. Please have a look at this also: https://security.snyk.io/package/linux/debian%3A11/glibc If you search google for vulnerabilities in glibc, then you will find many vulnerabilities and many of them are buffer overflows, stack overflows, etc. and these happen because of no limit put on the buffer size, etc. Amit
