[dpdk-dev] [Bug 656] CVE-YYYY-NNNN State: Report

[bugzilla at dpdk.org]

https://bugs.dpdk.org/show_bug.cgi?id=656

            Bug ID: 656
           Summary: CVE-YYYY-NNNN State: Report
           Product: DPDK
           Version: 20.11
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: High
         Component: vhost/virtio
          Assignee: dev at dpdk.org
          Reporter: ferruh.yigit at intel.com
                CC: ferruh.yigit at intel.com, maxime.coquelin at redhat.com,
                    security at dpdk.org, stephen at networkplumber.org,
                    thomas at monjalon.net
  Target Milestone: ---
             Group: security

Report From: dsfasd daf <coolboy43433 at gmail.com>
Report Date: Thu, 11 Mar 2021 10:24:24 +0000

Report:

Dear maintainers,

I’m writing this email to report a security issue. 

Description:
Vhost-user allocates temporary file descriptors when receiving multiple
vhost-user messages. 
However, in some situations where the content of message is abnormal, the file
descriptor resources are not cleaned up sometimes.
Malicious containers can send endless messages with wrong content to drain out
of the file descriptors.

Evidence:
For example, in vhost_user_set_mem_table() function, if malicious guest sends
the memory table message indicating memory regions exceed the max number, error
will be returned without fd clean-up.

if (memory->nregions > VHOST_MEMORY_MAX_NREGIONS) {
               VHOST_LOG_CONFIG(ERR,
                              "too many memory regions (%u)\n",
memory->nregions);
               return RTE_VHOST_MSG_RESULT_ERR;
}

This issue touches many places that returns ‘RTE_VHOST_MSG_RESULT_ERR’ but does
not clean up fd resources.
After checking, the target functions are vhost_user_set_mem_table(), and
vhost_user_set_log_base().

Fix:
I also prepared the fixed patch, just add close_msg_fds at these location.

Could you help to evaluate if this issue can be qualified as a security
vulnerability? So that it can enter the CVE progress.
Thank you very much.

Best regards,
Xuan(Xarvier)

-- 
You are receiving this mail because:
You are the assignee for the bug.