It seems libyaml is affected. The reproducer provided in the CVE report works and leads to a memory leak so the issue is reproducible.

I never saw an issue about that here.
But I went to the link and looked at the code:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <yaml.h>

void poc() {
    yaml_document_t document;
    memset(&document, 0, sizeof(yaml_document_t));
    yaml_char_t *anchor = "rsslab";
    yaml_char_t *tag = "tag:yaml.org,2002:str";
    int style = YAML_ANY_SEQUENCE_STYLE;
    yaml_document_add_sequence(&document, tag, style);
}

int main(int argc, char *argv[])
{
    printf("heap-buffer-overflow on libyaml/src/api.c:1274:10\n");
    poc();
    return 0;
}

So yeah, if you do strange things, then strange things happen.
What is the purpose of this code?

It can be fixed like that:

    yaml_document_t document;
    memset(&document, 0, sizeof(yaml_document_t));
    if (!yaml_document_initialize(&document, NULL, NULL, NULL, 0, 0))
        return;
    yaml_char_t *anchor = "rsslab";
    yaml_char_t *tag = "tag:yaml.org,2002:str";
    int style = YAML_ANY_SEQUENCE_STYLE;
    yaml_document_add_sequence(&document, tag, style);

    yaml_document_delete(&document);

You have to call yaml_document_initialize, and you have to call yaml_document_delete at the end.

I am not sure how that is something to exploit. If you find code out there that does this then the code is broken and won't work anyway. I will reject the CVE.
This is costing me time. If there is a way to exploit, then please create a private security report and describe it in detail, I really can't see the problem here. pinging @idhyt because this is from them, see #297 and https://github.com/idhyt/pocs/tree/main/libyaml

Thank you for the quick clarification! I don't have enough knowledge of the codebase here so if you say the reproducer is actually a broken piece of code, I trust you. The CVE has to be therefore rejected but you are the only one who can request that I guess.

I contacted Vuldb to reject it and also complained about a missing report before disclosure.

Vuldb replied that mitre.org is responsible for this one sigh so I filled out their contact form.
It seems to be easy to create a CVE, but it is made hard for maintainers to reject them.

@perlpunk

I have responded to all in #297 about this series issue，and have terminated all remaining reports, you can reject them, sorry for the trouble :)

Some more detailed thoughts.
In order to call something a CVE, I would at least need to see a program that does something useful and works.
So let's look at a minimal program:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <yaml.h>

int main(int argc, char *argv[])
{
    yaml_emitter_t emitter;
    yaml_document_t document;
    memset(&document, 0, sizeof(yaml_document_t));
    if (!yaml_document_initialize(&document, NULL, NULL, NULL, 0, 0)) return;

    fprintf(stderr, "yaml_emitter_initialize\n");
    if (!yaml_emitter_initialize(&emitter)) return;

    fprintf(stderr, "yaml_document_add_sequence\n");
    yaml_char_t *tag = "tag:yaml.org,2002:str";
    int style = YAML_ANY_SEQUENCE_STYLE;
    yaml_document_add_sequence(&document, tag, style);

    fprintf(stderr, "yaml_emitter_set_output_file\n");
    yaml_emitter_set_output_file(&emitter, stdout);
    fprintf(stderr, "yaml_emitter_open\n");
    yaml_emitter_open(&emitter);
    fprintf(stderr, "yaml_emitter_dump\n");
    if (!yaml_emitter_dump(&emitter, &document)) return;
//    yaml_document_delete(&document);
}

Running this I get:

yaml_emitter_initialize
yaml_document_add_sequence
yaml_emitter_set_output_file
yaml_emitter_open
yaml_emitter_dump
--- !!str []
...

Now I remove the yaml_document_initialize:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <yaml.h>

