Skip to content

Fix an error in how cksum parses checksum files#11553

Draft
frenchua wants to merge 1 commit intouutils:mainfrom
frenchua:fix-cksum-tagged-format-parsing-error
Draft

Fix an error in how cksum parses checksum files#11553
frenchua wants to merge 1 commit intouutils:mainfrom
frenchua:fix-cksum-tagged-format-parsing-error

Conversation

@frenchua
Copy link
Copy Markdown

@frenchua frenchua commented Mar 30, 2026

EDIT: After investigating more, the parsing issues are actually different that what I am describing here: See #11553 (comment) for an actual explanation on why cksum is panicking.

When cksum (or sha256sum, etc...) is called with the -c option, and it attempts to parse cheksum files in the "tagged output format" and it encounters the string "((", it crashes due to an error in how it parses the checksum file. GNU coreutils, by contrast, correctly recognizes this line as a syntax error and ignores the line.

This is due to the following two lines of code in the parse_algo_based function in validate.rs:

let par_idx = rest.iter().position(|&b| b == b'(')?;
let sub_case = if rest[par_idx - 1] == b' ' {

If the checksum file contains two consecutive left parentheses, then par_idx is equal to zero and so rest[par_idx - 1] evaluates to rest[-1] which causes the program to crash.

I have added a check to make sure that par_idx is greater than zero because, In my view, the string '((' appearing in a checksum file should be considered a syntax error and the line ignored, just as it does in the GNU cksum/sha256sum program).

When cksum (or sha256sum, etc...) attempts to parse chekcusm files in
the "tagged output format" and it encounters the string "((", it
crashes due to an error in how it parses the checksum file. GNU
coreutils, by contrast, correctly recognizes this string as a syntax
error and ignores the line.
@frenchua frenchua marked this pull request as draft March 30, 2026 21:24
@frenchua frenchua marked this pull request as ready for review March 30, 2026 21:26
@github-actions
Copy link
Copy Markdown

GNU testsuite comparison:

Skip an intermittent issue tests/tty/tty-eof (fails in this run but passes in the 'main' branch)

@sylvestre
Copy link
Copy Markdown
Contributor

could you please add a test to make sure we don't regress in the future?
(and that demonstrate the failure you are talking about)
thanks

@frenchua frenchua marked this pull request as draft March 31, 2026 07:41
@frenchua
Copy link
Copy Markdown
Author

frenchua commented Apr 1, 2026

Ignore (most) of what I've written above. I've read through the code more and here's whats causing the program to panic when passed syntactically incorrect checksum files.

A good formatted checksum line is supposed to look something like this:

MD5(filename.txt) = fds65dsf46as5df4d6f54asds5d7f7g9

If the algorithm at the beginning is missing, you have a line like the following:

(filename.txt) = fds65dsf46as5df4d6f54asds5d7f7g9

The parser works by looking for the first ( character it finds. It then reads the algorithm by reading the portion of the array before the first (. But if the ( is the first line in the file (except for whitespace), it will attempt to evaluate the array containing the line at index -1 and panic.

This fix causes cksum to report this behavior as a syntax error and ignore the line like GNU does.

I will write up some unit tests in the test_algo_based_parser function in a little bit, unless you want me to write integration tests in test_cksum.rs as well. I'm new to rust development so I apologize if I'm getting anything wrong.

@RenjiSann
Copy link
Copy Markdown
Collaborator

I will write up some unit tests in the test_algo_based_parser function in a little bit, unless you want me to write integration tests in test_cksum.rs as well. I'm new to rust development so I apologize if I'm getting anything wrong.

Both is good :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants