Uploaded image for project: 'Kudu'
  1. Kudu
  2. KUDU-347

ReceiveFramedMessageBlocking can allocate huge memory in case of network corruption or naughty client

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • M4
    • None
    • rpc
    • None

    Description

      This function calls BlockingRecv, but then doesn't check the received length before loading a 32-bit int from the receive buffer. This means we have two issues:
      a) we may interpret uninitialized memory as an int and try to allocate up to 4GB, if the sender actually disconnected rather than sending the full length prefix
      b) with corruption we'd receive a huge message

      We should subject the length to the configured max rpc message size before resizing the frame buffer

      Attachments

        Activity

          People

            andrew.wang Andrew Wang
            tlipcon Todd Lipcon
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: