From 236c7918cb7bfd3781aeeba8df40f3ca4467065c Mon Sep 17 00:00:00 2001 From: sgtatham Date: Thu, 25 Apr 2019 09:54:10 +0100 Subject: [PATCH] xf_cliprdr: detect null terminators more reliably. (#5353) Clipboard formats containing plain text are specified to be terminated by a \0 character in MS's documentation on standard clipboard formats: https://docs.microsoft.com/en-us/windows/desktop/dataxchg/standard-clipboard-formats xf_cliprdr_server_format_data_response receives pasted data from the server to transfer to the client, in a sufficiently raw form that the \0 terminator is still present, so it has to remove it. It does so by checking only at the very end of the data. But I've observed that when pasting out of at least one Windows program (namely Outlook 1903 on Windows 10), the intended paste data arrives in this function followed by \0 and then a spurious \n. In that situation the null-terminator removal will fail to notice the \0, and will leave both bogus characters on the end of the paste. Fixed by using memchr to find the _first_ \0 in the paste data, which should not lose any actually intentional data because it's in accordance with the spec above. --- client/X11/xf_cliprdr.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/client/X11/xf_cliprdr.c b/client/X11/xf_cliprdr.c index e9f91e4..b6fc52e 100644 --- a/client/X11/xf_cliprdr.c +++ b/client/X11/xf_cliprdr.c @@ -1444,8 +1444,9 @@ static UINT xf_cliprdr_server_format_data_response(CliprdrClientContext* if (nullTerminated) { - while (DstSize > 0 && pDstData[DstSize - 1] == '\0') - DstSize--; + BYTE* nullTerminator = memchr(pDstData, '\0', DstSize); + if (nullTerminator) + DstSize = nullTerminator - pDstData; } } -- 2.7.4