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
uri.c uri_parse, in the path %xx decode loop:
if (hex2nibble(next[1]) <= 15 && hex2nibble(next[2]) <= 15) {
*p++ = hex2nibble(next[1]) << 4 | hex2nibble(next[2]);
...
} else {
*p++ = *next;
...
}
next points to a '%' returned by memchr inside the path segment. When
that '%' is the last byte of the URI, next[1] reads uri[len]; if it
is a hex digit, next[2] reads uri[len+1]. The short-circuit on next[1]
prevents next[2] from being read only when uri[len] is itself not a
hex digit.
For OSC 7 (osc.c:462), uri is the OSC buffer, which action_osc_end
explicitly null-terminates (vt.c:612). uri[len] = '0円' makes the
short-circuit fire, so the bug is not reachable there.
For selection.c:2150 (fdm_receive_finish_uri, the final URI in a
clipboard text/uri-list payload), uri is ctx->buf.data and len is
ctx->buf.idx. selection.c:2114-2121 grows ctx->buf with xrealloc and
memcpy without writing a terminator. uri[len] is therefore uninitialised
heap memory or, when idx == sz, one byte past the allocation. When
uri[len] happens to be a hex character (about 22/256 chance from
uninitialised data), the decoder then reads uri[len+1], appends the
decoded byte to path, and pastes it into the slave.
Reproduce: as a Wayland clipboard provider, advertise text/uri-list
data ending in something like "file:///x%" with no trailing CR or LF,
then have the foot user paste from clipboard. The OOB read fires when
foot processes the final URI.
Fix: in the decode loop, only read next[1] and next[2] when they are
within [encoded, encoded + encoded_len). Equivalent: require
encoded_len >= 3 before treating it as a %xx escape, otherwise emit a
literal '%' and advance by one.
Relevant logs, stacktraces, etc.
No response