Uploaded image for project: 'CFEngine Community'
  1. CFEngine Community
  2. CFE-2786

old cf-agent segfaults when trying to communicate with newer server using protocol_version = 1

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open
    • Priority: Medium
    • Resolution: Unresolved
    • Affects Version/s: 3.10.0, 3.10.1, 3.10.2, 3.10.3
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Environment:
      Debian 9.x with openssl 1.1

      Description

      I am trying to plan a full migration of our servers from 3.6 and 3.8 instances to all 3.10.x instances, but i had problems using 3.10 server and these old client instances so I am trying to force protocol_version = 1 for all clients before update all of them to the same version, but when i force protocol_version = 1 our Debian 9 boxes cant execute the cf-agent , it allways get segfault when tries to connect on the cf-serverd instances , but when i disable the protocol_version the problem does not happens , the other old instances i can communicate with the server without problems (with protocol_version => 1) , there is something happening in the beggining of the communication between client and server only with legacy protocol that triggers this problem

       

      I ran valgrind to get the stack of the problem:

       

       

      ==3472== Memcheck, a memory error detector
      ==3472== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
      ==3472== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
      ==3472== Command: cf-agent -KI
      ==3472==
      ==3472== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
      ==3472==    at 0x682D5BD: send (send.c:26)
      ==3472==    by 0x4ED865C: SendSocketStream (classic.c:146)
      ==3472==    by 0x4ED9696: SendTransaction (net.c:88)
      ==3472==    by 0x4ED650A: AuthenticateAgent (client_protocol.c:287)
      ==3472==    by 0x4ED71B4: ServerConnection (client_code.c:251)
      ==3472==    by 0x120C9C: FileCopyConnectionOpen (verify_files_utils.c:2774)
      ==3472==    by 0x120C9C: ScheduleCopyOperation (verify_files_utils.c:2852)
      ==3472==    by 0x118542: VerifyFilePromise (verify_files.c:454)
      ==3472==    by 0x118A3E: FindFilePromiserObjects (verify_files.c:802)
      ==3472==    by 0x118A3E: FindAndVerifyFilesPromises (verify_files.c:786)
      ==3472==    by 0x114A2C: ParallelFindAndVerifyFilesPromises (cf-agent.c:1843)
      ==3472==    by 0x114A2C: KeepAgentPromise (cf-agent.c:1614)
      ==3472==    by 0x4E9C11B: ExpandPromiseAndDo (expand.c:215)
      ==3472==    by 0x4E9C11B: ExpandPromise (expand.c:283)
      ==3472==    by 0x115D5C: ScheduleAgentOperations (cf-agent.c:1328)
      ==3472==    by 0x113C09: KeepPromiseBundles (cf-agent.c:1242)
      ==3472==    by 0x113C09: KeepPromises (cf-agent.c:723)
      ==3472==    by 0x113C09: main (cf-agent.c:252)
      ==3472==  Address 0xffeff7ff9 is on thread 1's stack
      ==3472==  in frame #2, created by SendTransaction (net.c:55)

       

      ==3472== Invalid read of size 1
      ==3472==    at 0x4C301C8: memcpy@GLIBC_2.2.5 (vg_replace_strmem.c:1017)
      ==3472==    by 0x599044F: RSA_padding_add_PKCS1_type_2 (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1)
      ==3472==    by 0x598F586: ??? (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1)
      ==3472==    by 0x4ED6798: AuthenticateAgent (client_protocol.c:491)
      ==3472==    by 0x4ED71B4: ServerConnection (client_code.c:251)
      ==3472==    by 0x120C9C: FileCopyConnectionOpen (verify_files_utils.c:2774)
      ==3472==    by 0x120C9C: ScheduleCopyOperation (verify_files_utils.c:2852)
      ==3472==    by 0x118542: VerifyFilePromise (verify_files.c:454)
      ==3472==    by 0x118A3E: FindFilePromiserObjects (verify_files.c:802)
      ==3472==    by 0x118A3E: FindAndVerifyFilesPromises (verify_files.c:786)
      ==3472==    by 0x114A2C: ParallelFindAndVerifyFilesPromises (cf-agent.c:1843)
      ==3472==    by 0x114A2C: KeepAgentPromise (cf-agent.c:1614)
      ==3472==    by 0x4E9C11B: ExpandPromiseAndDo (expand.c:215)
      ==3472==    by 0x4E9C11B: ExpandPromise (expand.c:283)
      ==3472==    by 0x115D5C: ScheduleAgentOperations (cf-agent.c:1328)
      ==3472==    by 0x113C09: KeepPromiseBundles (cf-agent.c:1242)
      ==3472==    by 0x113C09: KeepPromises (cf-agent.c:723)
      ==3472==    by 0x113C09: main (cf-agent.c:252)
      ==3472==  Address 0xffffffffffffffff is not stack'd, malloc'd or (recently) free'd

       

      ==3472== Process terminating with default action of signal 11 (SIGSEGV)
      ==3472==  Access not within mapped region at address 0xFFFFFFFFFFFFFFFF
      ==3472==    at 0x4C301C8: memcpy@GLIBC_2.2.5 (vg_replace_strmem.c:1017)
      ==3472==    by 0x599044F: RSA_padding_add_PKCS1_type_2 (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1)
      ==3472==    by 0x598F586: ??? (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1)
      ==3472==    by 0x4ED6798: AuthenticateAgent (client_protocol.c:491)
      ==3472==    by 0x4ED71B4: ServerConnection (client_code.c:251)
      ==3472==    by 0x120C9C: FileCopyConnectionOpen (verify_files_utils.c:2774)
      ==3472==    by 0x120C9C: ScheduleCopyOperation (verify_files_utils.c:2852)
      ==3472==    by 0x118542: VerifyFilePromise (verify_files.c:454)
      ==3472==    by 0x118A3E: FindFilePromiserObjects (verify_files.c:802)
      ==3472==    by 0x118A3E: FindAndVerifyFilesPromises (verify_files.c:786)
      ==3472==    by 0x114A2C: ParallelFindAndVerifyFilesPromises (cf-agent.c:1843)
      ==3472==    by 0x114A2C: KeepAgentPromise (cf-agent.c:1614)
      ==3472==    by 0x4E9C11B: ExpandPromiseAndDo (expand.c:215)
      ==3472==    by 0x4E9C11B: ExpandPromise (expand.c:283)
      ==3472==    by 0x115D5C: ScheduleAgentOperations (cf-agent.c:1328)
      ==3472==    by 0x113C09: KeepPromiseBundles (cf-agent.c:1242)
      ==3472==    by 0x113C09: KeepPromises (cf-agent.c:723)
      ==3472==    by 0x113C09: main (cf-agent.c:252)
      ==3472==  If you believe this happened as a result of a stack
      ==3472==  overflow in your program's main thread (unlikely but
      ==3472==  possible), you can try to increase the size of the
      ==3472==  main thread stack using the --main-stacksize= flag.
      ==3472==  The main thread stack size used in this run was 8388608.
      ==3472==
      ==3472== HEAP SUMMARY:
      ==3472==     in use at exit: 3,637,882 bytes in 95,818 blocks
      ==3472==   total heap usage: 2,817,988 allocs, 2,722,170 frees, 592,059,528 bytes allocated

        Attachments

          Activity

            People

            • Assignee:
              Aleksei Aleksei Shpakovskii
              Reporter:
              andreferraz Andre Ferraz
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Summary Panel