Platform-driver-x86 Archive on lore.kernel.org
 help / color / Atom feed
From: Perry Yuan <perry979106@gmail.com>
To: Hans de Goede <hdegoede@redhat.com>,
	"Limonciello, Mario" <Mario.Limonciello@dell.com>,
	Mark Gross <mgross@linux.intel.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"platform-driver-x86@vger.kernel.org" 
	<platform-driver-x86@vger.kernel.org>
Subject: Re: [PATCH] platform/x86: dell-wmi-sysman: fix a NULL pointer dereference
Date: Mon, 1 Feb 2021 10:36:21 +0800
Message-ID: <8c51e60a-f5be-610a-ab13-84223d291a45@gmail.com> (raw)
In-Reply-To: <a371c1c9-d803-f2e6-dfca-607a0650345f@redhat.com>

On 2021/2/1 4:59, Hans de Goede wrote:
> Hi,
> 
> On 1/31/21 3:04 PM, Limonciello, Mario wrote:
>>
>>
>>> -----Original Message-----
>>> From: Hans de Goede <hdegoede@redhat.com>
>>> Sent: Saturday, January 30, 2021 15:44
>>> To: Limonciello, Mario; Mark Gross
>>> Cc: LKML; platform-driver-x86@vger.kernel.org
>>> Subject: Re: [PATCH] platform/x86: dell-wmi-sysman: fix a NULL pointer
>>> dereference
>>>
>>>
>>> [EXTERNAL EMAIL]
>>>
>>> Hi,
>>>
>>> On 1/29/21 6:26 PM, Mario Limonciello wrote:
>>>> An upcoming Dell platform is causing a NULL pointer dereference
>>>> in dell-wmi-sysman initialization.  Validate that the input from
>>>> BIOS matches correct ACPI types and abort module initialization
>>>> if it fails.
>>>>
>>>> This leads to a memory leak that needs to be cleaned up properly.
>>>>
>>>> Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
>>>> ---
>>>>   drivers/platform/x86/dell-wmi-sysman/sysman.c | 8 +++++++-
>>>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/platform/x86/dell-wmi-sysman/sysman.c
>>> b/drivers/platform/x86/dell-wmi-sysman/sysman.c
>>>> index dc6dd531c996..38b497991071 100644
>>>> --- a/drivers/platform/x86/dell-wmi-sysman/sysman.c
>>>> +++ b/drivers/platform/x86/dell-wmi-sysman/sysman.c
>>>> @@ -419,13 +419,19 @@ static int init_bios_attributes(int attr_type, const
>>> char *guid)
>>>>   		return retval;
>>>>   	/* need to use specific instance_id and guid combination to get right
>>> data */
>>>>   	obj = get_wmiobj_pointer(instance_id, guid);
>>>> -	if (!obj)
>>>> +	if (!obj || obj->type != ACPI_TYPE_PACKAGE) {
>>>> +		release_attributes_data();
>>>
>>> All calls of  init_bios_attributes() have the following error handling:
>>>
>>>          ret = init_bios_attributes(INT, DELL_WMI_BIOS_INTEGER_ATTRIBUTE_GUID);
>>>          if (ret) {
>>>                  pr_debug("failed to populate integer type attributes\n");
>>>                  goto fail_create_group;
>>>          }
>>>
>>> 	...
>>>
>>> fail_create_group:
>>>          release_attributes_data();
>>>
>>> So that added release_attributes_data() call is not necessary. If you can
>>> respin
>>> this patch Monday with the release_attributes_data(); addition dropped, then
>>> I will try to get this to Linus in time for 5.11 .
>>>
>>> Or I can fix this up locally if you agree with dropping the unnecessary
>>> release_attributes_data() call.
>>>
>>
>> Yes, please go ahead and drop the unnecessary call locally.
> 
> Ok, I've merged this into my review-hans branch and I will push this out
> to for-next as soon as a local build has finished. I'll also include
> this in my last fixes pull-req for Linus later this week.
> 
> While working on this I did notice that the function in question still
> has a bunch of further issues. But since this patch fixes a crash and has
> been tested I've decided to move forward with it as is (with the duplicate
> release_attributes_data() call dropped). The further issues can be fixed
> with follow-up patches.
> 
> So the other issues which I noticed are:
> 
> 1. Calling release_attributes_data() in the error-path here:
> 
> 	obj = get_wmiobj_pointer(instance_id, guid);
> 	if (!obj || obj->type != ACPI_TYPE_PACKAGE) {
> 		return -ENODEV;
> 	}
> 
> Is not necessary as discussed, but the added obj->type != ACPI_TYPE_PACKAGE
> which I assume triggers to fix the reported crash, means that obj is not
> NULL in which case we should free it. So this should become:
> 
> 	obj = get_wmiobj_pointer(instance_id, guid);
> 	if (!obj || obj->type != ACPI_TYPE_PACKAGE) {
> 		kfree(obj);
> 		return -ENODEV;
> 	}
> 
> Note that the kfree() will be a no-op when obj == NULL. This means that
> with just the current fix merged there is a small memleak on machines
> where we hit the error-path. I've decided that we can live with that,
> since the alternative is the crash or me pushing something untested.
> 
> 
> 2. There is a while below this if, which gets a new obj pointer:
> 
> 	obj = get_wmiobj_pointer(instance_id, guid);
> 	if (!obj || obj->type != ACPI_TYPE_PACKAGE) {
> 		kfree(obj);
> 		return -ENODEV;
> 	}
> 	elements = obj->package.elements;
> 
> 	mutex_lock(&wmi_priv.mutex);
> 	while (elements) {
> 		...
> 
> nextobj:
> 		kfree(obj);
> 		instance_id++;
> 		obj = get_wmiobj_pointer(instance_id, guid);
> 		elements = obj ? obj->package.elements : NULL;
> 	}
> 
> This is missing a check for the obj->type for the new obj when
> going into a second (or higher) iteration of the loop.
> 
> This check can be added by moving the original check to inside
> the loop like this:
> 
> 	obj = get_wmiobj_pointer(instance_id, guid);
> 
> 	mutex_lock(&wmi_priv.mutex);	
> 	while (obj) {
> 		if (obj->type != ACPI_TYPE_PACKAGE) {
> 			err = ENODEV;
> 			goto err_attr_init;
> 		}
> 		elements = obj->package.elements;
> 
> 		...
> 
> nextobj:
> 		kfree(obj);
> 		instance_id++;
> 		obj = get_wmiobj_pointer(instance_id, guid);
> 	}
> 
> 
> 3. Functions like populate_enum_data() (and the others) index the
> elements array with an index > 0 without checking the package length
> and also make assumptions about the types embedded in the package
> without checking them.
> 
> 
> 4. The err_attr_init exit path of init_bios_attributes() calls
> release_attributes_data() but that call does not just cleanup
> the results of that single init_bios_attributes() call but also
> of all previous init_bios_attributes() calls as such it makes more
> sense to leave the calling of release_attributes_data() to the caller.
> 
> Either way calling it twice once from the err_attr_init exit path
> and then again in sysman_init() feels wrong, even though I think it
> does no harm.
> 
> Regards,
> 
> Hans
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>>
>> Thank you
>>
>>> Regards,
>>>
>>> Hans
>>>
>>>
>>>
>>>
>>>>   		return -ENODEV;
>>>> +	}
>>>>   	elements = obj->package.elements;
>>>>
>>>>   	mutex_lock(&wmi_priv.mutex);
>>>>   	while (elements) {
>>>>   		/* sanity checking */
>>>> +		if (elements[ATTR_NAME].type != ACPI_TYPE_STRING) {
>>>> +			pr_debug("incorrect element type\n");
>>>> +			goto nextobj;
>>>> +		}
>>>>   		if (strlen(elements[ATTR_NAME].string.pointer) == 0) {
>>>>   			pr_debug("empty attribute found\n");
>>>>   			goto nextobj;
>>>>
>>
> 
Hi Hans.
Could you share your the commit link after you apply this patch to your 
for-next branch?

Thank you!
Perry.


  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-29 17:26 Mario Limonciello
2021-01-29 17:29 ` Limonciello, Mario
2021-01-30  3:55   ` Yuan, Perry
2021-01-30 21:43 ` Hans de Goede
     [not found]   ` <SA1PR19MB49263EE7ECF0D06962BE00ECFAB79@SA1PR19MB4926.namprd19.prod.outlook.com>
2021-01-31 20:59     ` Hans de Goede
2021-02-01  2:36       ` Perry Yuan [this message]
2021-02-01  8:27         ` Hans de Goede

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=8c51e60a-f5be-610a-ab13-84223d291a45@gmail.com \
    --to=perry979106@gmail.com \
    --cc=Mario.Limonciello@dell.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgross@linux.intel.com \
    --cc=platform-driver-x86@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

Platform-driver-x86 Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/platform-driver-x86/0 platform-driver-x86/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 platform-driver-x86 platform-driver-x86/ https://lore.kernel.org/platform-driver-x86 \
		platform-driver-x86@vger.kernel.org
	public-inbox-index platform-driver-x86

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.platform-driver-x86


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git