Validate embedded objects for ZoneId, Period and ZoneOffset

[manqingzhou]

Description

As requested after reporting this by email, I am filing it here as a regular validation bug.

JSR310StringParsableDeserializer returns JsonParser.getEmbeddedObject() without checking that the returned object matches the requested type. With a binary data format and a type-erased generic container, this allows (for example) a CBOR byte string to be stored as the value of a Map<String, ZoneId> without any exception.

This affects the shared deserializer used for ZoneId, Period, and ZoneOffset.

Version information

• jackson-datatype-jsr310: 2.22.2
• jackson-dataformat-cbor: 2.19.2
• Java 8

The behavior was also reproduced against the current 2.x branch (2.23.0-SNAPSHOT).

Minimal reproduction

ObjectMapper mapper = new ObjectMapper(new CBORFactory());
mapper.registerModule(new JavaTimeModule());

ByteArrayOutputStream out = new ByteArrayOutputStream();
CBORGenerator gen = new CBORFactory().createGenerator(out);
gen.writeStartObject();
gen.writeFieldName("zone");
gen.writeBinary(new byte[] {
        (byte) 0xDE, (byte) 0xAD, (byte) 0xBE, (byte) 0xEF
});
gen.writeEndObject();
gen.close();

Map<String, ZoneId> result = mapper.readValue(
        out.toByteArray(),
        new TypeReference<Map<String, ZoneId>>() { });

Object value = result.get("zone");
System.out.println(value.getClass());
System.out.println(value instanceof byte[]);

Output:

class [B
true

The same behavior occurs for a List<ZoneId> and for the Period and ZoneOffset deserializers.

Expected behavior

The embedded object should be accepted only if it is compatible with the requested target type. An incompatible value should produce a normal Jackson mapping exception, such as MismatchedInputException.

Actual behavior

The raw byte[] is returned and inserted into the generic container. No exception is raised during deserialization.

A directly typed POJO field does fail because reflective field assignment performs an independent runtime type check. Generic map values and collection elements do not have that check because of type erasure.

Cause

The VALUE_EMBEDDED_OBJECT branch returns the object directly:

} else if (p.hasToken(JsonToken.VALUE_EMBEDDED_OBJECT)) {
    return p.getEmbeddedObject();
}

JSR310StringParsableDeserializer extends JSR310DeserializerBase<Object>, so no compiler-generated cast validates the returned value. The other JSR-310 deserializers that explicitly cast their embedded values fail immediately instead of silently placing the wrong type in the container.

One possible fix is to verify the embedded value against handledType() / _valueClass and route an incompatible value through DeserializationContext.handleUnexpectedToken(...).