*New null dereference false positives:*
*913640*
"stack" is initialized with a document sentinel in the "ModelBuilder"
constructor, before the SAX parser delivers any callbacks. "startElement()"
pushes onto the stack, and "endElement()" only pops elements corresponding
to earlier "startElement()" calls. For well-formed XML, a conforming SAX
parser delivers balanced start/end events, and malformed XML aborts via
"fatalError()" (which throws), so an unmatched pop cannot occur. The
sentinel therefore always remains on the stack, and "peek()" cannot return
null during SAX processing.
*913641, 913642, 913644, 913647*
False positives for the same reasoning as 913640. All of these are
"stack.peek()" calls reached during "ModelBuilder" SAX callback processing,
either directly in the callbacks ("characters", "endDocument", "comment")
or in the "flushGap()" helper they call. In each case the sentinel is
always on the stack.
*XML external entity processing*
*913643*
The parser explicitly disables external DTD loading and external
general/parameter entity resolution ("load-external-dtd",
"external-general-entities", and "external-parameter-entities" are all set
to "false"). These are also among the protections Coverity itself
recommends against external entity resolution.
My reasoning here is that if external entity resolution is disabled, the
external resource cannot be loaded in the first place, so there should be
no external entity contents available to expand. However, I noticed that
"FEATURE_SECURE_PROCESSING" is not explicitly enabled here, which could be
why Coverity is still flagging the parser because it lists either that or
"setExpandEntityReferences(false)" together with the other settings. The
latter is not applicable here since it's a "SAXParserFactory", so I looked
further into FSP. I found that the JDK enables FSP by default for SAX
parsers, but Oracle's JAXP Security Guide notes that the default behavior
is not equivalent to explicitly enabling FSP through the API and that
explicit FSP applies additional security restrictions.
I wasn't able to confirm whether those additional restrictions are relevant
here, or whether setting FSP directly in the code was intentionally omitted
given the existing external-entity protections(?). Otherwise, it looks like
a false positive to me for the specific XXE concern.
*Best regards,*
*Fatima*
