Received-SPF: pass (google.com: domain of linux-kernel+bounces-25649-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <9e917782-03cd-493e-b6f1-c6170a265a38@kylinos.cn>
Date: Mon, 15 Jan 2024 14:07:08 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] vfio: Fix NULL pointer dereference in
 vfio_pci_bus_notifier
Content-Language: en-US
To: Alex Williamson <alex.williamson@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20240112062221.135681-1-chentao@kylinos.cn>
 <20240112083026.7fd01b41.alex.williamson@redhat.com>
From: Kunwu Chan <chentao@kylinos.cn>
In-Reply-To: <20240112083026.7fd01b41.alex.williamson@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2024/1/12 23:30, Alex Williamson wrote:
> On Fri, 12 Jan 2024 14:22:21 +0800
> Kunwu Chan <chentao@kylinos.cn> wrote:
> 
>> kasprintf() returns a pointer to dynamically allocated memory
>> which can be NULL upon failure. Ensure the allocation was successful
>> by checking the pointer validity.
>>
>> Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
>> ---
>>   drivers/vfio/pci/vfio_pci_core.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
>> index 1cbc990d42e0..74e5b89a3a0c 100644
>> --- a/drivers/vfio/pci/vfio_pci_core.c
>> +++ b/drivers/vfio/pci/vfio_pci_core.c
>> @@ -2047,6 +2047,8 @@ static int vfio_pci_bus_notifier(struct notifier_block *nb,
>>   			 pci_name(pdev));
>>   		pdev->driver_override = kasprintf(GFP_KERNEL, "%s",
>>   						  vdev->vdev.ops->name);
>> +		if (!pdev->driver_override)
>> +			return -ENOMEM;
>>   	} else if (action == BUS_NOTIFY_BOUND_DRIVER &&
>>   		   pdev->is_virtfn && physfn == vdev->pdev) {
>>   		struct pci_driver *drv = pci_dev_driver(pdev);
> 
> This is a blocking notifier callback, so errno isn't a proper return
> value, nor does it accomplish anything.  We're into the realm of
> worrying about small allocation failures here, which I understand
> essentially cannot happen, but about the best we could do at this
> point would be to WARN_ON if we weren't able to allocate an override.
Thanks for your reply.
I'll update v2 patch use WARN_ON to print some callstack msgs when we 
weren't able to allocate an override.

These msgs could reduce some of the worries and help us to find what happed.

> Thanks,
> 
> Alex
> 
-- 
Thanks,
   Kunwu