[PATCH] wmi: use memcmp instead of strncmp to compare GUIDs

[PATCH] wmi: use memcmp instead of strncmp to compare GUIDs

[Thadeu Lima de Souza Cascardo]

While looking for the duplicates in /sys/class/wmi/, I couldn't find
them. The code that looks for duplicates uses strncmp in a binary GUID,
which may contain zero bytes. The right function is memcmp, which is
also used in another section of wmi code.

It was finding 49142400-C6A3-40FA-BADB-8A2652834100 as a duplicate of
39142400-C6A3-40FA-BADB-8A2652834100. Since the first byte is the fourth
printed, they were found as equal by strncmp.

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
---
 drivers/platform/x86/wmi.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
index 104b77c..aecd9a9 100644
--- a/drivers/platform/x86/wmi.c
+++ b/drivers/platform/x86/wmi.c
@@ -755,7 +755,7 @@ static bool guid_already_parsed(const char *guid_string)
 	struct wmi_block *wblock;
 
 	list_for_each_entry(wblock, &wmi_block_list, list)
-		if (strncmp(wblock->gblock.guid, guid_string, 16) == 0)
+		if (memcmp(wblock->gblock.guid, guid_string, 16) == 0)
 			return true;
 
 	return false;
-- 
1.7.2.3

Re: [PATCH] wmi: use memcmp instead of strncmp to compare GUIDs

[Jesper Juhl]

On Sun, 28 Nov 2010, Thadeu Lima de Souza Cascardo wrote:

> While looking for the duplicates in /sys/class/wmi/, I couldn't find
> them. The code that looks for duplicates uses strncmp in a binary GUID,
> which may contain zero bytes. The right function is memcmp, which is
> also used in another section of wmi code.
> 
> It was finding 49142400-C6A3-40FA-BADB-8A2652834100 as a duplicate of
> 39142400-C6A3-40FA-BADB-8A2652834100. Since the first byte is the fourth
> printed, they were found as equal by strncmp.
> 
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
> ---
>  drivers/platform/x86/wmi.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
> index 104b77c..aecd9a9 100644
> --- a/drivers/platform/x86/wmi.c
> +++ b/drivers/platform/x86/wmi.c
> @@ -755,7 +755,7 @@ static bool guid_already_parsed(const char *guid_string)
>  	struct wmi_block *wblock;
>  
>  	list_for_each_entry(wblock, &wmi_block_list, list)
> -		if (strncmp(wblock->gblock.guid, guid_string, 16) == 0)
> +		if (memcmp(wblock->gblock.guid, guid_string, 16) == 0)
>  			return true;
>  
>  	return false;
> 

Looks right to me.

-- 
Jesper Juhl <jj@chaosbits.net>            http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.

Re: [PATCH] wmi: use memcmp instead of strncmp to compare GUIDs

[Matthew Garrett]

Applied to -next, thanks.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] wmi: use memcmp instead of strncmp to compare GUIDs

[Thadeu Lima de Souza Cascardo]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

On Mon, Dec 06, 2010 at 10:02:31PM +0000, Matthew Garrett wrote:
> Applied to -next, thanks.
> 
> -- 
> Matthew Garrett | mjg59@srcf.ucam.org

Hello, Matthew.

I consider this one a serious bug and with a trivial fix that should go
to Linus, for the next release candidate. I also consider it should go
to stable releases, and that's why I'm copying stable.

Any out-of-tree wmi driver written for systems with two or more GUIDs
containing any '\0' byte with a common prefix will fail to load because
of this bug. I've hit that, and that's how I found the bug.

Regards,
Cascardo.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] wmi: use memcmp instead of strncmp to compare GUIDs

[Matthew Garrett]

On Mon, Dec 06, 2010 at 08:13:46PM -0200, Thadeu Lima de Souza Cascardo wrote:
> On Mon, Dec 06, 2010 at 10:02:31PM +0000, Matthew Garrett wrote:
> > Applied to -next, thanks.
> > 
> > -- 
> > Matthew Garrett | mjg59@srcf.ucam.org
> 
> Hello, Matthew.
> 
> I consider this one a serious bug and with a trivial fix that should go
> to Linus, for the next release candidate. I also consider it should go
> to stable releases, and that's why I'm copying stable.

Sure, I'll pull it back for .37 as well.

-- 
Matthew Garrett | mjg59@srcf.ucam.org