MDEV-40385 use-of-uninitialized-value in Binary_string::c_ptr()

[LukeYL026]

Description

SELECT KDF('','',1000,256) triggered an MSAN use-of-uninitialized-value
report originating in Binary_string::c_ptr() (sql/sql_string.h) reached from
Item_func_kdf::val_str() (sql/item_strfunc.cc).

In Item_func_kdf::val_str(String *buf) the optional 4th argument (kdf_name)
was evaluated into the shared result buffer buf and then read as a C
string:

if (String *s= args[3]->val_str(buf))      // buf == the shared result buffer
{
  if (strcasecmp(s->c_ptr(), "hkdf") == 0)
  ...

The issue is when args[3] is an integer literal (here 256), Item_int::val_str() writes the digits "256" (length 3) into the buffer, and String::alloc() intentionally skips reallocation when the buffer is already large enough — so the buffer stays non-alloced and is left without a trailing NUL.

c_ptr() then executes:

if (unlikely(!alloced && !Ptr[str_length]))   // reads Ptr[3]
  return Ptr;

Because the buffer is not alloced, c_ptr() first reads Ptr[str_length]
(i.e. buf[3]) to decide whether a terminator already exists. That byte is
validly addressable (the buffer is large) but was never initialized, so MSAN
flags a use-of-uninitialized-value. Valgrind does not flag it because that stack
byte was typically written by an earlier call frame; only MSAN re-poisons the
stack scope, which is why the report is MSAN-only.

Fix

sql/item_strfunc.cc, Item_func_kdf::val_str():

• Use s->c_ptr_safe() instead of s->c_ptr(). c_ptr_safe() never reads
  Ptr[str_length]; it writes the terminator (or reallocates), removing the
  uninitialized read regardless of the buffer's alloced state.

Behaviour is unchanged for callers: a non-matching kdf_name still yields the
ER_STD_INVALID_ARGUMENT warning and NULL, and valid names (pbkdf2_hmac,
hkdf) still work.

Release Notes

Resolved uninitialized read deficiency in Binary_string::c_ptr() via item_func_kdf::val_str().

How can this PR be tested?

Because this stray read is harmless without a sanitizer, related MTR tests need to be run on an MSAN build to observe regression. Run MTR on an MSAN build by adding build flag-DWITH_MSAN=ON (clang), which requires MSAN-instrumented system
libraries — see
https://mariadb.com/kb/en/compile-and-using-mariadb-with-sanitizers-asan-ubsan-tsan-msan/

The following test and result files were added as regression tests:

• mysql-test/main/mdev40385.test
• mysql-test/main/mdev40385.result

Basing the PR against the correct MariaDB version

Based against 11.4, the oldest maintained LTS affected. The JIRA MSAN matrix
shows 10.6 and 10.11 as unaffected because the KDF() function does not
exist there; the defect is present from 11.4 onward.

Copyright

All new code of the whole pull request, including one or several files that are
either new files or modified ones, are contributed under the BSD-new license. I
am contributing on behalf of my employer Amazon Web Services, Inc.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[gkodinov]

Thank you for your contribution! This is a preliminary review.