Data loss: qpdf discards the character in a binary string following an octal quoted character with 1 or 2 digits
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Qpdf |
Fix Released
|
Unknown
|
|||
qpdf (Debian) |
Fix Released
|
Unknown
|
|||
qpdf (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Lunar |
Fix Released
|
High
|
Unassigned | ||
Mantic |
Fix Released
|
High
|
Unassigned |
Bug Description
Notes:
* I am the upstream author and debian maintainer for qpdf.
* This bug has been fixed in debian unstable and testing with version 11.6.3, but because 24.04 is not yet open, it has not synced. This should not block fixing 23.04 and 22.04. I have uploaded 11.6.3 to my ppa: https:/
* I am attaching debdiffs for lunar and mantic
Upstream bug https:/
I also reported this as a debian bug: https:/
It was approved as a stable update by debian: https:/
[ Impact ]
The bug could result in silent corruption of binary strings in PDF metadata. It could also result in failure of qpdf to process a valid file. Data loss justifies a stable update.
[ Test Plan ]
The test file in https:/
The upstream fix includes several additional automated test cases. These are not included in the patch, but they are included in the upstream commit that fixes the bug: https:/
How to test the SRU package on Ubuntu manually (copied from Jay's comment #6 below):
Running `qpdf --check 018.pdf` where `018.pdf` is the file attached to the upstream bug will reproduce the issue. With the current version in 22.04 and 23.04, you will see something like this:
```
WARNING: /tmp/z/018.pdf (xref stream: object 17 1, offset 110340): EOF while reading token
WARNING: /tmp/z/018.pdf (xref stream: object 17 1, offset 110830): unexpected EOF
WARNING: /tmp/z/018.pdf (xref stream: object 17 1, offset 110830): parse error while reading object
WARNING: /tmp/z/018.pdf (xref stream: object 17 1, offset 110830): expected endobj
WARNING: /tmp/z/018.pdf: file is damaged
WARNING: /tmp/z/018.pdf (offset 110267): xref not found
WARNING: /tmp/z/018.pdf: Attempting to reconstruct cross-reference table
qpdf: /tmp/z/018.pdf: unable to find trailer dictionary while recovering damaged file
```
After the fix, you will see
```
checking /home/ejb/
PDF Version: 1.7
File is not encrypted
File is not linearized
No syntax or stream encoding errors found; the file may still contain
errors that qpdf cannot detect
```
(obviously with the full paths based on whatever you call the file).
[ Where problems could occur ]
This fix has a very low risk of causing a regression. The fix is very localized to qpdf's lexical layer and is in a code path that only occurs when a 1-digit or 2-digit octal quoted character is terminated by other than an octal digit. This is the first bug in qpdf's lexical layer in many years. It was introduced by a pull request from a reliable and consistent contributor who has made may improvements to qpdf's performance. The fix follows the established pattern of how to handle instances in which a character triggers a state change and has to be reprocessed in the new state.
qpdf has a rigorous test suite and an extremely good quality record. It processes millions of documents daily by many commercial entities. My current employer runs millions of pages a day through qpdf.
[ Other Info ]
See also
Upstream bug report: https:/
Corresponding debian bug report: https:/
Debian stable release approval: https:/
Changed in qpdf (Ubuntu Lunar): | |
importance: | Undecided → High |
Changed in qpdf (Ubuntu Mantic): | |
importance: | Undecided → High |
Changed in qpdf: | |
status: | Unknown → Fix Released |
Changed in qpdf (Debian): | |
status: | Unknown → Confirmed |
summary: |
- SRU request: qpdf: data loss bug affecting versions 11.0.0 through - 11.6.2 + Data loss: qpdf discards the character in a binary string following an + octal quoted character with 1 or 2 digits |
Changed in qpdf (Debian): | |
status: | Confirmed → Fix Released |
I've gone as far as I think I can, but I can do additional steps if needed. I have not tagged this or uploaded anything anywhere. Please let me know if I can/should take any additional steps to get this approved and processed as an SRU.