Skip to content

date: cap format width to i32::MAX to prevent OOM#11377

Draft
sylvestre wants to merge 1 commit intouutils:mainfrom
sylvestre:fuzz_date
Draft

date: cap format width to i32::MAX to prevent OOM#11377
sylvestre wants to merge 1 commit intouutils:mainfrom
sylvestre:fuzz_date

Conversation

@sylvestre
Copy link
Contributor

@sylvestre sylvestre commented Mar 17, 2026

found by the fuzzer

@github-actions
Copy link

GNU testsuite comparison:

Skip an intermittent issue tests/date/date-locale-hour (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/pr/bounded-memory (fails in this run but passes in the 'main' branch)
Congrats! The gnu test tests/misc/io-errors is no longer failing!

@github-actions
Copy link

GNU testsuite comparison:

GNU test failed: tests/date/date. tests/date/date is passing on 'main'. Maybe you have to rebase?
Skip an intermittent issue tests/date/date-locale-hour (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/tty/tty-eof (passes in this run but fails in the 'main' branch)
Congrats! The gnu test tests/misc/io-errors is no longer failing!
Note: The gnu test tests/pr/bounded-memory is now being skipped but was previously passing.
Note: The gnu test tests/seq/seq-epipe is now being skipped but was previously passing.

// GNU date appears to cap output at around 1000 characters,
// so we'll use a similar limit.
const MAX_WIDTH: usize = 1000;
let width: usize = width_str.parse::<usize>().unwrap_or(0).min(MAX_WIDTH);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused by this claim:

$ date -d 2024-01-01 "+r++%++8888888888r+%" | wc -c
8888888894
$ ./target/debug/date -d 2024-01-01 "+r++%++8888888888r+%" | wc -c
1006

Copy link
Contributor

@xtqqczze xtqqczze Mar 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GNU date limit is about i64::MAX - 3, and it errors instead of capping output:

$ date --version
date (GNU coreutils) 9.10
$ date -d 2024-01-01 "+r++%++9223372036854775805r+%"
r++gdate: fprintftime error: Result too large

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please don't share links to GNU's projects. The licenses are not compatible.

@xtqqczze
Copy link
Contributor

Should we just error instead of capping width?

@xtqqczze
Copy link
Contributor

There is still the issue that our implementation allocates too much memory for width of i32::MAX.

Since there is no reasonable use case anyway, we could cap or error at u16::MAX.

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