DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: "Wiles, Keith" <keith.wiles@intel.com>,
	"Lipiec, Herakliusz" <herakliusz.lipiec@intel.com>
Cc: dpdk-dev <dev@dpdk.org>,
	"rasland@mellanox.com" <rasland@mellanox.com>,
	"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2] net/tap: fix potential buffer overrun
Date: Mon, 29 Apr 2019 15:05:31 +0100	[thread overview]
Message-ID: <45415448-f01d-8b5d-b893-e1fb1f802fdf@intel.com> (raw)
Message-ID: <20190429140531.itWJzwMERPIhfxuh_xQe_3wMStS3jfZ1v6-Zd9jQ6PM@z> (raw)
In-Reply-To: <7E00796C-D91F-47C4-B957-8561FC26F0E5@intel.com>

On 29-Apr-19 2:58 PM, Wiles, Keith wrote:
> 
> 
>> On Apr 25, 2019, at 10:17 AM, Lipiec, Herakliusz <herakliusz.lipiec@intel.com> wrote:
>>
>> When secondary to primary process synchronization occours
>> there is no check for number of fds which could cause buffer overrun.
>>
>> Bugzilla ID: 252
>> Fixes: c9aa56edec8e ("net/tap: access primary process queues from secondary")
>> Cc: rasland@mellanox.com
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Herakliusz Lipiec <herakliusz.lipiec@intel.com>
>> ---
>> drivers/net/tap/rte_eth_tap.c | 13 +++++++++++--
>> 1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
>> index e9fda8cf6..4a2ef5ce7 100644
>> --- a/drivers/net/tap/rte_eth_tap.c
>> +++ b/drivers/net/tap/rte_eth_tap.c
>> @@ -2111,6 +2111,10 @@ tap_mp_attach_queues(const char *port_name, struct rte_eth_dev *dev)
>> 	TAP_LOG(DEBUG, "Received IPC reply for %s", reply_param->port_name);
>>
>> 	/* Attach the queues from received file descriptors */
>> +	if (reply_param->rxq_count + reply_param->txq_count != reply->num_fds) {
>> +		TAP_LOG(ERR, "Unexpected number of fds received");
>> +		return -1;
>> +	}
> 
> This check is reasonable, but why is this being done on the receive side and not checked on the send side. There may need to be a check for num_fds being zero or greater than 8 as that is the limit to the number of FDs that can be handle by the IPC.

It is done below on the send side as well. This check is for 
sanity-checking external input. It's a socket, so anything (with 
matching UID) can write to it.

-- 
Thanks,
Anatoly

  parent reply	other threads:[~2019-04-29 14:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-25 16:47 [dpdk-dev] [PATCH] " Herakliusz Lipiec
2019-04-25 16:47 ` Herakliusz Lipiec
2019-04-25 17:17 ` [dpdk-dev] [PATCH v2] " Herakliusz Lipiec
2019-04-25 17:17   ` Herakliusz Lipiec
2019-04-29 13:32   ` Burakov, Anatoly
2019-04-29 13:32     ` Burakov, Anatoly
2019-04-29 13:53   ` Ferruh Yigit
2019-04-29 13:53     ` Ferruh Yigit
2019-04-29 14:02     ` Burakov, Anatoly
2019-04-29 14:02       ` Burakov, Anatoly
2019-04-30 10:42       ` Ferruh Yigit
2019-04-30 10:42         ` Ferruh Yigit
2019-04-29 13:58   ` Wiles, Keith
2019-04-29 13:58     ` Wiles, Keith
2019-04-29 14:05     ` Burakov, Anatoly [this message]
2019-04-29 14:05       ` Burakov, Anatoly
2019-04-29 17:31 ` [dpdk-dev] [PATCH v3] " Herakliusz Lipiec
2019-04-29 17:31   ` Herakliusz Lipiec
2019-05-02 16:31   ` [dpdk-dev] [dpdk-stable] " Ferruh Yigit
2019-05-02 16:31     ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45415448-f01d-8b5d-b893-e1fb1f802fdf@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=herakliusz.lipiec@intel.com \
    --cc=keith.wiles@intel.com \
    --cc=rasland@mellanox.com \
    --cc=stable@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).