[
https://issues.apache.org/jira/browse/HBASE-30304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18100856#comment-18100856
]
Hudson commented on HBASE-30304:
--------------------------------
Results for branch branch-3
[build #597 on
builds.a.o|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-3/597/]:
(x) *{color:red}-1 overall{color}*
----
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-3/597/General_20Nightly_20Build_20Report/]
(x) {color:red}-1 jdk17 hadoop3 checks{color}
-- For more information [see jdk17
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-3/597/JDK17_20Nightly_20Build_20Report_20_28Hadoop3_29/]
> Bytes.toBytesBinary throws StringIndexOutOfBoundsException on truncated \x
> escape
> ---------------------------------------------------------------------------------
>
> Key: HBASE-30304
> URL: https://issues.apache.org/jira/browse/HBASE-30304
> Project: HBase
> Issue Type: Bug
> Reporter: Junegunn Choi
> Assignee: Junegunn Choi
> Priority: Minor
> Labels: pull-request-available
> Fix For: 4.0.0-alpha-1, 2.7.0, 2.5.16, 2.6.7, 3.1.0, 3.0.1
>
>
> h2. Problem
> {{Bytes.toBytesBinary}} parses {{\xNN}} hex escapes. The guard checks only
> that the {{x}} after a backslash exists ({{in.length() > i + 1}}), then reads
> {{charAt(i + 2)}} and {{charAt(i + 3)}} unconditionally, so a string ending
> in a truncated {{\x}} escape throws {{StringIndexOutOfBoundsException}}.
> {code:java}
> Bytes.toBytesBinary("abc\\x00\\x01\\x"); // throws, reads past end at i + 2
> Bytes.toBytesBinary("abc\\x00\\x01\\x0"); // throws, reads past end at i + 3
> {code}
> HBASE-6518 fixed the trailing bare-backslash case with the same guard but did
> not extend it to the two hex digits, so this sub-case remained.
> h2. Fix
> Widen the guard to {{in.length() > i + 3}} so both hex reads are in bounds. A
> truncated tail escape then falls through to the existing bogus-escape path
> and emits the backslash literally. Valid escapes and mid-string bogus escapes
> are unchanged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)