[PATCH v2 0/8] Fixes for CVE-2026-5435, CVE-2026-6238

[Carlos O'Donell]

On 6/18/26 8:57 AM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> On 6/16/26 12:31 PM, Florian Weimer wrote:
>>> CVE-2026-6238 has multiple vulnerable commits across different glibc
>>> versions.  Technically, this means the CVE ID should be SPLIT.  I'm not
>>> sure if this is worthwhile because I doubt people care about glibc
>>> before version 2.7.
>>
>> May you please expand on this comment?
> 
> It's in one of the commit messages:
> 
> “
> The vulnerable LOC record handling was first introduced before
> glibc 2.0, in commit ee188d555b8c32ad9704a7440cab400af967292f.
> 
> CERT, TSIG, TKEY handling came with commit
> b43b13ac2544b11f35be301d1589b51a8473e32b, released with glibc 2.2.
> 
> A6 record handling was introduced in commit
> 91633816430e7ec5a19fe3ff510a7c4822a9557e ("* resolv/ns_print.c
> (ns_sprintrrf): Handle ns_t_a6 and ns_t_opt."), which went into glibc
> 2.7.
> ”
> 
> I think this falls under ADT3 here:
> 
> | ADT3
> |
> |  Does X affect a version that Y does not? (e.g. X affects 1.2 and 3.4,
> |  but Y only affects 3.4. Consider "1.x" and "1.2" as different.)
> |
> |  Yes: SPLIT them.
> 
> <https://cveproject.github.io/docs/cna/application-guidance.html>

Just noting that this is archived "guidance" for the CNA program,
and as such we get to exercise our own discretion here within the
context of the CNA rules.

In this case I don't think there is value in splitting this into 3
CVEs (which are independently fixable), I'd like to proceed as-if
there was just 1 CVE with the handling of the user's buffer, and
follow the logical consequence of fixing these issues all together.

If we receive guidance from downstream that they would like to
see more diligent splitting, then and only then would I have a
conversation with the glibc security team about how to split.

--
Cheers,
Carlos.