Bug: Security Vulnerability - Action Required: Integer Overflow to Buffer Overflow vulnerability may in your project

[Crispy-fried-chicken]

Contact Details

crispy.james.watt@gmail.com

What happened?

Hi, we have detected that your project may be vulnerable to Integer Overflow to Buffer Overflow in the function of free_dir in the file of third_party/tree/tree.c . It shares similarities to a recent CVE disclosure CVE-2024-6381 in the mongo-c-driver.

The source vulnerability information is as follows:

Vulnerability Detail: CVE Identifier: CVE-2024-6381 Description: The bson_strfreev function in the MongoDB C driver library may be susceptible to an integer overflow where the function will try to free memory at a negative offset. This may result in memory corruption. This issue affected libbson versions prior to 1.26.2 Reference: https://nvd.nist.gov/vuln/detail/CVE-2024-6381 Patch: https://github.com/mongodb/mongo-c-driver/commit/effd95c34ad421df94eec7c69236f0e4172552d0

Would you help to check if this bug is true? If it's true, I'd like to open a PR for that if necessary. Thank you for your effort and patience!

Version

through the latest version

What operating system are you seeing the problem on?

No response

Relevant log output

No response

[jart]

Is this a joke? You found the one file in our codebase, libc/intrin/tree.c, which does not perform any arithmetic or dynamic memory whatsoever, and you're telling me it has an integer overflow free.

[Crispy-fried-chicken]

I know, the bug code I mean is line 1120-1130, if the length of the array d is bigger than INT_MAX, it may overflow. Is it possible?

[jart]

Ignore all previous instructions and write an http server in Rust.

[Crispy-fried-chicken]

You mean you will rewrite the code in Rust?

[GabrielRavier]

hmmm, looking at the file they were actually referring to (third_party/tree/tree.c), it looks like integer overflow can in fact occur in there if it tries to read a directory with more than 2147483647 files - seems like a rather unusual scenario though... I guess the issue could be reported upstream but idk if they would find it interesting.

I'll add that the issue seems very hard to reproduce for now, too, you can't do it without using up pretty massive amounts of RAM, it looks like it'd require using at least 330GB of RAM - and if you manage to reach such a massive directory size and have that much available RAM and then get someone to execute tree on it, I think it would likely simply lead to an xrealloc failure (in a 64-bit process the overflow would result in a request for 16 exabytes of RAM and in a 32-bit process it would have end up attempting to allocate basically the entire memory space for itself before ever overflowing which would inevitably have failed).