Live › vulnerability › CVE-2026-111441
Go to dashboardopenGauss's HllObjectUnpack() in hll.cpp checks only that the input covers the used length, then allocates by the total length and copies by the used length without checking that total is at least used. A database user who sends a malformed packed HLL, for example via ::hll into hll_in(), can trigger a heap out-of-bounds write on the server.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Any openGauss-server deployment on the affected versions that has the hll extension in use is exposed, since hll_in(), hll_print() and hll_cardinality() all reach the vulnerable unpack path. Any connected database user can trigger it, so multi-tenant or user-facing databases carry the most risk. Deployments already on 7.0.0-LTS or a build with the fix can skip it.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
在 openGauss-server 的 src/gausskernel/cbb/utils/hll/hll.cpp 中，内置函数 HllObjectUnpack() 存在长度校验缺陷。该函数从用户提供的 packed HLL 解析 lenUsed 与 lenTotal 后，仅检查输入长度足以覆盖 HLL_HEAD_SIZE + lenUsed，随后按 lenTotal 分配缓冲区、按 lenUsed 调用 memcpy_s() 拷贝输入，既未校验 lenTotal >= lenUsed，也将 memcpy_s() 目标大小写成 lenUsed 而非实际分配的 lenTotal，导致安全拷贝无法拦截越界写。hll_in()、hll_print()、hll_cardinality() 等 SQL 入口会走同一解包路径。因此，普通数据库连接用户只需构造 lenTotal 小于 lenUsed 的畸形 packed HLL（例如经 ::hll 进入 hll_in()），即可触发服务端堆越界写，存在内存破坏风险。此问题随 packed HLL 解包函数 HllObjectUnpack() 进入代码，v2.1.0 起即存在。受影响版本包括 2.1.0、3.0.x、3.1.x、5.0.x、5.1.0、6.0.x，以及 7.0.0-RC1、7.0.0-RC2、7.0.0-RC3。该问题已在 7.0.0-LTS 版本修复，通过在 HllObjectUnpack() 中补齐 lenUsed <= lenTotal 校验，并将 memcpy_s() 的目标大小改为实际分配的 lenTotal。修复 PR 见 https://gitcode.com/opengauss/openGauss-server/pull/9380 。
This page as .md · .json · in your agent: get_signal("CVE-2026-111441")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.