From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 90CAEA00E6 for ; Wed, 10 Jul 2019 20:42:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 471013195; Wed, 10 Jul 2019 20:42:34 +0200 (CEST) Received: from mail-pf1-f195.google.com (mail-pf1-f195.google.com [209.85.210.195]) by dpdk.org (Postfix) with ESMTP id 70B312C60 for ; Wed, 10 Jul 2019 20:42:33 +0200 (CEST) Received: by mail-pf1-f195.google.com with SMTP id g2so1506789pfq.0 for ; Wed, 10 Jul 2019 11:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=QDsESulCbnwTiCb9fK/M3WZpV9RFHle/kmw03owqYSg=; b=p+L/nRWVd3kq4uMz0m2DCi3Zh94qEQM2IKJYgaW4jOi+jXF7H+i2Tujzn9K/KCBzJs A55n5FuaO5B2IY8l9HVmMkN8bi0ODIxUVLESAqZLoKxpH9++8tSxJGGEQeMrI8s8REDB yuPwEKLZWmvGDhM+XEz+rcYSYtgN/DkLOVpOr1JzRiov9e9OKGlXTokrnzc1GcHmBwMG m+uhI8dAP8T3TtnT8nynzhRFW7zyG9EmkMBQx7KVvvbsB4/4rDKBLqZ3Rxq2etnIJ9iw dNUbW6XR3vat+i1iGdz4yvDwh5xGmzGpTzYxkHvczthVLdJSOYQLEZ+2XNMjtdZGF1bM p4yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=QDsESulCbnwTiCb9fK/M3WZpV9RFHle/kmw03owqYSg=; b=nSvjBLMvchQQFaWA9Nm2sTQQ5PYK9vTwR/4H4j23H7+YP15fsv/jXbLastnKS34Oe0 ctxzBRWF9oEbZMWy5qIsxP8xYfgAZzTCGu/vR2gnUo8/td+bXL9m9cZNZWA1drz7lqYP 1K6xeNvLbm5z8RElVNw7rK7fQRgFDWaybWiBtDJjG7S4EQJm5C509z8haZDvo8WWrs53 rwBpMtVnMTjXF4znc1QDIhEZWh/mZamBDxJwCK05REWgf8hj611XuuB+zXz3ri7NA4OD yIbdi6zs4NRsVj99ABfxvyhbvIJcgr2f9jehMMx8WBY2VOXwAe3R2lQyDPL1KaCy6ta2 2buA== X-Gm-Message-State: APjAAAUDUa1TS9PkkdiFPIhbuCgz/bepZ9sR/Nq0mIxzXG8aXlB3SyTM 0GluvohdsQ3cWRec95lN9uUcrw== X-Google-Smtp-Source: APXvYqx7mjruTtWPQbm9W/YMSjZqdMahmyiCf2Gf5yqw33TyDXBd1+GLYZ+leTzXzhcnUPU4koy9+w== X-Received: by 2002:a65:4844:: with SMTP id i4mr39248306pgs.113.1562784152422; Wed, 10 Jul 2019 11:42:32 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id w14sm3151010pfn.47.2019.07.10.11.42.32 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 10 Jul 2019 11:42:32 -0700 (PDT) Date: Wed, 10 Jul 2019 11:42:30 -0700 From: Stephen Hemminger To: Aaron Conole Cc: dev@dpdk.org, Olivier Matz , Andrew Rybchenko , Ferruh Yigit Message-ID: <20190710114230.7c171c7a@hermes.lan> In-Reply-To: <20190710183342.6459-1-aconole@redhat.com> References: <20190710183342.6459-1-aconole@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] rte_ether: force format string for unformat_addr X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, 10 Jul 2019 14:33:42 -0400 Aaron Conole wrote: > rte_ether_unformation_addr is very lax in what it accepts now, including > ethernet addresses formatted ambiguously as "x:xx:x:xx:x:xx". However, > previously this behavior was enforced via the my_ether_aton which would > fail ambiguously formatted values. > > Reported-by: Michael Santana > Fixes: 596d31092d32 ("net: add function to convert string to ethernet address") > Signed-off-by: Aaron Conole > --- > lib/librte_net/rte_ether.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/lib/librte_net/rte_ether.c b/lib/librte_net/rte_ether.c > index 8d040173c..4f252b813 100644 > --- a/lib/librte_net/rte_ether.c > +++ b/lib/librte_net/rte_ether.c > @@ -45,7 +45,8 @@ rte_ether_unformat_addr(const char *s, struct rte_ether_addr *ea) > if (n == 6) { > /* Standard format XX:XX:XX:XX:XX:XX */ > if (o0 > UINT8_MAX || o1 > UINT8_MAX || o2 > UINT8_MAX || > - o3 > UINT8_MAX || o4 > UINT8_MAX || o5 > UINT8_MAX) { > + o3 > UINT8_MAX || o4 > UINT8_MAX || o5 > UINT8_MAX || > + strlen(s) != RTE_ETHER_ADDR_FMT_SIZE - 1) { > rte_errno = ERANGE; > return -1; > } > @@ -58,7 +59,8 @@ rte_ether_unformat_addr(const char *s, struct rte_ether_addr *ea) > ea->addr_bytes[5] = o5; > } else if (n == 3) { > /* Support the format XXXX:XXXX:XXXX */ > - if (o0 > UINT16_MAX || o1 > UINT16_MAX || o2 > UINT16_MAX) { > + if (o0 > UINT16_MAX || o1 > UINT16_MAX || o2 > UINT16_MAX || > + strlen(s) != RTE_ETHER_ADDR_FMT_SIZE - 4) { > rte_errno = ERANGE; > return -1; > } NAK Skipping leading zero should be ok. There is no need for this patch. The current behavior is superset of what standard ether_aton accepts.