[added,to,the,3.18,stable,tree] firmware: dmi_scan: Fix dmi_len type

Message ID 1426648483-4376-11-git-send-email-sasha.levin@oracle.com
State New
Headers show

Commit Message

Sasha Levin March 18, 2015, 3:14 a.m.
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>

This patch has been added to the 3.18 stable tree. If you have any
objections, please let us know.

Comments

Ivan Khoronzhuk March 18, 2015, 9:15 a.m. | #1
Sasha,
There is no need in this patch for 3.18, only beginning from 3.19.

On 18.03.15 05:14, Sasha Levin wrote:
> From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>
> This patch has been added to the 3.18 stable tree. If you have any
> objections, please let us know.
>
> ===============
>
> [ Upstream commit 6d9ff473317245e3e5cd9922b4520411c2296388 ]
>
> According to SMBIOSv3 specification the length of DMI table can be
> up to 32bits wide. So use appropriate type to avoid overflow.
>
> It's obvious that dmi_num theoretically can be more than u16 also,
> so it's can be changed to u32 or at least it's better to use int
> instead of u16, but on that moment I cannot imagine dmi structure
> count more than 65535 and it can require changing type of vars that
> work with it. So I didn't correct it.
>
> Acked-by: Ard Biesheuvel <ard@linaro.org>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
> ---
>   drivers/firmware/dmi_scan.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> index 17afc51..84bc2a5 100644
> --- a/drivers/firmware/dmi_scan.c
> +++ b/drivers/firmware/dmi_scan.c
> @@ -78,7 +78,7 @@ static const char * __init dmi_string(const struct dmi_header *dm, u8 s)
>    *	We have to be cautious here. We have seen BIOSes with DMI pointers
>    *	pointing to completely the wrong place for example
>    */
> -static void dmi_table(u8 *buf, int len, int num,
> +static void dmi_table(u8 *buf, u32 len, int num,
>   		      void (*decode)(const struct dmi_header *, void *),
>   		      void *private_data)
>   {
> @@ -108,7 +108,7 @@ static void dmi_table(u8 *buf, int len, int num,
>   }
>   
>   static u32 dmi_base;
> -static u16 dmi_len;
> +static u32 dmi_len;
>   static u16 dmi_num;
>   
>   static int __init dmi_walk_early(void (*decode)(const struct dmi_header *,

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ivan Khoronzhuk March 18, 2015, 7:07 p.m. | #2
SMBIOSv3 is absent in k3.18.
I simply chekcouted on v3.18 and verified.
There were no SMBIOSv3 support added.

Patch points on SMBIOSv3, no SMBIOSv3 - no need in patch.

On 18.03.15 19:49, Sasha Levin wrote:
> Ivan,
>
> Why so? The commit description/code doesn't really make that clear.
>
>
> Thanks,
> Sasha
>
> On 03/18/2015 05:15 AM, Ivan Khoronzhuk wrote:
>> Sasha,
>> There is no need in this patch for 3.18, only beginning from 3.19.
>>
>> On 18.03.15 05:14, Sasha Levin wrote:
>>> From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>>>
>>> This patch has been added to the 3.18 stable tree. If you have any
>>> objections, please let us know.
>>>
>>> ===============
>>>
>>> [ Upstream commit 6d9ff473317245e3e5cd9922b4520411c2296388 ]
>>>
>>> According to SMBIOSv3 specification the length of DMI table can be
>>> up to 32bits wide. So use appropriate type to avoid overflow.
>>>
>>> It's obvious that dmi_num theoretically can be more than u16 also,
>>> so it's can be changed to u32 or at least it's better to use int
>>> instead of u16, but on that moment I cannot imagine dmi structure
>>> count more than 65535 and it can require changing type of vars that
>>> work with it. So I didn't correct it.
>>>
>>> Acked-by: Ard Biesheuvel <ard@linaro.org>
>>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>>> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
>>> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>>> ---
>>>    drivers/firmware/dmi_scan.c | 4 ++--
>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
>>> index 17afc51..84bc2a5 100644
>>> --- a/drivers/firmware/dmi_scan.c
>>> +++ b/drivers/firmware/dmi_scan.c
>>> @@ -78,7 +78,7 @@ static const char * __init dmi_string(const struct dmi_header *dm, u8 s)
>>>     *    We have to be cautious here. We have seen BIOSes with DMI pointers
>>>     *    pointing to completely the wrong place for example
>>>     */
>>> -static void dmi_table(u8 *buf, int len, int num,
>>> +static void dmi_table(u8 *buf, u32 len, int num,
>>>                  void (*decode)(const struct dmi_header *, void *),
>>>                  void *private_data)
>>>    {
>>> @@ -108,7 +108,7 @@ static void dmi_table(u8 *buf, int len, int num,
>>>    }
>>>      static u32 dmi_base;
>>> -static u16 dmi_len;
>>> +static u32 dmi_len;
>>>    static u16 dmi_num;
>>>      static int __init dmi_walk_early(void (*decode)(const struct dmi_header *,

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ivan Khoronzhuk March 18, 2015, 7:11 p.m. | #3
$ git ll v3.18 | grep fc4302
$ git ll v3.19 | grep fc4302
fc43026 dmi: add support for SMBIOS 3.0 64-bit entry point

On 18.03.15 19:49, Sasha Levin wrote:
> Ivan,
>
> Why so? The commit description/code doesn't really make that clear.
>
>
> Thanks,
> Sasha
>
> On 03/18/2015 05:15 AM, Ivan Khoronzhuk wrote:
>> Sasha,
>> There is no need in this patch for 3.18, only beginning from 3.19.
>>
>> On 18.03.15 05:14, Sasha Levin wrote:
>>> From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>>>
>>> This patch has been added to the 3.18 stable tree. If you have any
>>> objections, please let us know.
>>>
>>> ===============
>>>
>>> [ Upstream commit 6d9ff473317245e3e5cd9922b4520411c2296388 ]
>>>
>>> According to SMBIOSv3 specification the length of DMI table can be
>>> up to 32bits wide. So use appropriate type to avoid overflow.
>>>
>>> It's obvious that dmi_num theoretically can be more than u16 also,
>>> so it's can be changed to u32 or at least it's better to use int
>>> instead of u16, but on that moment I cannot imagine dmi structure
>>> count more than 65535 and it can require changing type of vars that
>>> work with it. So I didn't correct it.
>>>
>>> Acked-by: Ard Biesheuvel <ard@linaro.org>
>>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>>> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
>>> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>>> ---
>>>    drivers/firmware/dmi_scan.c | 4 ++--
>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
>>> index 17afc51..84bc2a5 100644
>>> --- a/drivers/firmware/dmi_scan.c
>>> +++ b/drivers/firmware/dmi_scan.c
>>> @@ -78,7 +78,7 @@ static const char * __init dmi_string(const struct dmi_header *dm, u8 s)
>>>     *    We have to be cautious here. We have seen BIOSes with DMI pointers
>>>     *    pointing to completely the wrong place for example
>>>     */
>>> -static void dmi_table(u8 *buf, int len, int num,
>>> +static void dmi_table(u8 *buf, u32 len, int num,
>>>                  void (*decode)(const struct dmi_header *, void *),
>>>                  void *private_data)
>>>    {
>>> @@ -108,7 +108,7 @@ static void dmi_table(u8 *buf, int len, int num,
>>>    }
>>>      static u32 dmi_base;
>>> -static u16 dmi_len;
>>> +static u32 dmi_len;
>>>    static u16 dmi_num;
>>>      static int __init dmi_walk_early(void (*decode)(const struct dmi_header *,

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

===============

[ Upstream commit 6d9ff473317245e3e5cd9922b4520411c2296388 ]

According to SMBIOSv3 specification the length of DMI table can be
up to 32bits wide. So use appropriate type to avoid overflow.

It's obvious that dmi_num theoretically can be more than u16 also,
so it's can be changed to u32 or at least it's better to use int
instead of u16, but on that moment I cannot imagine dmi structure
count more than 65535 and it can require changing type of vars that
work with it. So I didn't correct it.

Acked-by: Ard Biesheuvel <ard@linaro.org>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
---
 drivers/firmware/dmi_scan.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 17afc51..84bc2a5 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -78,7 +78,7 @@  static const char * __init dmi_string(const struct dmi_header *dm, u8 s)
  *	We have to be cautious here. We have seen BIOSes with DMI pointers
  *	pointing to completely the wrong place for example
  */
-static void dmi_table(u8 *buf, int len, int num,
+static void dmi_table(u8 *buf, u32 len, int num,
 		      void (*decode)(const struct dmi_header *, void *),
 		      void *private_data)
 {
@@ -108,7 +108,7 @@  static void dmi_table(u8 *buf, int len, int num,
 }
 
 static u32 dmi_base;
-static u16 dmi_len;
+static u32 dmi_len;
 static u16 dmi_num;
 
 static int __init dmi_walk_early(void (*decode)(const struct dmi_header *,