<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-20T00:32:19.868672+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/cve-2026-111441</id>
    <title>CVE-2026-111441 — HLL 反序列化 lenTotal/lenUsed 校验缺失导致堆越界写</title>
    <updated>2026-10-20T00:32:19.869571+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> openGauss-server</p>
<p>在 openGauss-server 的 src/gausskernel/cbb/utils/hll/hll.cpp 中，内置函数 HllObjectUnpack() 存在长度校验缺陷。该函数从用户提供的 packed HLL 解析 lenUsed 与 lenTotal 后，仅检查输入长度足以覆盖 HLL_HEAD_SIZE + lenUsed，随后按 lenTotal 分配缓冲区、按 lenUsed 调用 memcpy_s() 拷贝输入，既未校验 lenTotal &gt;= 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 &lt;= lenTotal 校验，并将 memcpy_s() 的目标大小改为实际分配的 lenTotal。修复 PR 见 https://gitcode.com/opengauss/openGauss-server/pull/9380 。</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/cve-2026-111441"/>
  </entry>
</feed>
