linux-kernel - Re: [PATCH] vfio: Fix NULL pointer dereference in vfio_pci_bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240112083026.7fd01b41.alex.williamson@redhat.com>
Date: Fri, 12 Jan 2024 08:30:26 -0700
From: Alex Williamson <alex.williamson@...hat.com>
To: Kunwu Chan <chentao@...inos.cn>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vfio: Fix NULL pointer dereference in
 vfio_pci_bus_notifier

On Fri, 12 Jan 2024 14:22:21 +0800
Kunwu Chan <chentao@...inos.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@...inos.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,

Alex