int main(int argc, char *argv[])
{
    yaml_emitter_t emitter;
    yaml_document_t document;
    memset(&document, 0, sizeof(yaml_document_t));
//    if (!yaml_document_initialize(&document, NULL, NULL, NULL, 0, 0)) return;

    fprintf(stderr, "yaml_emitter_initialize\n");
    if (!yaml_emitter_initialize(&emitter)) return;

    fprintf(stderr, "yaml_document_add_sequence\n");
    yaml_char_t *tag = "tag:yaml.org,2002:str";
    int style = YAML_ANY_SEQUENCE_STYLE;
    yaml_document_add_sequence(&document, tag, style);

    fprintf(stderr, "yaml_emitter_set_output_file\n");
    yaml_emitter_set_output_file(&emitter, stdout);
    fprintf(stderr, "yaml_emitter_open\n");
    yaml_emitter_open(&emitter);
    fprintf(stderr, "yaml_emitter_dump\n");
    if (!yaml_emitter_dump(&emitter, &document)) return;
//    yaml_document_delete(&document);
}

and I get:

yaml_emitter_initialize
yaml_document_add_sequence
yaml_emitter_set_output_file
yaml_emitter_open
yaml_emitter_dump
malloc(): corrupted top size
[1]    12219 IOT instruction (core dumped)  ./tests/run-emitter-test-suite

So this program is not working at all, so I doubt any app out there has code like this running that one could somehow exploit.
If the code can be improved to avoid the buffer overflow and return an error instead, like #299 (which seems to be a proof of concept), then sure, that should be considered. But the V in CVE stands for vulnerability.

Hmm, it seems somebody focused on libyaml and filled 3 more CVEs:

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-35325 with PoC: https://github.com/idhyt/pocs/blob/main/libyaml/CVE-2024-35325.c
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-35326 with PoC: https://github.com/idhyt/pocs/blob/main/libyaml/CVE-2024-35326.c
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-35328 with PoC: https://github.com/idhyt/pocs/blob/main/libyaml/CVE-2024-35328.c

Do you want to open new issues for them so we can tackle them individually?

There's something seriously wrong with the CVE process if maintainers are not contacted prior to disclosure.

@frasertweedale do you know who to contact for breaches of process?

