Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Smile: wrong cached property name returned for names containing 0xFF bytes

Aperta
  • Qualcosa non va?
#869 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
71/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java
Ambito
backend

Direzione di ricerca

Start with the listed lookup and padding paths in SmileParser, NonBlockingParserBase, and NonBlockingByteArrayParser, then compare the suggested _padAndValidateLastQuad() approach in jackson-core#1785. Reproduce the cached-name case with the supplied byte sequence and check both short and long field names, including the non-blocking parser. Done means invalid 0xFF is reported instead of returning a previously cached property name.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

smile

SmileParser and NonBlockingByteArrayParser can return the wrong property name when a name contains a 0xFF byte. Instead of reporting the invalid UTF-8 byte, they return a different name that was seen earlier.

Same class of bug as FasterXML/jackson-core#1784.

Reproduced on 2.x:

// header, {"a": 1, <0xFF 'a'>: 2}
byte[] doc = {':', ')', '\n', 0x00, (byte) 0xFA,
    (byte) 0x80, 'a', (byte) 0xC2,              // short ASCII name "a"
    (byte) 0xC0, (byte) 0xFF, 'a', (byte) 0xC4, // short Unicode name, 2 bytes
    (byte) 0xFB};
JsonParser p = new SmileFactory().createParser(doc);
// property names returned: "a", "a"

The non-blocking parser returns the same. Without a cached "a", the second name fails as expected with Invalid byte 0xFF in short Unicode text block. The symbol table belongs to the factory, so a name from an earlier document parsed with the same SmileFactory matches too.

Long names (token 0x34, ended by 0xFC) are affected the same way. For example, 64 'a' bytes followed by FF 61 61 return the cached 66-'a' name.

Cause: when building quads for symbol table lookup, the last partial quad is padded with 0xFF bytes. So a name whose last partial quad starts with 0xFF produces the same quads as a shorter name, e.g. FF 61 and 61 both give 0xFFFFFF61. On a symbol table hit the name bytes are never decoded, so the 0xFF is not reported.

Affected code:

  • SmileParser: short-name lookups using _padQuadForNulls(), and _handleLongFieldName() using _padLastQuad()
  • NonBlockingParserBase: short-name lookups using _padQuadForNulls()
  • NonBlockingByteArrayParser._finishLongFieldName(): _padQuadForNulls()

Suggested fix: 0xFF is never valid in UTF-8, so reject it as the first byte of the partial quad before padding, as jackson-core#1785 does with _padAndValidateLastQuad().

Lingua principale
Java
Stelle
348
Fork
159
Merge medio
22h 34m
PR unite (30g)
39

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di FasterXML/jackson-dataformats-binary

Tutte le issue di FasterXML/jackson-dataformats-binary

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.