On Jan 31, 2026, at 8:55 PM, Amit <[email protected]> wrote:
> On Sun, 1 Feb 2026 at 10:09, Guy Harris <[email protected]> wrote: > >> 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 OK, the AI summary found some examples of recent glibc CVEs. The first one is CVE-2023-6246: https://security-tracker.debian.org/tracker/CVE-2023-6246 which is fixed by https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=6bd0e4efcc78f3c0115e5ea9739a1642807450da;hp=8aeec0eb5a18f9614d18156f9d6092b3525b818c This is *NOT* a case where the correct fix is to impose an arbitrary limit on the length of input strings. (Note: "N% of RAM' is, for all values of N, including values of N >= 100, every bit as arbitrary as is a limit of "N", for some value of N). It is, instead, an internal case of failing to update a value, and has nothing to do with failing to check the validity of an argument. To quote the git commit comment for the fix: __vsyslog_internal did not handle a case where printing a SYSLOG_HEADER containing a long program name failed to update the required buffer size, leading to the allocation and overflow of a too-small buffer on the heap. This commit fixes that. It also adds a new regression test that uses glibc.malloc.check. which does *NOT* treat a long program name as an error, it just handles it by fixing the code so that that it dynamically allocates a buffer of sufficient size in this case. The second one is CVE-2023-4911: https://security-tracker.debian.org/tracker/CVE-2023-4911 which is fixed by https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=1056e5b4c3f2d90ed2b4a55f96add28da2f4c8fa;hp=0d5f9ea97f1b39f2a855756078771673a68497e1 This is *NOT* a case where the correct fix is to impose an arbitrary limit on the length of input strings. It is, instead, an internal case of failing to break out of a loop in one case. To quote the git commit comment for the fix: The string parsing routine may end up writing beyond bounds of tunestr if the input tunable string is malformed, of the form name=name=val. This gets processed twice, first as name=name=val and next as name=val, resulting in tunestr being name=name=val:name=val, thus overflowing tunestr. Terminate the parsing loop at the first instance itself so that tunestr does not overflow. The third one is CVE-2015-7547: https://security-tracker.debian.org/tracker/CVE-2015-7547 which is fixed by https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=e9db92d3acfe1822d56d11abcea5bfc4c41cf6ca This is *NOT* a case where the correct fix is to impose an arbitrary limit on the length of input strings. It is, instead, an internal case where buffers were being mismanaged. To quote the git commit comment for the fix: * A stack-based buffer overflow was found in libresolv when invoked from libnss_dns, allowing specially crafted DNS responses to seize control of execution flow in the DNS client. The buffer overflow occurs in the functions send_dg (send datagram) and send_vc (send TCP) for the NSS module libnss_dns.so.2 when calling getaddrinfo with AF_UNSPEC family. The use of AF_UNSPEC triggers the low-level resolver code to send out two parallel queries for A and AAAA. A mismanagement of the buffers used for those queries could result in the response of a query writing beyond the alloca allocated buffer created by _nss_dns_gethostbyname4_r. Buffer management is simplified to remove the overflow. Thanks to the Google Security Team and Red Hat for reporting the security impact of this issue, and Robert Holiday of Ciena for reporting the related bug 18665. (CVE-2015-7547) The burden of proof here is yours, not ours. If you wish to support your argument that imposing arbitrary limits on input data to functions fixes security holes, please take the time to find a CVE where the correct fix is to impose such a limit. > 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 The same applies here. Simply showing a list of glibc vulnerabilities is insufficient to prove your point. *You* must do the work to find which, if *any*, of those vulnerabilities support your assertion. > 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. No, that's *not* the problem. Please read my analysis of that bug above; it's a case of a failure to properly update the size needed for the buffer. > """"All buffer overflow issues mean that no limits were put on the > size of the buffer."""" No, it does not. It means that either: 1) it is a fixed-length buffer, and a limit *is* placed on the buffer at compile time - and the code that fills it doesn't check to make sure that it doesn't overflow the buffer, i.e. no limit is placed on the amount of data put *into* the buffer; 2) it is a fixed-length buffer, and a limit *is* placed on the buffer at run time, when the buffer is allocated - and the code doesn't make sure the size is large enough to hold all the data that will be put into the buffer; 3) it is a variable-length buffer that is expanded as needed, and the code that expands it as needed doesn't properly detect when the buffer has to be expanded. > 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. Again, see my explanation of this bug above. It has *nothing* to do with limits not being placed on buffers. > CVE-2024-33599: nscd Stack-based Overflow That's https://security-tracker.debian.org/tracker/CVE-2024-33599 which is fixed by https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=87801a8fd06db1d654eea3e4f7626ff476a9bdaa That fix changes the code to use a buffer whose size is the required size rather than one whose size is fixed at a value that can't handle the maximum size. I.e., it doesn't place additional limitations on the sizes passed to it, it increases the size that an be handled to the maximum size that it will be passed. > CVE-2015-7547: getaddrinfo() Buffer Overflow Again, see my explanation of this bug above. It's just a bug in buffer handling. > CVE-2025-0395: assert() Overflow That's https://security-tracker.debian.org/tracker/CVE-2025-0395 the fix for which is https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=7971add7ee4171fdd8dfd17e7c04c4ed77a18845 This is *NOT* a case where the correct fix is to impose an arbitrary limit on the length of input strings. It is, instead, an internal case where the buffer was being *dynamically* allocated at run time and the code was not correctly calculating the size required. > There are many more of them but I am not listing them here. I will bet you USD 10000 that the *vast* majority of them are *not* the result of limits not being placed on buffer sizes, but are the result of either: 1) the code not checking whether it would overflow a fixed-length buffer whose size is defined at compile time; 2) the code not correctly calculating the size of a buffer whose size is calculated when it is allocated at run time; 3) the code not properly detecting when the buffer needs to be expanded. > 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. I'm quite aware of that. I do not need to search for glibc vulnerabilities to be convinced of that. However: > and these happen because of no limit put on the buffer > size, etc. No, they don't, as I've shown several times above.
