A kitty placement with a large `r=`, `c=` or `s=` panics the emulator (u32 overflow)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 85/100
Research direction
Start with kitty_cells in crates/termlens/src/graphics.rs around lines 1293–1307, where the issue identifies overflowing additions and multiplications. Add tests for u32::MAX in each of c, r, s, and v; the issue is done when none of these inputs panic or wrap.
Written by the indexing model from the issue text.
Description
What happens. With .graphics(Graphics::Kitty) and a cell_size declared, the setup #588 added, a placement size chosen by the program under test overflows u32 and kills the reader thread in a debug build:
Terminal::builder().size(40, 10).cell_size(10, 20).graphics(Graphics::Kitty)
.args(["-c", r"printf '\033_Ga=T,f=24,s=1,v=1,r=4294967295;AAAA\033\\'; printf after; sleep 2"])
.spawn("sh")?
thread 'termlens-pty-reader' panicked at crates/termlens/src/graphics.rs:1297:36: attempt to multiply with overflow
the terminal emulator failed and the screen stopped advancing: attempt to multiply with overflow
| key | panic |
|---|---|
c=4294967295 |
:1307:35 (multiply) |
s=4294967295,v=1,X=5 |
:1293:13 (add) |
In a release build the arithmetic wraps and the cursor moves by a nonsense amount.
Cause. kitty_cells (graphics.rs:1293-1307) computes src_w + offset_x, cell_h * rows, src_h + offset_y and cell_w * cols in u32.
Why it matters. Every number in a payload is chosen by the program under test. No input should be able to kill the emulator.
Fix. Do the arithmetic in u64 (or f64) and saturate on the way back, or use saturating_mul/saturating_add.
Done when u32::MAX in each of c, r, s and v neither panics nor wraps, with a test per key.
- Dominant language
- Rust
- Stars
- 28
- Forks
- 24
- Avg merge
- 11h 23m
- Merged PRs (30d)
- 42
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from vyncint/termlens
-
documentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
documentation good first issue
Difficulty 1/5 Under an hour Newbie friendliness 95/100
Maintainers usually reply within 1 day
-
Release notes show a broken link: `extract-changelog.sh` copies a reference but not its definitionOpenbug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
All issues in vyncint/termlens
Similar issues
-
good first issue help wanted r-docs
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
servo/rust-smallvec#824 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day
-
priority middle
Difficulty 1/5 Under an hour Newbie friendliness 62/100
KATO-Hiro/AtCoderClans#12940 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day
-
o8 next debug build aborts on Glass to Dark appearance switch (nil identifier messaged before check)Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
hurttlocker/o8#5112 ·