All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hellermann <stefan@the2masters.de>
To: netdev@vger.kernel.org, adobriyan@gmail.com,
	andriy.shevchenko@linux.intel.com, andrew@lunn.ch,
	linux@arm.linux.org.uk, jason@lakedaemon.net, dv@vollmann.ch,
	gregory.clement@free-electrons.com,
	linux-arm-kernel@lists.infradead.org
Cc: Stefan Hellermann <stefan@the2masters.de>,
	"\[ 4 . 4+ \]" <stable@vger.kernel.org>
Subject: [PATCH] net: Allow mac_pton() to work on non-NULL terminated strings
Date: Fri, 23 Feb 2018 21:17:48 +0100	[thread overview]
Message-ID: <20180223201748.14328-1-stefan@the2masters.de> (raw)
In-Reply-To: <20180223182006.GA2116@avx2>

Commit 4904dbda41c8 ("ARM: orion5x: use mac_pton() helper") crashes my
QNAP TS-209 NAS early on boot.

The boot code for the TS-209 is looping through an ext2 filesystem on a
384kB mtd partition (factory configuration put there by QNAP). There it
looks on every 1kB boundary if there is a valid MAC address. The
filesystem has a 1kB block size, so this seems to work.

On my device the MAC address is on the 37th 1kB block. But: On the 27th
block is a large file (1,5kB) without 0 bytes inside. The code in
qnap_tsx09_find_mac_addr() maps 1kB into memory (not a whole file or the
whole 384kB) and then calls qnap_tsx09_check_mac_addr() -> mac_pton() ->
strlen() on this memory block. as there is no 0 byte in the file on the
27th block, strlen() runs into bad memory and the machine panics. The old
code had no strlen().

Actually mac_pton() doesn't need to call strlen(), the following loop
catches short strings quite nicely. The strlen() seems to be an
optimization for calls to mac_pton with empty string. But this is rarely
the case and this is not a hot path. Remove it to reduce code size and
speed up calls with an not empty string.

Besides fixing the crash there is are other users interested in
this change, see https://patchwork.ozlabs.org/patch/851008/

Fixes: 4904dbda41c8 ("ARM: orion5x: use mac_pton() helper")
Signed-off-by: Stefan Hellermann <stefan@the2masters.de>
Cc: <stable@vger.kernel.org> [4.4+]
---
 lib/net_utils.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/lib/net_utils.c b/lib/net_utils.c
