Malformed COM_STMT_EXECUTE JSON parameter causes ASan SEGV in `ObILobCursor::read_i16()`

Self Checks

• I have read the Contributing Guide.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

OceanBase version

OceanBase_CE 4.6.0.0

Self Hosted

Self Hosted (Source)

Environment

OS Version and CPU Arch (uname -a):

Linux bass1 6.8.0-124-generic #124~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue May 26 21:05:19 UTC  x86_64 x86_64 x86_64 GNU/Linux

OB Version (LD_LIBRARY_PATH=../lib:$LD_LIBRARY_PATH ./observer -V):

observer (OceanBase_CE 4.6.0.0)

REVISION: 1-109121611519b2f74bcf154ed8fcbcde7984df19
BUILD_BRANCH: develop
BUILD_TIME: Jun 16 2026 16:45:32
BUILD_FLAGS: RelWithDebInfo
BUILD_INFO:

The crash was reproduced on a local single-node ASan build/deployment of OceanBase.

Steps to reproduce

This is a protocol-level PoC. The SQL text alone is not expected to reproduce the crash; the trigger depends on a prepared statement and a crafted COM_STMT_EXECUTE payload containing malformed OceanBase binary JSON data.

Attached files:
reproduce.py
asan.log

Install the Python dependency:

pip install PyMySQL

Run the PoC against a test OceanBase instance:

python3 reproduce.py -H <ip> -P <port> -u <user> -p <password>

The PoC performs this sequence:

1. COM_STMT_PREPARE: SELECT ?
2. COM_STMT_EXECUTE with one non-NULL parameter.
   The parameter type is MYSQL_TYPE_JSON (0xf5) and its 15-byte
   binary-JSON object has malformed internal object metadata.

Observed output from the reproducer:

[*] COM_STMT_PREPARE payload_len=9
    stmt_id=<runtime statement id>, num_params=1, num_columns=1
[*] COM_STMT_EXECUTE payload_len=30
[!!!] Connection lost or timed out while waiting for COM_STMT_EXECUTE: ...
[*] Reconnect probe 1/3 failed: ...
[*] Reconnect probe 2/3 failed: ...
[*] Reconnect probe 3/3 failed: ...
[!!!] BUG CONFIRMED: server appears to be down

Relevant ASan excerpt:

ERROR: AddressSanitizer: SEGV on unknown address
The signal is caused by a READ memory access.
    #0 oceanbase::common::ObILobCursor::read_i16(...)
       deps/oblib/src/lib/lob/ob_lob_base.cpp:84
    #1 oceanbase::common::ObJsonVar::read_var(...)
       deps/oblib/src/lib/json_type/ob_json_bin.cpp:4525
    #2 oceanbase::common::ObJsonBin::get_value_entry(...)
       deps/oblib/src/lib/json_type/ob_json_bin.cpp:4946
    #7 oceanbase::common::ObIJsonBase::print_object(...)
       deps/oblib/src/lib/json_type/ob_json_base.cpp:3685
    #10 oceanbase::observer::ObMPStmtExecute::store_params_value_to_str(...)
       src/observer/mysql/obmp_stmt_execute.cpp:651
    #12 oceanbase::observer::ObMPStmtExecute::request_params(...)
       src/observer/mysql/obmp_stmt_execute.cpp:1037

✔️ Expected Behavior

OceanBase should reject malformed binary JSON parameter data with a protocol error and keep the observer process alive.

❌ Actual Behavior

While processing the crafted COM_STMT_EXECUTE, observer crashes under AddressSanitizer with a read-access SEGV. The crash occurs while the prepared-statement path formats the JSON parameter as SQL text, before the prepared SQL statement needs to execute.

The top OceanBase frame is:

oceanbase::common::ObILobCursor::read_i16(...)
deps/oblib/src/lib/lob/ob_lob_base.cpp:84

Start by running reproduce.py against a test OceanBase instance and reviewing asan.log. Trace the reported path from src/observer/mysql/obmp_stmt_execute.cpp:651 and :1037 through deps/oblib/src/lib/json_type/ob_json_bin.cpp:4525 and :4946 to deps/oblib/src/lib/lob/ob_lob_base.cpp:84. Done means malformed COM_STMT_EXECUTE JSON is rejected with a protocol error and the observer remains alive.