[
https://issues.apache.org/jira/browse/LUCENE-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275859#comment-16275859
]
Xiaoshan Sun commented on LUCENE-8075:
--------------------------------------
--------------
Please Refer to "Trusted Operating System and System Assurance Working Group,
TCA, Institute of Software, Chinese Academy of Sciences" in the
acknowledgement if applicable.
> Possible null pointer dereference in
> core/src/java/org/apache/lucene/codecs/blocktree/IntersectTermsEnum.java
> -------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-8075
> URL: https://issues.apache.org/jira/browse/LUCENE-8075
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/codecs
> Affects Versions: 7.1
> Reporter: Xiaoshan Sun
> Labels: easyfix, security
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> Possible null pointer dereference in
> core/src/java/org/apache/lucene/codecs/blocktree/IntersectTermsEnum.java.
> This result is based on static analysis tools and the proofs are:
> *
> 106: if (fr.index == null) {
> 107: fstReader = null; // fr.index is Known NULL here.
> } else {
> fstReader = fr.index.getBytesReader();
> }
> // TODO: if the automaton is "smallish" we really
> // should use the terms index to seek at least to
> // the initial term and likely to subsequent terms
> // (or, maybe just fallback to ATE for such cases).
> // Else the seek cost of loading the frames will be
> // too costly.
> 119: final FST.Arc<BytesRef> arc = fr.index.getFirstArc(arcs[0]);
> // fr.index is dereferenced here and fr.index can be NULL if 107 is arrived.
> *
> We think it is reasonable to fix it by a test if fr.index is NULL and an
> error handling.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