I guess I got @idhyt wrong, so I have to reject all four :(

So CVE-2024-35326 , CVE-2024-35328 and this one here are very similar in that they all skip the call to initialize a struct.
This means that the memory will just contain garbage, and in a full program any operations on them will likely result in an error like malloc(): corrupted top size. So a program like this just doesn't work, and the contrived examples are doing nothing useful, so there shouldn't be anything out there that can be exploited.

There's something seriously wrong with the CVE process if maintainers are not contacted prior to disclosure.

@frasertweedale do you know who to contact for breaches of process?

CVE is just a numbering system. Blocks of IDs are assigned to CVE Numbering Authorities (CNAs) - typically large software vendors or security research orgs. Each CNA has their own procedures and expectations.

These CVEs were assigned by MITRE, a "CNA of last resort". Anyone can request a CVE and they will assign it. A reference to a public POC or evidence of the issue is sufficient to make the details public. Disclosing without first contacting the vendor/maintainer is poor form, but it happens a lot and there is no real means of recourse.

@perlpunk
@hasufell
@frasertweedale
@frenzymadness
@zhuofeng6
@mmz-zmm
@...

我不希望再占用公共资源，关于这几个问题我最后做一次解释：

1. 发现这些问题的过程，就像在#297中所说，我在使用rust进行开发时候，需要解析yaml文件，因此我引入了 serde_yaml 库，当我进行编译时候，发现了该库依赖了unsafe-libyaml，在rust中使用 unsafe 需要非常谨慎，因此我最终找到了这个项目，我对这个项目的API和部分实现代码进行了大致阅读，发现了其实现过程中存在多处缺陷，并且在rust中复现了这些问题，见 poc。

2. 关于披露流程问题，起初我在这个项目中提了issue(double-free on yaml_event_delete api #297)，两周过去了没有任何人进行回复，随后我在问题下边也说明了，我将公开所有问题。 同时，我在评估了风险以后（最新的一个版本已经过去4年），放弃了 serde_yaml 并使用了serde_toml 进行替代，并将已经编写4的poc公开，随后作者回复了我的issue，由于公开时间我无法控制，因此存在了关于#297问题下的争议，此时，我已经终止提交了所有未公开的问题，不会再有新的披露了。 在#297下 @Martchus 提醒了我，不应该向开源维护者施压，这个确实是我没有考虑的问题，我为此表示抱歉，我确实希望这些问题能够尽快的得到回应（我在开发过程中确实需要这个库）。

3. 关于漏洞与否的争议，我想说的是，漏洞能否被利用是一个非常主观的事情，依赖于个人的技术水平和使用环境，历史上有很多非常典型的案例，如CVE-2015-1805曾经一度认为无法利用的漏洞，在几年以后被用作通用的提权工具，站在不同的开发者的角度，对代码缺陷（或者漏洞）的容忍度不同，因此我保留我的观点，也尊重作者的意见，可以将已公开的4个poc拒绝掉。

4. 最后我想再多说一点，这些问题仅仅是我开发过程中的一次意外，如果是个人仓库(影响范围有限)，我可能不会反馈这些问题，或者换一个库来使用，但是，当我在 snyk 查询了这个项目的历史漏洞，发现其影响范围已经超出了我的预期，这个项目作为一个公共库，影响的开源组件和操作系统非常广泛（超过200+），
   其代码实现中的缺陷导致我不得不放弃yaml解析库，改用toml库，这些代码缺陷影响的不仅仅是我个人，yaml作为被广泛使用的文件类型，基本影响了大部分的开发者，请重视这些问题。

5. 我不会再对此问题作出回应，抱歉占用了公共资源，给大家带来的困扰我非常抱歉，如有其他问题，非常欢迎随时与我邮件进行沟通。

Translation via DeepL:

I don't want to take up any more public resources, so I'll explain about these issues one last time:

The process of discovering these problems was as described in #297, I was using rust for development and needed to parse yaml files, so I introduced the serde_yaml library, and when I compiled it, I found out that it relied on unsafe-libyaml, and that I needed to be careful about using unsafe in rust, so I ended up finding this project. So I finally found this project, I read the API and some of the implementation code of this project, and found several flaws in its implementation, and I reproduced these problems in rust, see poc.

Regarding the disclosure process, I initially raised an issue (#297) in this project, and two weeks passed without anyone responding, and then I also stated under the issue that I would disclose all issues. In the meantime, after evaluating the risks (the latest version is 4 years old), I abandoned serde_yaml and used serde_toml instead, and made the poc that I had already written 4 public, and then the author replied to my issue, and since the timing of the disclosure was out of my control, there is a controversy about the #297 issue under the issue, and at this point I have terminated the commit! All undisclosed issues, no new disclosures will be made. Under #297 @Martchus reminded me that I shouldn't pressure open source maintainers, and this is really something I didn't consider, and I apologize for that, and I do hope that these issues will be responded to as soon as possible (I really do need this library in my development process).

Regarding the controversy of vulnerability or not, I would like to say that whether a vulnerability can be exploited or not is a very subjective thing, depending on the technical level and usage environment of an individual, there are many very typical cases in history, such as CVE-2015-1805 once thought to be unavailable vulnerability, was used as a generalized power-raising tool a few years later, standing from the point of view of different developers, the code defects (or vulnerability ) are tolerated differently by different developers, so I reserve my opinion and respect the author's opinion that the 4 pocs that have been made public can be rejected.

Finally I would like to add one more point, these problems are just an accident in my development process, if it is a personal repository (with a limited scope of influence), I may not give feedback on these problems, or change another library to use, but when I checked the history of vulnerabilities in this project in snyk, I found that the scope of its influence has exceeded my expectations, this project as a public library, affecting a wide range of open source components and operating systems very widely (over 200+).
The flaws in the code implementation led me to abandon the yaml parsing library and use the toml library instead. These code flaws affect more than just me, yaml as a widely used file type basically affects the majority of developers, so please pay attention to these issues.

I will not respond to this issue, sorry for taking up public resources, I'm very sorry for the trouble brought to everyone, if you have any other questions, you are very welcome to communicate with me by email at any time.

Adding translation:

I don't want to occupy public resources anymore, so I'll explain these issues one last time:

The process of discovering these problems, as mentioned in #297, when I was developing with rust, I needed to parse yaml files, so I introduced the serde_yaml library. When I compiled it, I found that the library depended on unsafe-libyaml. It is necessary to be very cautious to use unsafe in rust, so I finally found this project. I read the API and some implementation codes of this project roughly, and found that there are many defects in its implementation process, and reproduced these problems in rust, see poc.

Regarding the disclosure process, I first raised an issue in this project (

double-free on yaml_event_delete api #297), and no one responded after two weeks. Then I also explained under the question that I will disclose all problems. At the same time, after evaluating the risks (the latest version has been out for 4 years), I gave up serde_yaml and used serde_toml instead, and made the 4 POCs I had written public. The author then responded to my issue. Since I could not control the time of publication, there was a dispute about issue #297. At this time, I had stopped submitting all undisclosed issues and there would be no new disclosures. @Martchus reminded me under #297 that I should not put pressure on open source maintainers. This is indeed a problem I did not consider. I apologize for this. I really hope that these issues can be responded to as soon as possible (I really need this library during the development process).

Regarding the dispute over whether there is a vulnerability or not, I want to say that whether a vulnerability can be exploited is a very subjective thing, which depends on the individual's technical level and the use environment. There are many very typical cases in history, such as CVE-2015-1805, which was once considered to be an unexploitable vulnerability, but was used as a general privilege escalation tool a few years later. From the perspective of different developers, the tolerance for code defects (or vulnerabilities) is different. Therefore, I retain my point of view and respect the author's opinion. The 4 POCs that have been made public can be rejected.

Finally, I would like to say a little more. These problems are just an accident in my development process. If it is a personal repository (limited scope of impact), I may not report these problems or use another library. However, when I checked the historical vulnerabilities of this project in snyk, I found that its scope of impact has exceeded my expectations. As a public library, this project affects a wide range of open source components and operating systems (more than 200+). The defects in its code implementation forced me to abandon the yaml parsing library and use the toml library instead. These code defects affect not only me personally. As a widely used file type, yaml basically affects most developers. Please pay attention to these issues. I will not respond to this issue again. I am sorry for occupying public resources. I am very sorry for the troubles caused to everyone. If you have other questions, you are very welcome to communicate with me by email at any time.

@idhyt you reported the issues but the maintainer was unresponsive. In that case disclosure is the proper thing to do. All is well with that.

From POV of Haskell Advisory Database, without a PoC or a clear way to exploit the issue, or an patch to the upstream that resolves the issue, it is debatable whether issuing an advisory actually helps. We are thankful that bugs (whether expoitable or not) get reported and discussed, and hope that widely used libraries are actively and sustainable maintained.

If the upstream fixes the issue, we can issue an advisory, with the effect that users of versions containing the bug should be encouraged to upgrade.

@idhyt you reported the issues but the maintainer was unresponsive. In that case disclosure is the proper thing to do. All is well with that.

no, no, no.
How often do I have to repeat that?
Only one of the four issues was reported to us in #297.
And the waiting time was only 2 weeks.
For this issue here and the other two we were never contacted.
Please stop spreading that false information.
Nothing well here.

I misunderstood, and did not intend to spread wrong information.

Let's get back to the issues in the code - whether they be considered vulnerabilities or not. What is the next step? Will there be an unstream release to fix those issues?

I'm still not sure if a fix is needed, because without initializing the structure the program can't work anyway.
I just can't see how there would be such broken code out there that does nothing useful.

#299 is a start for one of the three issues, but I was playing with it and there seem to be more functions that would need the check.
And for the parser and emitter case, there would also be quite a number of functions that need to add such a check.
It's a lot of work.
I have been already quite busy in the last months by a couple of invalid reports from google oss-fuzz (had to fix their code because there were bugs in the fuzztesting code instead of libyaml). I spent a lot of my time on this.

#297 instead is something that can happen in an otherwise valid program, but I'm not sure what to do about that without changing the struct. And also there is no known exploit yet.