index out of ranges and assertion failures

[tokatoka]

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

pdf/pdf/src/enc.rs

Line 501 in 677152f

out[..bpp].copy_from_slice(&inp[..bpp]);

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

pdf/pdf/src/crypt.rs

Line 37 in 677152f

assert!(!key.is_empty() && key.len() <= 256);

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

pdf/pdf/src/crypt.rs

Line 562 in 677152f

key[..n].copy_from_slice(self.key());

[tokatoka]

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.

crash-201.pdf

Running: crash-201.pdf
thread '<unnamed>' panicked at /tmp/pdf/pdf/src/encoding.rs:53:33:
attempt to add with overflow

crash-d33.pdf

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

crash-ecf.pdf

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

crash-f2b.pdf

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

[aaronleopold]

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

[s3bk]

@aaronleopold could you try with the git version?
I need to update the crates.io version..

[aaronleopold]

@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

[s3bk]

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()?;
?

[s3bk]

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.

[aaronleopold]

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.

debug.txt

[s3bk]

Thank you, that is all I need. Now I just need to make sense of it.

[s3bk]

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.