Catch and rethrow yaml engine internal exception on generation

[pjfanning]

see https://oss-fuzz.com/testcase-detail/4866995549175808

[cowtowncoder]

@pjfanning Made small change to use existing JacksonIOException which is used by jackson-core and YAML parser side to wrap underlying IOExceptions.

Now: we don't really have test to show how YamlEngineException (specifically, EmitterException) would be thrown. So I'm bit torn b/w merging this as speculative fix, vs postponing addition of new wrapper type, handling. I guess I can do partial merge now.

[cowtowncoder]

Ok: merged JacksonIOException wrapping part, leaving the rest here.
Would be great to reproduce YamlEngineException throw case, its handling.

[pjfanning]

The OSS Fuzz trace is

== Java Exception: org.snakeyaml.engine.v2.exceptions.EmitterException: expected NodeEvent, but got DocumentEnd
--
  | at org.snakeyaml.engine.v2.emitter.Emitter.expectNode(Emitter.java:466)
  | at org.snakeyaml.engine.v2.emitter.Emitter$ExpectDocumentRoot.expect(Emitter.java:448)
  | at org.snakeyaml.engine.v2.emitter.Emitter.emit(Emitter.java:241)
  | at tools.jackson.dataformat.yaml.YAMLGenerator._emit(YAMLGenerator.java:802)
  | at tools.jackson.dataformat.yaml.YAMLGenerator._emitEndDocument(YAMLGenerator.java:798)
  | at tools.jackson.dataformat.yaml.YAMLGenerator.close(YAMLGenerator.java:326)

So we see that it is possible that org.snakeyaml.engine.v2.emitter.Emitter.expectNode can throw org.snakeyaml.engine.v2.exceptions.EmitterException under certain circumstances.

I'm not sure how to make snakeyaml do this but we have some level of proof that is possible to trigger something like this.

[cowtowncoder]

@pjfanning Ok. Given stack trace, maybe co-pilot could attempt a reproduction. FWTW, it sounds like empty YAML document, or mis-match with events. But I don't know how Fuzz case actually works; does it generate "YAML" content to round-trip (read-then-write) or something.

But it does sound like there is probably a path that could trigger this.

[pjfanning]

@cowtowncoder maybe it's not as important to worry about issues generating YAML or other data formats. Parsing is a more attackable API - it's harder to manipulate a scenario where issues in generators can be abused

[cowtowncoder]

Yeah I don't really consider RuntimeException leakage a real attack vector anyway in Java, more a usability/correctness/ergonomic thing.