pdf
pdf copied to clipboard
index out of ranges and assertion failures
Sorry, there are 3 more
toka@toka:~/repro$ ./target/release/repro crash-282.pdf
thread 'main' panicked at 'range end index 1 out of range for slice of length 0', /home/toka/.cargo/git/checkouts/pdf-3ef1c528a9b91eec/a1608d9/pdf/src/enc.rs:501:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
crash-282.pdf https://github.com/pdf-rs/pdf/blob/677152fa8e84a2dcfbc3d927535148bb8d0369ba/pdf/src/enc.rs#L501
toka@toka:~/repro$ ./target/release/repro crash-538.pdf
thread 'main' panicked at 'assertion failed: !key.is_empty() && key.len() <= 256', /home/toka/.cargo/git/checkouts/pdf-3ef1c528a9b91eec/a1608d9/pdf/src/crypt.rs:37:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
crash-538.pdf https://github.com/pdf-rs/pdf/blob/677152fa8e84a2dcfbc3d927535148bb8d0369ba/pdf/src/crypt.rs#L37
toka@toka:~/repro$ ./target/release/repro crash-203.pdf
thread 'main' panicked at 'range end index 32 out of range for slice of length 21', /home/toka/.cargo/git/checkouts/pdf-3ef1c528a9b91eec/a1608d9/pdf/src/crypt.rs:562:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
crash-203.pdf https://github.com/pdf-rs/pdf/blob/677152fa8e84a2dcfbc3d927535148bb8d0369ba/pdf/src/crypt.rs#L562
I have found 4 more different crashes.
To reproduce.
cd pdf/fuzz and build the fuzzer with cargo fuzz build
and run with the following inputs.
Running: crash-201.pdf
thread '<unnamed>' panicked at /tmp/pdf/pdf/src/encoding.rs:53:33:
attempt to add with overflow
Running: crash-d33.pdf
thread '<unnamed>' panicked at /tmp/pdf/pdf/src/crypt.rs:560:26:
source slice length (16) does not match destination slice length (17)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread '<unnamed>' panicked at /tmp/pdf/pdf/src/parser/parse_xref.rs:55:19:
attempt to shift left with overflow
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread '<unnamed>' panicked at /tmp/pdf/pdf/src/file.rs:153:23:
index out of bounds: the len is 0 but the index is 0
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I believe I've run into a similar issue, although I don't see the an example that panics in the same location as what I am experiencing so will paste it below:
thread 'tokio-runtime-worker' panicked at 'index out of bounds: the len is 1 but the index is 1', /Users/aaronleopold/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pdf-0.8.1/src/object/types.rs:925:54
Namely: src/object/types.rs:925:54
@aaronleopold could you try with the git version? I need to update the crates.io version..
@aaronleopold could you try with the git version? I need to update the crates.io version..
Hey 👋 thanks for responding so quickly! Unfortunately, it still panicked using the latest on main 53bebecaf62e5351b32ce1308ff5c0e7d6c219d1:
thread 'tokio-runtime-worker' panicked at 'index out of bounds: the len is 1 but the index is 1', /Users/aaronleopold/.cargo/git/checkouts/pdf-3ef1c528a9b91eec/53bebec/pdf/src/object/types.rs:1059:54
server:dev | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
It is fixed.
Something is odd with that file.
If you have some time, can you dbg!(&names) after the line
let names = names.resolve(resolve)?.into_array()?;
?
Or running the read.rs example on the file. That should print what gets loaded. I am interested in the last "load" message before it panics.
It is fixed.
Thank you! I confirmed locally the panic does not happen now
If you have some time, can you dbg!(&names)
[pdf/src/object/types.rs:1056] &names = [
String(
"iTextJS_0",
),
]
Or running the read.rs example on the file. That should print what gets loaded. I am interested in the last "load" message before it panics.
I ran it against the code with the fix (attached to this comment) but can re-run it with the previous commit if that is helpful.
Thank you, that is all I need. Now I just need to make sense of it.
From PDF32000, 7.9.6. Table 36
Names
(Root and leaf nodes only; required in leaf nodes; present in the root node if and only if Kids is not present) Shall be an array of the form [ key1 value1 key2 value2 ... keyn valuen ] where each keyi shall be a string and the corresponding valuei shall be the object associated with that key. The keys shall be sorted in lexical order, as described below.
So I think I will just ignore it as is, because the spec does not mention how it should be decoded.