DecodingReader::set_encoding panics when the XML declaration is longer than 64 bytes

Open
  • Is something wrong?
#1,040 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@emschwartz is already working on this.

Since Nov 10, 2026.

  • #1041 by @emschwartz — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
30/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
data

Research direction

The panic comes from the assert in set_encoding() in src/encoding.rs (around line 380), which fires once the 64-byte PREFIX_CAP buffer has been drained. Start by reading how that prefix is filled and drained in the DecodingReader fill path. Then run the three repro tests from the issue (long ASCII body, Latin-1 body, UTF-16 with BOM). Done means none of them panic, and the Latin-1 case decodes correctly. Fixing it needs an encoding-design decision, so check with maintainers first.

Written by the indexing model from the issue text.

Description

bug encoding

DecodingReader::set_encoding can panic on valid input. I found this while working to update rss and atom_syndication to quick-xml v0.42. Below, I have an AI-authored repro that shows how to trigger this panic.

Let me know if you'd like a PR to fix this.

The analysis and repros below were drafted with Claude (claude-fable-5-2) and checked against 0.42.0 and master.

The documented DecodingReader loop (call set_encoding() on Event::Decl) panics when the XML declaration is longer than the 64-byte prefix (PREFIX_CAP). XML allows extra whitespace inside the declaration, so well-formed input can trigger the panic.

0.42.0 and master (250824b) give the same result, with the encoding feature on. tests/repro.rs:

use quick_xml::encoding::DecodingReader;
use quick_xml::events::Event;
use quick_xml::reader::Reader;

/// The documented loop: wrap in `DecodingReader`, `set_encoding()` on `Decl`.
fn texts(xml: &[u8]) -> Result<Vec<String>, quick_xml::Error> {
    let mut reader = Reader::from_reader(DecodingReader::new(xml));
    let mut buf = Vec::new();
    let mut out = Vec::new();
    loop {
        match reader.read_event_into(&mut buf)? {
            Event::Decl(d) => {
                if let Some(enc) = d.encoder() {
                    reader.get_mut().set_encoding(enc);
                }
            }
            Event::Text(t) => out.push(t.to_string()),
            Event::Eof => return Ok(out),
            _ => {}
        }
        buf.clear();
    }
}

/// The declaration is 68 bytes long, so it does not fit in the 64-byte prefix.
#[test]
fn long_declaration_ascii_body() {
    let xml = b"<?xml version=\"1.0\"                          encoding=\"ISO-8859-1\"?><a>e</a>";
    assert_eq!(texts(xml).unwrap(), ["e"]);
}

#[test]
fn long_declaration_non_ascii_body() {
    let xml = b"<?xml version=\"1.0\"                          encoding=\"ISO-8859-1\"?><a>\xE9</a>";
    assert_eq!(texts(xml).unwrap(), ["\u{e9}"]);
}

/// UTF-16LE with BOM, declaration says UTF-8 (self-contradicting document).
#[test]
fn utf16_long_declaration() {
    let mut xml = vec![0xFF, 0xFE];
    for c in "<?xml version=\"1.0\" encoding=\"UTF-8\"?><a>x</a>".encode_utf16() {
        xml.extend_from_slice(&c.to_le_bytes());
    }
    assert_eq!(texts(&xml).unwrap(), ["x"]);
}

cargo test output (paths shortened, thread ids removed):

---- long_declaration_ascii_body stdout ----
thread 'long_declaration_ascii_body' panicked at src/encoding.rs:380:9:
set_encoding() called after prefix buffer was drained; encoding can only be changed while the prefix is still active

---- long_declaration_non_ascii_body stdout ----
thread 'long_declaration_non_ascii_body' panicked at tests/repro.rs:35:27:
called `Result::unwrap()` on an `Err` value: Encoding(Other(Encoding { name: "UTF-8", .. }))

---- utf16_long_declaration stdout ----
thread 'utf16_long_declaration' panicked at src/encoding.rs:380:9:
set_encoding() called after prefix buffer was drained; encoding can only be changed while the prefix is still active

The three cases

  • ASCII body: the prefix is already drained when the Decl event arrives, so set_encoding() hits its assert. A 64-byte declaration works; 65 bytes panics.
  • Non-ASCII Latin-1 body: the same declaration with \xE9 in the body returns a UTF-8 encoding error instead of a panic.
  • UTF-16: the prefix holds 32 UTF-16 characters, so behind a BOM a declaration of 32 characters or more panics the same way. The test's declaration is 38 characters and names UTF-8, which contradicts the BOM. An error would be fine there, a panic is not.

Context

  • 0.41 baseline: 0.41.0 with a plain Reader (no DecodingReader, encoding feature) parses both Latin-1 inputs and returns e and é.
  • The prefix and set_encoding() came with #956 (6f5d029, 0.40.0).
  • #1023 (merged) fixed non-ASCII bytes inside the first 64 bytes. This is the case it leaves: the declaration itself runs past the prefix.
  • All three tests fail the same way on the branch of open PR #1033.

Impact

rss and atom_syndication are on quick-xml 0.41 with the encoding feature. They can't upgrade to 0.42 while a feed they parse today can panic.

Suggested fix

Keep set_encoding() usable until the first > has been decoded, instead of only while the 64-byte prefix lasts. Where a switch is impossible, such as a BOM that contradicts the declaration, set_encoding() could store an error that the next fill_buf returns as an io::Error. Its signature stays the same.

Dominant language
Rust
Stars
1.6k
Forks
299
Avg merge
2d 4h
Merged PRs (30d)
9

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from tafia/quick-xml

All issues in tafia/quick-xml

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.