On Sun, 1 Feb 2026 at 14:07, Guy Harris <[email protected]> wrote: > > 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: > > > > 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 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 and if it checked then it would have resulted in not processing the input and then hacking wouldn't have happened. You can fix an issue in multiple ways, just like there are many different sorting algorithms. One technical question can result in many different codes. So, the point is that we should not focus on how it was fixed. And it was fixed the way it was fixed because you can't put a limit in the current code, because if you do then many existing code/software can break. """"So, we need a totally new security oriented standard."""" The comment from the changed code is: /* We already know that bufs is too small to use for this log message. + The next vsnprintf into bufs is used only to calculate the total + required buffer length. We will discard bufs contents and allocate + an appropriately sized buffer later instead. */ So, they decided to allocate a larger buffer for larger input. So, they modified their buffer size based on the input size. Now, for the sake of the conversation, what would happen if the program name was 1G in length. In this case, the allocation would have failed. So, putting a limit is better than allocating a buffer according to the input size. Amit
