Foot Version
1.27.0
TERM environment variable
foot
Compositor Name and Version
sway 1.11
Distribution
arch
Terminal multiplexer
No response
Shell, TUI, application
No response
Server/standalone mode
- Standalone
- Server
Foot config
default
Description of Bug and Steps to Reproduce
A program that writes to the terminal can crash foot or force a multi-
GB allocation with a single ~16-byte escape sequence:
printf '033円[2147483647#P' # aborts foot (xrealloc fails)
printf '033円[1000000#P' # ~1 GB allocation, multi-second hang
XTPUSHCOLORS takes a "slot" parameter and grows the color stack to
that size. vt_param_get returns up to 0x7fffffff, and the handler has
no clamp. Each slot is sizeof(struct colors) = 1056 bytes (256-entry
color table plus fg/bg/cursor/selection), so slot N costs N*1056 bytes
of allocation plus an N-iteration memcpy loop on the main event
thread.
csi.c case 'P' under private '#':
int slot = vt_param_get(term, 0, 0);
...
if (term->color_stack.size < slot) {
const size_t new_size = slot;
term->color_stack.stack = xrealloc(
term->color_stack.stack,
new_size * sizeof(term->color_stack.stack[0]));
...
for (size_t i = term->color_stack.size; i < new_size - 1; i++)
memcpy(&term->color_stack.stack[i], &term->colors,
sizeof(term->colors));
}
Same delivery model as the CHT/CBT issue.
xterm restricts this parameter to 1-10 per spec. foot has no bound.
Fix: cap slot to a small constant.
Relevant logs, stacktraces, etc.
No response
### Foot Version
1.27.0
### TERM environment variable
foot
### Compositor Name and Version
sway 1.11
### Distribution
arch
### Terminal multiplexer
_No response_
### Shell, TUI, application
_No response_
### Server/standalone mode
- [ ] Standalone
- [ ] Server
### Foot config
```ini
default
```
### Description of Bug and Steps to Reproduce
A program that writes to the terminal can crash foot or force a multi-
GB allocation with a single ~16-byte escape sequence:
printf '033円[2147483647#P' # aborts foot (xrealloc fails)
printf '033円[1000000#P' # ~1 GB allocation, multi-second hang
XTPUSHCOLORS takes a "slot" parameter and grows the color stack to
that size. vt_param_get returns up to 0x7fffffff, and the handler has
no clamp. Each slot is sizeof(struct colors) = 1056 bytes (256-entry
color table plus fg/bg/cursor/selection), so slot N costs N*1056 bytes
of allocation plus an N-iteration memcpy loop on the main event
thread.
csi.c case 'P' under private '#':
int slot = vt_param_get(term, 0, 0);
...
if (term->color_stack.size < slot) {
const size_t new_size = slot;
term->color_stack.stack = xrealloc(
term->color_stack.stack,
new_size * sizeof(term->color_stack.stack[0]));
...
for (size_t i = term->color_stack.size; i < new_size - 1; i++)
memcpy(&term->color_stack.stack[i], &term->colors,
sizeof(term->colors));
}
Same delivery model as the CHT/CBT issue.
xterm restricts this parameter to 1-10 per spec. foot has no bound.
Fix: cap slot to a small constant.
### Relevant logs, stacktraces, etc.
_No response_