Roman Arce created ORC-2214:
-------------------------------
Summary: Harden RLE integer decoders against buffer cursor
overshoot
Key: ORC-2214
URL: https://issues.apache.org/jira/browse/ORC-2214
Project: ORC
Issue Type: Improvement
Components: C++, RLE
Reporter: Roman Arce
A malformed/truncated RLE stream can drive the C++ RLE integer decoders' read
cursor past the end of the internal stream buffer, causing out-of-bounds heap
reads (detected by AddressSanitizer as heap-buffer-overflow READ) when reading
a crafted ORC file via the public reader API.
Root cause: RleDecoderV2::bufLength() (c++/src/RLEv2.hh) returns the raw
(unsigned) pointer difference between bufferEnd_ and bufferStart_; once the
cursor overshoots (bufferStart_ > bufferEnd_) this underflows to a value near
2^64, defeating the std::min clamps in the UnpackDefault bit-unpacking fast
loops (BpackingDefault.cc). Separately, RleDecoderV2::readByte() and
RleDecoderV1::readByte() gated their buffer refill on strict equality
(bufferStart_ == bufferEnd_), so an already-overshot cursor skips the refill
and dereferences out of bounds.
Impact is limited to a crash / out-of-bounds read while parsing an untrusted
file (no write, no code execution demonstrated). This was reported privately to
[email protected]; per the project's published security model
(https://orc.apache.org/security/), a crash on malformed input is out of scope
as a vulnerability, and ASF Security (Arnout Engelen) invited submitting the
fix as a hardening improvement through the normal contribution channel.
A PR implementing the fix is already open: apache/orc#2691 — "Harden RLE
integer decoders against buffer cursor overshoot"
(https://github.com/apache/orc/pull/2691). It has been validated against the
full C++ unit suite (752/752 passing) and against AddressSanitizer-built
reproduction cases (31/31 previously-crashing malformed-file cases now handled
cleanly).
This issue was created at the request of @luffy-zh in the PR discussion, since
the project tracks changes in JIRA rather than GitHub Issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
