linux-mips
[Top] [All Lists]

Re: [PATCH] MIPS: BCM63XX: properly handle mac address octet overflow

To: Sergei Shtylyov <sshtylyov@mvista.com>
Subject: Re: [PATCH] MIPS: BCM63XX: properly handle mac address octet overflow
From: Jonas Gorski <jonas.gorski@gmail.com>
Date: Tue, 18 Sep 2012 13:56:49 +0200
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org, Maxime Bizon <mbizon@freebox.fr>, Florian Fainelli <florian@openwrt.org>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0OEpOmu3yaVExx2aeDaMuVbQmZgW01kxQlMbD+o6R+I=; b=DLhT8or5prEJ0TFmLrRE5aZP1YVb+OOuLGHgk5NzvxaVq/zQDN8Nh9sibm6fLzhSHl kiN8sVrKXDN2a85Y3jMFXaxMJsCRTFqJXL/dLwhkycHUo+W7FEwdQi8XC8b0FTeDFSGe ifKLJOK//YnVOh3Nd4uETNWwTAu9yAkZJHRdIwX5Q5NAd3Yx37JT2tfgk2fjd7LRGZes x+tP0/S/K/p+2n7icCDMd/ai7c7DBHzP6NYyAhIDE6Y8on1WvmzgHJZ2J2Mit/vNzpeT hjlSvv8Cqp8g+QIz7GlT50bvzdbDoAimq6nI69M3cCq14TrHbp14t4sc5D8TojGf1cv8 omLg==
In-reply-to: <50586059.4090407@mvista.com>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
References: <1347960728-5884-1-git-send-email-jonas.gorski@gmail.com> <50586059.4090407@mvista.com>
Sender: linux-mips-bounce@linux-mips.org
On 18 September 2012 13:51, Sergei Shtylyov <sshtylyov@mvista.com> wrote:
> Hello.
>
>
> On 18-09-2012 13:32, Jonas Gorski wrote:
>
>> While calculating the mac address the pointer for the current octet was
>> never reset back to the least significant one after being decremented
>> because of an octet overflow. This resulted in the code continuing to
>> increment at the current octet, potentially generating duplicate or
>> invalid mac addresses.
>
>
>> As a second issue the pointer was allowed to advance up to the most
>> significant octet, modifying the OUI, and potentially changing the type
>> of mac address.
>
>
>> Rewrite the code so it resets the pointer to the least significant
>> in each outer loop step, and bails out when the least significant octet
>> of the OUI is reached.
>
>
>> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
>> ---
>>   arch/mips/bcm63xx/boards/board_bcm963xx.c |   16 +++++++++-------
>>   1 file changed, 9 insertions(+), 7 deletions(-)
>
>
>> diff --git a/arch/mips/bcm63xx/boards/board_bcm963xx.c
>> b/arch/mips/bcm63xx/boards/board_bcm963xx.c
>> index ea4ea77..f0fcec6 100644
>> --- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
>> +++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
>> @@ -720,7 +720,7 @@ const char *board_get_name(void)
>>    */
>>   static int board_get_mac_address(u8 *mac)
>>   {
>> -       u8 *p;
>> +       u8 *oui;
>>         int count;
>>
>>         if (mac_addr_used >= nvram.mac_addr_count) {
>> @@ -729,21 +729,23 @@ static int board_get_mac_address(u8 *mac)
>>         }
>>
>>         memcpy(mac, nvram.mac_addr_base, ETH_ALEN);
>> -       p = mac + ETH_ALEN - 1;
>> +       oui = mac + ETH_ALEN/2 - 1;
>>         count = mac_addr_used;
>>
>>         while (count--) {
>> +               p = mac + ETH_ALEN - 1;
>
>
>    But didn't you remove 'p' above? Did you compile this?

Argh. Yes, but the wrong version (my "user space" one to test it). Let
me try that again ... . Thanks for catching it.

Jonas

<Prev in Thread] Current Thread [Next in Thread>