index af525353395d..9d38da67ee44 100644
--- a/lib/net_utils.c
+++ b/lib/net_utils.c
@@ -8,10 +8,6 @@ bool mac_pton(const char *s, u8 *mac)
 {
 	int i;
 
-	/* XX:XX:XX:XX:XX:XX */
-	if (strlen(s) < 3 * ETH_ALEN - 1)
-		return false;
-
 	/* Don't dirty result unless string is valid MAC. */
 	for (i = 0; i < ETH_ALEN; i++) {
 		if (!isxdigit(s[i * 3]) || !isxdigit(s[i * 3 + 1]))
-- 
2.11.0

WARNING: multiple messages have this Message-ID (diff)
From: Stefan Hellermann <stefan@the2masters.de>
To: netdev@vger.kernel.org, adobriyan@gmail.com,
	andriy.shevchenko@linux.intel.com, andrew@lunn.ch,
	linux@arm.linux.org.uk, jason@lakedaemon.net, dv@vollmann.ch,
	gregory.clement@free-electrons.com,
	linux-arm-kernel@lists.infradead.org
Cc: Stefan Hellermann <stefan@the2masters.de>,
	"[ 4 . 4+ ]" <stable@vger.kernel.org>
Subject: [PATCH] net: Allow mac_pton() to work on non-NULL terminated strings
Date: Fri, 23 Feb 2018 21:17:48 +0100	[thread overview]
Message-ID: <20180223201748.14328-1-stefan@the2masters.de> (raw)
In-Reply-To: <20180223182006.GA2116@avx2>

Commit 4904dbda41c8 ("ARM: orion5x: use mac_pton() helper") crashes my
QNAP TS-209 NAS early on boot.

The boot code for the TS-209 is looping through an ext2 filesystem on a
384kB mtd partition (factory configuration put there by QNAP). There it
looks on every 1kB boundary if there is a valid MAC address. The
filesystem has a 1kB block size, so this seems to work.

On my device the MAC address is on the 37th 1kB block. But: On the 27th
block is a large file (1,5kB) without 0 bytes inside. The code in
qnap_tsx09_find_mac_addr() maps 1kB into memory (not a whole file or the
whole 384kB) and then calls qnap_tsx09_check_mac_addr() -> mac_pton() ->
strlen() on this memory block. as there is no 0 byte in the file on the
27th block, strlen() runs into bad memory and the machine panics. The old
code had no strlen().

Actually mac_pton() doesn't need to call strlen(), the following loop
catches short strings quite nicely. The strlen() seems to be an
optimization for calls to mac_pton with empty string. But this is rarely
the case and this is not a hot path. Remove it to reduce code size and
speed up calls with an not empty string.

Besides fixing the crash there is are other users interested in
this change, see https://patchwork.ozlabs.org/patch/851008/

Fixes: 4904dbda41c8 ("ARM: orion5x: use mac_pton() helper")
Signed-off-by: Stefan Hellermann <stefan@the2masters.de>
Cc: <stable@vger.kernel.org> [4.4+]
---
 lib/net_utils.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/lib/net_utils.c b/lib/net_utils.c
index af525353395d..9d38da67ee44 100644
--- a/lib/net_utils.c
+++ b/lib/net_utils.c
@@ -8,10 +8,6 @@ bool mac_pton(const char *s, u8 *mac)
 {
 	int i;
 
-	/* XX:XX:XX:XX:XX:XX */
-	if (strlen(s) < 3 * ETH_ALEN - 1)
-		return false;
-
 	/* Don't dirty result unless string is valid MAC. */
 	for (i = 0; i < ETH_ALEN; i++) {
 		if (!isxdigit(s[i * 3]) || !isxdigit(s[i * 3 + 1]))
-- 
2.11.0

WARNING: multiple messages have this Message-ID (diff)
From: stefan@the2masters.de (Stefan Hellermann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] net: Allow mac_pton() to work on non-NULL terminated strings
Date: Fri, 23 Feb 2018 21:17:48 +0100	[thread overview]
Message-ID: <20180223201748.14328-1-stefan@the2masters.de> (raw)
In-Reply-To: <20180223182006.GA2116@avx2>

Commit 4904dbda41c8 ("ARM: orion5x: use mac_pton() helper") crashes my
QNAP TS-209 NAS early on boot.

The boot code for the TS-209 is looping through an ext2 filesystem on a
384kB mtd partition (factory configuration put there by QNAP). There it
looks on every 1kB boundary if there is a valid MAC address. The
filesystem has a 1kB block size, so this seems to work.

On my device the MAC address is on the 37th 1kB block. But: On the 27th
block is a large file (1,5kB) without 0 bytes inside. The code in
qnap_tsx09_find_mac_addr() maps 1kB into memory (not a whole file or the
whole 384kB) and then calls qnap_tsx09_check_mac_addr() -> mac_pton() ->
strlen() on this memory block. as there is no 0 byte in the file on the
27th block, strlen() runs into bad memory and the machine panics. The old
code had no strlen().

Actually mac_pton() doesn't need to call strlen(), the following loop
catches short strings quite nicely. The strlen() seems to be an
optimization for calls to mac_pton with empty string. But this is rarely
the case and this is not a hot path. Remove it to reduce code size and
speed up calls with an not empty string.

Besides fixing the crash there is are other users interested in
this change, see https://patchwork.ozlabs.org/patch/851008/

Fixes: 4904dbda41c8 ("ARM: orion5x: use mac_pton() helper")
Signed-off-by: Stefan Hellermann <stefan@the2masters.de>
Cc: <stable@vger.kernel.org> [4.4+]
---
 lib/net_utils.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/lib/net_utils.c b/lib/net_utils.c
index af525353395d..9d38da67ee44 100644
--- a/lib/net_utils.c
+++ b/lib/net_utils.c
@@ -8,10 +8,6 @@ bool mac_pton(const char *s, u8 *mac)
 {
 	int i;
 
-	/* XX:XX:XX:XX:XX:XX */
-	if (strlen(s) < 3 * ETH_ALEN - 1)
-		return false;
-
 	/* Don't dirty result unless string is valid MAC. */
 	for (i = 0; i < ETH_ALEN; i++) {
 		if (!isxdigit(s[i * 3]) || !isxdigit(s[i * 3 + 1]))
-- 
2.11.0

  reply	other threads:[~2018-02-23 20:17 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-02 14:12 [PATCH v2 1/1] ARM: orion5x: use mac_pton() helper Andy Shevchenko
2015-10-13 11:27 ` Detlef Vollmann
2015-10-15  7:51   ` Gregory CLEMENT
2018-02-22 17:45 ` [v2,1/1] " Stefan Hellermann
2018-02-22 21:42   ` Andrew Lunn
2018-02-22 23:18     ` Stefan Hellermann
2018-02-22 23:34       ` Andrew Lunn
2018-02-23 10:09         ` Andy Shevchenko
2018-02-23 15:01           ` Andrew Lunn
2018-02-23 15:18             ` Andy Shevchenko
2018-02-23 15:51               ` Andrew Lunn
2018-02-23 16:36                 ` Stefan Hellermann
2018-02-23 16:57                   ` Andy Shevchenko
2018-02-23 17:23                   ` Andrew Lunn
2018-02-23 18:20               ` Alexey Dobriyan
2018-02-23 20:17                 ` Stefan Hellermann [this message]
2018-02-23 20:17                   ` [PATCH] net: Allow mac_pton() to work on non-NULL terminated strings Stefan Hellermann
2018-02-23 20:17                   ` Stefan Hellermann
2018-02-23 20:27                   ` Andrew Lunn
2018-02-23 20:27                     ` Andrew Lunn
2018-02-23 20:27                     ` Andrew Lunn
2018-02-23 20:41                   ` Alexey Dobriyan
2018-02-23 20:41                     ` Alexey Dobriyan
2018-02-23 20:41                     ` Alexey Dobriyan
2018-02-23 20:51                     ` Andy Shevchenko
2018-02-23 20:51                       ` Andy Shevchenko
2018-02-23 20:51                       ` Andy Shevchenko
2018-02-26 18:37                   ` David Miller
2018-02-26 18:37                     ` David Miller

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=20180223201748.14328-1-stefan@the2masters.de \
    --to=stefan@the2masters.de \
    --cc=adobriyan@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dv@vollmann.ch \
    --cc=gregory.clement@free-electrons.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@arm.linux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=stable@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.