simon-git: putty (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  150089ac Fix bit rot in TERM_CC_DIAGS ifdef.
  9ea0dfd8 Fix memory corruption in scrollback compression.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2020-10-27 18:42:58

commit 150089ac169d660de748b58486d2d4775154c9a7
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=150089ac169d660de748b58486d2d4775154c9a7;hp=65383082bf0c49cec63f4b36001a40bd9b13edf6
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Oct 27 18:15:12 2020 +0000

    Fix bit rot in TERM_CC_DIAGS ifdef.
    
    This is a piece of conditioned-out code that I haven't used since I
    originally invented the compressed scrollback format, which
    decompressed every scrollback line immediately after compressing it to
    check that the round-trip conversion worked. Now I have occasion to
    actually use it, I find that (of course) changes around it have made
    it not quite work any more: the thing the diagnostic code is passing
    to decompressline hasn't had its length field filled in yet, because
    that gets done 20 lines later.
    
    Now you can compile with -DTERM_CC_DIAGS again, and it doesn't crash
    _unless_ it detects the actual bug it was intended to spot.

 terminal.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

commit 9ea0dfd8c0615a634c410520b3b1096a3908dfef
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=9ea0dfd8c0615a634c410520b3b1096a3908dfef;hp=150089ac169d660de748b58486d2d4775154c9a7
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Oct 27 18:26:06 2020 +0000

    Fix memory corruption in scrollback compression.
    
    Introduced by commit 5891142aee5c, in which I invented
    strbuf_shrink_to() and went round replacing lots of assignments of the
    form 'sb->len = smaller_value' with calls to it. The bug is also in
    0.74, because 34a0460f0561 is a cherry-pick of the commit that
    introduced it.
    
    The difference between that assignment and strbuf_shrink_to is partly
    that the latter checks by assertion that the new length really is
    _smaller_ - it doesn't let you accidentally grow a strbuf's length
    field beyond the limit of its buffer (or indeed at all). But also,
    strbuf_shrink_to re-establishes the strbuf invariant that the text
    logically in the buffer is always followed by a zero byte, so that
    it's a valid C string.
    
    Unfortunately, in one of the places I made this change, I was storing
    binary data in the strbuf (so the terminating NUL is unimportant), and
    immediately after decreasing the strbuf's length, I was doing a memcmp
    one of whose arguments was the data I'd just chopped off the end of
    the strbuf. So it _mattered_ that no random NUL had been splurged over
    it.
    
    Specifically, this happened in the run-length encoder used to compress
    scrollback data, and had the effect that two components of the
    compressed scrollback could be spuriously considered equal, if one of
    them started with a legitimate zero byte and the other had a zero byte
    written over it by this bug. Thanks to Michael Weller for a nice test
    case that demonstrated a compressed scrollback line being decompressed
    again as the wrong thing:
    
    "NORMAL TEXT, \033[42mGREEN BACKGROUND\033[0m, NORMAL TEXT AGAIN"
    
    If the above line is printed to the terminal (after being decoded as
    if it was a C string literal), then only the words "GREEN BACKGROUND"
    get a green background. But after that line is scrolled off the top of
    the window, if you find it in the scrollback, then the rest of the
    line to the right has also become green-backgrounded due to this bug.

 terminal.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)