Isn’t gh-109638 a security problem? Doesn’t it deserve a CVE?

When looking the pull request gh-154867 (fix for gh-98820, CVE-2026-18503), I saw just next PR gh-154868 (fix for gh-109638), which however doesn’t have CVE. Shouldn’t it? It is exactly same DoS problem as the other one, isn’t it?

Matěj

Speaking as a reader of CVEs: CPU use DOS CVEs are just noise.

You can maybe make a case for memory consumption DOS CVEs being more than that, because of Linux, memory overcommit and the OOM killer. But CPU use DOS issues? If all you’re doing is run a single core at 100%, that is not a security issue.

Others may disagree, and others do disagree, otherwise we wouldn’t be seeing as many time-wasting CVEs about something using a quadratic algorithm (admittedly gh-154868 looks exponential, but people do issue CVEs for quadratic performance), or using stack linear to the input size.

DOS CVEs sometimes feel like a denial of service attack on people who read CVEs.

7 Likes

FTR, I didn’t notice this one come through the PSRT (Seth or Stan can confirm), which is why it isn’t labelled yet.

The general lines we’re drawing on DoS reports these days is amplification and exploitability - that is, the issue is cheaper to exploit than to suffer (which this one meets), and it’s something more likely to be used against an innocent victim rather than against yourself (which isn’t so clear here - CPU use DoS involving file parsing often isn’t).

Also, the decision to backport to security releases is independent of whether a CVE ID is assigned or not. It would probably be irresponsible for a RM to refuse the backport of something assigned a CVE, but it’s not a requirement that everything backported be a vulnerability.

The preferred process to get an existing public issue assigned a CVE ID would be to report it through the usual channels, reference the existing fix, and explain the impact of being/not being assigned an ID. We’re trying to do the best for our users, not merely do paperwork, so if there’s no impact then there likely won’t be a CVE ID assigned.

3 Likes

All these arguments would be completely valid if not for gh-98820 (CVE-2026-18503), which seems to me functionally identical, and yet one has CVE and this one not.

They share the same CVE. They were discussed together.

2 Likes