On Sun, 1 Feb 2026 at 15:55, Guy Harris <[email protected]> wrote: > > On Feb 1, 2026, at 1:11 AM, Amit <[email protected]> wrote: > > > The description of the CVE is: A heap-based buffer overflow was found > > in the __vsyslog_internal function of the glibc library. This function > > is called by the syslog and vsyslog functions. This issue occurs when > > the openlog function was not called, or called with the ident argument > > set to NULL, > > """"and the program name (the basename of argv[0]) is bigger than 1024 > > bytes,"""" > > resulting in an application crash or local privilege escalation. This > > issue affects glibc 2.36 and newer. > > > > So, the function didn't check that the length of the input exceeds > > 1024 bytes > > That is completely false. > > The problem isn't that *an argument to the program* exceeded a limit. > > The problem is that *the string pointed to by the global variable __progname* > exceeded a limit.
Please look at the patch and the code and the comments. I consider the name of the function as an input because the name of the function is decided by the user, and hence, the name can be treated as an user input. So, file name is an user input which was put in __progname* variable and then it was copied into a buffer of fixed length of 1024 bytes without checking the length of the file name. They have a fixed sized buffer (bufs[1024]). The fix was to allocate a new buffer whose size was according to the input size. This means that there was no limit on the input size. If they have a buffer of 1024 bytes, then they should have checked whether the program name is less than 1024 bytes or not but they didn't. I gave an example of 1 GB. But this doesn't mean that you have to take it literally. The idea was to emphasize that the length of the input can be anything which may fail allocation. I can't explain further if you are still not convinced about putting a limit. > > """"So, we need a totally new security oriented standard."""" > > That wouldn't have helped here. If the Open group is not open for a new security oriented POSIX standard, then there is no point in me continuing this discussion. So, I am stopping this discussion here. Amit
