Foot Version
foot 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
The DECCRA handler in csi.c (case 'v', CSI ... $ v) computes:
int dst_left = vt_param_get(term, 6, 1) - 1; // not clamped
int dst_right = min(dst_left + (src_right - src_left), term->cols - 1);
const size_t cell_count = min(src_right - src_left,
dst_right - dst_left) + 1;
...
copy[r] = xmalloc(cell_count * sizeof(copy[r][0]));
...
struct cell *cell = &row->cells[dst_left];
memcpy(cell, copy[r], cell_count * sizeof(copy[r][0]));
The source rect is clamped via params_to_rectangular_area() and
dst_right is clamped to cols-1, but dst_left itself is never clamped.
If the parameter makes dst_left >= cols, dst_right - dst_left is
negative; cell_count is then computed as a non-positive int and
converted to size_t, becoming near SIZE_MAX. xmalloc gets a
SIZE_MAX-class request, fails, and aborts via the fatal-error path.
&row->cells[dst_left] is also out of bounds.
The sibling rectangular ops DECFRA ('x'), DECERA ('z') and DECSERA
('{') all route their rectangle through params_to_rectangular_area()
and are fine; DECCRA is the only one that takes dst_left straight from
a parameter.
DECCRA is unconditionally enabled (no tweak/security flag). Any byte
stream the parser reads can trigger this - terminal output, an SSH
banner, cat of a crafted file, output of a network tool, etc. One
escape sequence kills foot (and every program running in that window).
Reproduce (default grid is wider than 80; any param 6 value > cols+1
works):
printf '033円[1;1;1;1;1;1;300;1$v'
Fix: clamp dst_left to [0, term->cols - 1] (and reject the sequence if
the destination column is outside the grid), the same way
params_to_rectangular_area() clamps the source. Additionally, validate
row_count and cell_count as signed before converting to size_t so a
negative value cannot become a huge allocation.
Relevant logs, stacktraces, etc.
Debug log (full real VT pipeline,
fdm_ptmx -> vt_from_slave -> csi_dispatch):
src(t=0,l=0,b=0,r=0) dst_left=299 dst_right=134 row_count=1
cell_count=18446744073709551452 cols=135
==ERROR== requested allocation size 0xfffffffffffff850 exceeds maximum
#1 xmalloc
#2 csi_dispatch
#3 vt_from_slave
#4 fdm_ptmx