From fe7b892d8f49221ed9c102a27bfd2eeb7fe2b589 Mon Sep 17 00:00:00 2001 From: strager Date: Sat, 14 Jun 2025 22:44:05 -0400 Subject: [PATCH] Fixes #729: Ignore libvterm string with length -1 libvterm sometimes gives us a string fragment with length 1073741823 [1]. When this happens, we attempt to read 1073741823 bytes, overrunning the buffer and causing a segfault. Fix the crash by adding a check for -1. Because the number is not exactly -1 (because VTermStringFragment.len is a 30-bit bit field at least in my copy of libvterm), do some C trickery to get the -1 value for comparison. [1] This -1 length might be a bug in libvterm. I did not investigate further. --- vterm-module.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/vterm-module.c b/vterm-module.c index 2294ef4..cc0ef53 100644 --- a/vterm-module.c +++ b/vterm-module.c @@ -1149,6 +1149,12 @@ static VTermParserCallbacks parser_callbacks = { }; #else +#pragma clang diagnostic push +#pragma clang diagnostic ignored "-Wbitfield-constant-conversion" +/* -1 is represented as ~0 in the bit field. */ +static const size_t invalid_string_fragment_len = (VTermStringFragment){.len = (size_t)-1}.len; +#pragma clang diagnostic pop + static int osc_callback(int cmd, VTermStringFragment frag, void *user) { /* osc_callback (OSC = Operating System Command) */ @@ -1171,7 +1177,11 @@ static int osc_callback(int cmd, VTermStringFragment frag, void *user) { return 0; } - term->cmd_buffer = concat(term->cmd_buffer, frag.str, frag.len, true); + /* frag.len can be -1 (invalid) for sequences such as "\033];\033". https://github.com/akermu/emacs-libvterm/issues/729 */ + /* This might be a bug in libvterm. */ + if (frag.len != invalid_string_fragment_len) { + term->cmd_buffer = concat(term->cmd_buffer, frag.str, frag.len, true); + } if (frag.final) { handle_osc_cmd(term, cmd, term->cmd_buffer); free(term->cmd_buffer);