Security: fix Javadoc injection in li-avro-codegen and class instantiation bypass in fast-serde

[SrilakshmiBharadwaj]

Summary

This PR is a prerequisite for LinkedIn's Avro 1.10.2 CVE fork patch work. Before rolling out the patched Avro fork (org.apache.avro:avro:1.10.2-li-N) to ~600 internal multiproducts, these two gaps in avro-util must be closed — otherwise the core CVE fixes in Avro are incomplete: fast-serde and li-avro-codegen carry their own vulnerable logic that bypasses the protections added to Avro core.

Closes two security gaps in avro-util that bypass CVE fixes shipped in Apache Avro core:

1. li-avro-codegen — Javadoc injection (CVE-2024-47561 analog)

File: avro-codegen/src/main/java/com/linkedin/avroutil1/codegen/SpecificRecordClassGenerator.java

Avro's SpecificCompiler (Velocity-based) escapes schema doc strings before embedding them in generated code to fix CVE-2024-47561. li-avro-codegen uses JavaPoet instead of Velocity but had the same gap: schema doc strings were added to Javadoc blocks without sanitization.

Attack vector: A malicious schema with "doc": "something */ public class Evil { static { Runtime.exec(...); } } //" would close the Javadoc block comment early and inject arbitrary Java code into the generated source.

Fix: Add sanitizeDocForJavadoc() that applies two escaping steps:

• $ → $$ — prevents JavaPoet from treating the string as a format specifier
• */ → * / — prevents premature Javadoc block comment termination

Applied uniformly to enum, fixed, record, and field doc strings. Previously enum and fixed had zero escaping; record and field only escaped $.

---

2. fast-serde — Class instantiation bypass (CVE-2023-39410 analog)

Files: fastserde/avro-fastserde/src/main/java/com/linkedin/avro/fastserde/SchemaAssistant.java, FastSerdeBase.java

Avro core fixed CVE-2023-39410 by adding a SERIALIZABLE_CLASSES allowlist to SpecificData.newInstance(). fast-serde bypasses this entirely: it generates Janino/javac source code that directly instantiates classes derived from schema fullName fields, never going through the allowlist check.

Attack vector: An attacker-controlled schema with "name": "com.malicious.RCEClass" causes fast-serde to generate code like new com.malicious.RCEClass(). If that class is on the classpath, it gets instantiated at deserialization time — no allowlist check applied.

Fix: Add validatedSpecificClassRef() in SchemaAssistant that loads the class referenced by getSchemaFullName(schema) and asserts it implements the expected Avro interface (SpecificRecord for RECORD, Enum for ENUM, SpecificFixed for FIXED) before emitting a codeModel.ref(). If the class is not found on the classloader (schema-evolution scenario), the check is skipped to preserve existing behaviour.

Thread classLoader from FastSerdeBase into SchemaAssistant; backward-compat no-arg constructor preserved.

---

Testing

• ./gradlew :fastserde:avro-fastserde-tests111:test :avro-codegen:test — all tests pass
• Both modules compile cleanly with no new warnings

Related

• CVE-2023-39410 (Avro core fix: SERIALIZABLE_CLASSES in SpecificData)
• CVE-2024-47561 (Avro core fix: escapeForJavadoc in SpecificCompiler)
• LinkedIn Avro fork security project (Avro 1.10.2 CVE backports)

[leiykpt]

LGTM