An eager-allocation denial-of-service in jackson-dataformats-binary's async Smile parser (latest, 3.2.2 / "tools.jackson" line), where a raw-binary length prefix from untrusted input is used to allocate a "byte[]" before the body is read, with no upper bound and no overflow check. This is the same class as the HIGH-rated CBOR CVE-2020-28491 in this library, which was fixed with a "LONGEST_NON_CHUNKED_BINARY" guard; the async Smile parser never received the equivalent guard. Reporter: apvxlab (AppViewX security research). Split out of GHSA-ww35-763r-jg22 at the maintainer's request so one GHSA maps to one component (async Smile). The Protobuf issue remains in GHSA-ww35-763r-jg22. File: "smile/src/main/java/tools/jackson/dataformat/smile/async/NonBlockingByteArrayParser.java" ("_startRawBinary", ~line 1484; also "_finishRawBinaryLen" ~line 1496). On the raw-binary marker "0xFD", "_decodeVInt()" computes "(value << 6) + (i & 0x3F)" with no overflow check. The blocking "SmileParser._readUnsignedVInt" guards this with "(value >>> 25) != 0", but the async variant omits it. "_startRawBinary" then does "_binaryValue = new byte[len]" immediately, before the body is required. Impact. A ~10-byte async Smile feed forces an eager ~2 GB allocation (OutOfMemoryError) on reactive / async Smile endpoints (WebFlux, Vert.x, Micronaut). A VInt crafted to overflow "int" yields a negative length, giving a "NegativeArraySizeException", a non-"JacksonException" "RuntimeException" that escapes the parser contract. Either way an untrusted input crashes the request/processing thread (denial of service). Reproduction. "SmileFactory.builder().build().createNonBlockingByteArrayParser(...)"; feed a Smile 4-byte header ("0x3A 0x29 0x0A <hdr>") + "0xFD" + a 5-byte unsigned VInt encoding ~2,000,000,000, then call "nextToken()" → "_startRawBinary" → "new byte[~2e9]". Choosing the VInt bytes so "(value << 6) + (i & 0x3F)" overflows negative gives the "NegativeArraySizeException" crash variant. Fix. Add the "(value >>> 25)" overflow check to the async "_decodeVInt", and route large raw-binary lengths through an incremental read as the blocking parser does ("_finishBinaryRawLong" for "byteLen > 250000"). Code-verified against the 3.2.2 source with the exact reproduction input above. Happy to provide a runnable harness and coordinate the fix.