simon-git: putty (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  d6b1d3a Move null pointer checks to before FROMFIELD.
  d659507 Install ssh-connection packet handlers synchronously.

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:           2018-05-31 18:49:58

commit d6b1d3aef7a1ab5614a2f6411fab161704a5a60b
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=d6b1d3aef7a1ab5614a2f6411fab161704a5a60b;hp=d6208d9b0a4a583a63b42722796a80b194746ff9
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu May 31 18:32:09 2018 +0100

    Move null pointer checks to before FROMFIELD.
    
    This fixes an oversight in commit 0fc2d3b45: if a key creation
    function returns a null 'ssh_key *', then adjusting the pointer's
    address using FROMFIELD is a mistake, both in technical C terms
    (undefined behaviour) and practically speaking because it will foil
    the subsequent check against NULL. Instead, if we're going to check a
    pointer against NULL, we must do it _before_ applying this kind of
    address-adjusting type conversion.

 sshdss.c | 16 ++++++++++------
 sshecc.c | 23 ++++++++++++++---------
 sshrsa.c | 24 ++++++++++++++++--------
 3 files changed, 40 insertions(+), 23 deletions(-)

commit d659507d93da599281f6244c914eda9a52e2097b
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=d659507d93da599281f6244c914eda9a52e2097b;hp=d6b1d3aef7a1ab5614a2f6411fab161704a5a60b
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu May 31 18:42:47 2018 +0100

    Install ssh-connection packet handlers synchronously.
    
    I had a one-off 'Strange packet received' error yesterday for an
    SSH_MSG_GLOBAL_REQUEST at connection startup. I wasn't able to
    reproduce, but examining the packet logs from the successful retry
    suggested that the global request in question was an OpenSSH 'here are
    my hostkeys' message.
    
    My belief is that in the failing connection that request packet must
    have arrived exceptionally promptly, and been added to pq_full before
    the preceding SSH_MSG_USERAUTH_SUCCESS had been processed. So the code
    that loops along pq_full feeding everything to the dispatch table
    would have moved the USERAUTH_SUCCESS on to pq_ssh2_userauth and
    scheduled a callback to handle it, and then moved on to the
    GLOBAL_REQUEST which would have gone straight to the dispatch table
    handler for 'help, we weren't expecting this message'. The userauth
    callback would later on have installed a more sensible dispatch table
    handler for global requests, but by then, it was too late.
    
    Solution: make a special case during pq_full processing, so that when
    we see USERAUTH_SUCCESS we _immediately_ - before continuing to
    traverse pq_full - install the initial dispatch table entries for the
    ssh-connection protocol. That way, even if connection messages are
    already in the queue, we won't get confused by them.

 ssh.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++-------------------
 1 file changed, 55 insertions(+), 21 deletions(-)