[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH for-4.17 3/6] vpci: don't assume that vpci per-device data exists unconditionally
- To: Roger Pau Monne <roger.pau@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 24 Oct 2022 13:04:01 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XeqPmMJZ+8CnIJjSeKkGG+vz8qOWn+PJ81D0LKkR3ew=; b=IdblzLHAYIpaVKY2rvPYFNEsr8oWszTaFow5dTYMbaki5flFneUkJEsUsDiDJqfwlPLoePFSxi2wFgAK6ZTwE14B5MZpo9r4Kn/pGXBMwcd2KYUe2u7CsYUxOxB9b76tpOflBOdVmNmXBHI2+EWx+UHcxmPBkT2y7UXxuH2ZtfatC7vHzB3xl5PSvZNOm6fnXHBBzEx838ocXshQfaPuJ4fpWF+ulunvp+oXElg1yzeRBs+r10LhSBxQ4+g03IwoYGyk0aenF076MU0u+NxWUY3RYhb0fwxOemHJM3MzGZKg12F8yLmcSZuKW+WNWXrsbbgtYQtTmc0yRq0dQw4BjQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HGAGS9RrHjh1k2jbUmduNOCltNFDPL979I3YmW0ZkHjxjjExgZvjKCV0YIv+Muq149Z0BD5at7zN7QPy0+mlBW6/v6GmRM9tWFIhHCeldbmWNMWwWZ69JF/y6xv8gw5bWLWmYQHc/g6pEp6UFglL8s+1CK40K9OVe77kbDizVClLCNzzyzuzCIZnyoDfJkIr5gdfMo2Ei8T3chjso3uH3md6ycAq2oQ2XX9tqbGdi9F65A1787TMVQ6+1FOkDPLE5r5l8BrnPEjhHf0dwHWU7YMcrZ6a981EzS0AcXoKTdIu+9/l1/bfWmDqVBACdVyOwlJRZOd4qJzYIX/9RO51HA==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Mon, 24 Oct 2022 11:04:09 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 20.10.2022 11:46, Roger Pau Monne wrote:
> It's possible for a device to be assigned to a domain but have no
> vpci structure if vpci_process_pending() failed and called
> vpci_remove_device() as a result. The unconditional accesses done by
> vpci_{read,write}() and vpci_remove_device() to pdev->vpci would
> then trigger a NULL pointer dereference.
>
> Add checks for pdev->vpci presence in the affected functions.
>
> Fixes: 9c244fdef7 ('vpci: add header handlers')
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
I wonder though whether these changes are enough. Is
vpci_process_pending() immune to a pdev losing its ->vpci?
Furthermore msix_find() iterates over d->arch.hvm.msix_tables, which
looks to only ever be added to. Doesn't this list need pruning by
vpci_remove_device()? I've noticed this only because of looking at
derefs of ->vpci in msix.c - I don't think I can easily see that all
of those derefs are once again immune to a pdev losing its ->vpci.
Jan
|
