diff: `-t --tabsize=<huge>` aborts in `do_expand_tabs`
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 65/100
Rechercherichtung
The bug is in src/utils.rs in the do_expand_tabs function. Start by reading the function to understand how tabsize is used in capacity calculations at lines 20 and 31. Look for where tabsize is parsed from the command line to see if bounds checking is missing. Write a test that reproduces the abort with large tabsize values, then add validation to limit tabsize to a safe maximum or handle allocation failures gracefully.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
--tabsize is parsed into a usize with no upper bound and then used to size an allocation: do_expand_tabs reserves line.len() + ntabs * (tabsize - 1) bytes or every line containing a tab. A large --tabsize makes that request exceed what the allocator can serve and the process aborts with no diff: diagnostic.
$ printf '\tx\n' > a; printf 'y\n' > b
$ diff -t --tabsize=18446744073709551615 a b > /dev/null
Aborted (core dumped)
$ echo $?
134
The threshold is the allocator, not a parse guard — the request scales directly
with the flag:
$ diff -t --tabsize=1000000000 a b # 1e9 -> exit 1, diffs normally
$ diff -t --tabsize=4611686018427387904 a b # 2^62
memory allocation of 4611686018427387905 bytes failed -> exit 134
$ diff -t --tabsize=9223372036854775807 a b # isize::MAX -> exit 134
A tab in the input is required — ntabs == 0 returns early.
Root cause
src/utils.rs:
pub fn do_expand_tabs(line: &[u8], tabsize: usize) -> Vec<u8> {
let tab = b'\t';
let ntabs = line.iter().filter(|c| **c == tab).count();
if ntabs == 0 {
return line.to_vec();
}
let mut result = Vec::with_capacity(line.len() + ntabs * (tabsize - 1)); // :20
let mut offset = 0;
let mut iter = line.split(|c| *c == tab).peekable();
while let Some(chunk) = iter.next() {
...
if iter.peek().is_some() {
result.resize(result.len() + tabsize - offset % tabsize, b' '); // :31
tabsize comes straight from --tabsize and multiplies the tab count. Nothing bounds it at parse time, so the capacity is attacker-chosen and the allocation aborts.
The same function aborts at a second site, src/utils.rs:31. Once the with_capacity at :20 is survived, the per-chunk result.resize(result.len() + tabsize - offset % tabsize, b' ') requests another attacker-sized allocation. Which of the two fires depends on the --tabsize value:
# :20 — capacity overflow (tabsize = 2^63)
$ diffutils diff -t --tabsize=9223372036854775808 a b
thread 'main' panicked at library/alloc/src/raw_vec/mod.rs:...: capacity overflow
$ echo $?
134
# :31 — allocation abort (tabsize = u64::MAX)
$ printf '\tx\n' > a; printf 'y\n' > b
$ diffutils diff -t --tabsize=18446744073709551615 a b
thread 'main' panicked at library/alloc/src/raw_vec/mod.rs:28:5:
$ echo $?
134
- Vorherrschende Sprache
- Rust
- Sterne
- 276
- Forks
- 39
- Ø Merge
- 4 T. 12 Std.
- Gemergte PRs (30 T.)
- 3
Entwicklungsumgebung
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus uutils/diffutils
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 85/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 45/100
Alle Issues in uutils/diffutils
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
arkworks-rs/algebra#1161 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 85/100
lbjlaq/Antigravity-Manager#3525 · 2 Kommentare · 1 Reaktion ·
Maintainer antworten meist innerhalb von 1 Tag
-
Registry Scheduling: startup logging goes to stdout, colliding with a stdout audit destinationOffenagent-ready area:platform bug criticality:p3 rust triage:needs-implementation
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
registrystack/registry-stack#1583 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
Maintainer antworten meist innerhalb von 1 Tag
-
Docs: "Work with Codex from anywhere" page still claims Windows mobile support is "coming soon"Offenapp documentation remote windows-os
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 88/100
Maintainer antworten meist innerhalb von 1 Tag