这里记载我挖到的cve和细节：

1. cve-2025-68118
2. cve-xxxx-yyyyy（还没挖到）

CVE-2025-68118

https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-h78c-5cjx-jw6x

函数:freerdp_certificate_data_hash_

• 漏洞类型: 栈溢出 / 堆溢出（buffer overflow）
• 详细位置: 函数使用 _snprintf 写入目标缓冲区 ’name’，但未正确处理 _snprintf 的返回值。如果 ‘hostname’ 和 ‘port’ 组合生成的字符串长度大于或等于 ’length’，_snprintf 会截断输出，但不会在末尾添加空终止符，导致后续字符串操作（如 ensure_valid_charset）可能读取越界或写入越界。

实际上，ensure_valid_charset 和 ensure_lowercase 函数操作该缓冲区不会引发内存破坏，但是某个父函数在调用它之后很可能出现内存泄露

char* freerdp_certificate_data_hash(const char* hostname, UINT16 port)
{
	char name[MAX_PATH + 10] = { 0 };
	freerdp_certificate_data_hash_(hostname, port, name, sizeof(name));
	return _strdup(name);
}

Re:

​ nice catch! there is indeed a way that you can force a out of bound read if you have a server under your control. did correct your assessment though, there is no impact on availability as the client will not connect anyway (your redirected DNS name is just invalid in any case if you happen to hit this) you can also not expose the out of bound read data currently (at least not with our default clients) as the connection will be terminated.

comment

Thank you for the quick review and confirmation!

Regarding the impact assessment: I agree with your adjustment. My original assessment on “Availability” was based on the behavior of _strdup. Since _strdup reads blindly until a null terminator, there is a theoretical chance (depending on heap layout) that the read could cross into an unmapped memory page, triggering an Access Violation (Segmentation Fault) before the connection logic has a chance to handle the invalid hostname.

However, I understand that in most practical scenarios, it will likely just result in a connection error as you described.

Glad to help make FreeRDP more secure!