From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from AM0PR83CU005.outbound.protection.outlook.com (mail-westeuropeazon11020075.outbound.protection.outlook.com [52.101.69.75]) by lore.virtuozzo.com (Postfix) with ESMTPS id 30F80802A7 for ; Tue, 6 Oct 2026 16:31:34 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jwOiJby2ncbpCd7qENOlwU2zUTvHOtTqrD/9VAiWHxKdTfj35okoXYTWyKFBXcgqXqO/7VmNNjujOjch3vn1TohEw9veCXdBKT7+7092Ifh6u99xK+3a8CFFCXwbPYOgkvUUl4Z0/1SEi2oBPOemxzcqxS6TjkweBrygaq1ecKn161h+izCpGbCYolA75UfekAXBfZgFHnN2YDH/HoAqitvjYIm8rpI9UCI+nvN6OKCA5S0St1pg7r5B5A8Ngq3+dpYo5ySMiDEnvbRYn7oKLanZyAC47pV4cs+MEx8b2ecEDAVypxymaZD2gwSiM/yg4hDsvnpAIqs9ayfu1p54Tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=gaywLc/dyA/GZxHuT+5OV7OXLbT/RcDpXdJ4Vbn//Ik=; b=eymw+p/7TgX/eYgH09d5t04iE+x7oEOHA3IRc3nEKonl3AyVi2qEwnqqY9ncvM9AFOObORevMmYnKAJ2QrQS6VdvNa6XF5D9fByE45yUIQ5PE9bc89TrQUwVITpJo8nLn9XjHSwd7k1VIpmsAfQK4xbgIDrCzFbyD78Sj/oMNaS+682J7oY6nEdTpPge+5UX926CCmQpQOZbIZu879uz1JSFjKI4RsUYEpeM5Io7z3NlGJhuqS8kthFuMY6QrfoA66NL4jU5GOhDZXBYtPjlzuIIMKWUfZtEoMa0q0UNtvgx9sKRla4pKWHtaSVhD9sJek0UvX36UYw4JXNO9pcmFg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.5) smtp.rcpttodomain=virtuozzo.com smtp.mailfrom=eu-central-1.amazonses.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=sashiko.virtuozzo.com; dkim=pass (signature was verified) header.d=sashiko.virtuozzo.com; dkim=pass (signature was verified) header.d=amazonses.com; arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.onmicrosoft.com; s=selector2-virtuozzo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gaywLc/dyA/GZxHuT+5OV7OXLbT/RcDpXdJ4Vbn//Ik=; b=jqnis4Anh124Jbz/67sCgsjYzKyf7FMZtRpOGgoSB08LiDLztqNsPwlsmUCrMMds8qZZ/BVg3nlXCaKciOzOEZnA6a0Sn+e7/qf+V3KobZnbZdDEGdZ3ohAzmsySI8wn3DhzykniBxi4bKq63aPaHXPPi2YoKaTipbdksgK+7ew= Received: from DUZPR01CA0064.eurprd01.prod.exchangelabs.com (2603:10a6:10:3c2::17) by AS8PR08MB7354.eurprd08.prod.outlook.com (2603:10a6:20b:445::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14; Tue, 6 Oct 2026 16:31:27 +0000 Received: from DB3PEPF0000885E.eurprd02.prod.outlook.com (2603:10a6:10:3c2:cafe::94) by DUZPR01CA0064.outlook.office365.com (2603:10a6:10:3c2::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Tue, 6 Oct 2026 16:31:27 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.5) smtp.mailfrom=eu-central-1.amazonses.com; dkim=pass (signature was verified) header.d=sashiko.virtuozzo.com;dkim=pass (signature was verified) header.d=amazonses.com;dmarc=pass action=none header.from=sashiko.virtuozzo.com; Received-SPF: Pass (protection.outlook.com: domain of eu-central-1.amazonses.com designates 69.169.224.5 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.5; helo=b224-5.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-5.smtp-out.eu-central-1.amazonses.com (69.169.224.5) by DB3PEPF0000885E.mail.protection.outlook.com (10.167.242.9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Tue, 6 Oct 2026 16:31:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1791304287; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID; bh=FjgJRhxOclrmZL4B8t3n2PqBJZ6xu++7e5QNgRSburc=; b=1iNvfeGX93Wk3cp4fCknEieL4UJfcY2SBGvsP8JcNxY+x9cBuCMjeAgr9nOVXqi9 SNnWtYtSGEBbtLBqbWgx02mASMHVE1jqDfqZtr3d/MiUXbdhd+7U7yht7+0SRpcHy05 0ylGnbm3Az9J8ji2xDjfZ0p68vTO1et1DPBrDnBVNot5T1rFORsHyschv0cZLYlLyik Dhl3UL3iT+LI+rg9JYhD3cuVRuPAh4vDHkEgFUFhZZqPNuzoNbVNmqLQKXmoq9aviBN FgArEidwx5xD3Y/XoFmxpFj9i7CaykUR0TYV6wpkMGmcZMYzGtTO/VJqaIq5T2wAIWo W9GGC9tsjA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=sokbgaaqhfgd6qjht2wmdajpuuanpimv; d=amazonses.com; t=1791304287; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID:Feedback-ID; bh=FjgJRhxOclrmZL4B8t3n2PqBJZ6xu++7e5QNgRSburc=; b=D4hvNIDHeAIvQrVrHNOqMB1cIW3EKmxcUh3ZQu/D/qNfCdIHbjk+ziHsyVaLquyG p2Fl/BUQjZzUGVO2ilf8Z6JZ+IlRxJNq6hZD0ffB8fi4DxiZI8rMpRuh9+r6ffG+sVd h3Y6lE5luiQTsU12sl58FvbXqrtI+K1HA77tgoD0= From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.0 v8 01/14] usb-host: don't leak hostdev FD on open failure #VSTOR-137800 To: svt-core@virtuozzo.com, Andrey Drobyshev Cc: den@openvz.org, andrey.drobyshev@virtuozzo.com In-Reply-To: <20261006-usb-host_v3-v8-1-72ae4fb8977b@virtuozzo.com> References: <20261006-usb-host_v3-v8-0-72ae4fb8977b@virtuozzo.com> <20261006-usb-host_v3-v8-1-72ae4fb8977b@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Oct 2026 16:31:27 +0000 Message-ID: <010701a1120e434b-ac4c6b00-089e-425e-bb21-84a4c74176e3-000000@eu-central-1.amazonses.com> Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.06-69.169.224.5 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PEPF0000885E:EE_|AS8PR08MB7354:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 8ba6811a-50da-4bc0-d918-08df23c74534 X-LD-Processed: 0bc7f26d-0264-416e-a6fc-8352af79c58f,ExtAddr X-MS-Exchange-AtpMessageProperties: SA List-Id: svt-core@virtuozzo.com X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|704161411799003|9140799003|61400799027|376014|32142699015|48200799018|4113699003|5113699003|56012099006|5063699009|4143699003|10067099003|22082099003|13003099007|16102099003|18002099003|55112099003; X-Microsoft-Antispam-Message-Info: mJ8XSr8U536x+GZ28unzFPE9Cw1oYPN40Vzx3gqG1pUzi1RSwB6Hs5rwoMkVzk3aJcwNts02a/BoUU8a8KZtAiulTUvY/AE1buF3z5AvjCjAtywZbzCZDNPYz7eXovRQnV1lQEDD2EUlf8XORXo8MA1bvF2DfnkOTyUv2wPLZqFfA+Gge7G7cYZVKx92yRFJ6Z0LVUf+0r7zEiKNOxDOBx6l6hA5jr4GFoG/xkPjVDQq+1ixYQy/cO0RdvhRugQE3mNdpZwqfflpRZxtC1/9lT3ppPSjcHbClwvwnguKV5sMjZHULCu7wYvUX0S4TS2NdQ0w5cM91T72rLZhcoH6eik8RnesPbTYheeeV+R1zIBuP7+DEA3YCnO6ZQgIbdxBZ/UmOoCEy6vkFwMyGurLJjCec+qXBbQESzZEx3zSz5e2B1uK0Jj6BihTZp9h3xNNUzHIN38JpKW1mB3PD0K8Q11okbF+pE9J5pljiBK0Aa2tJ4ciMUAkl/J8/XaRo0lzwZTE/vEPafR7R7pAy5m/KDxswaATu6p/O0sdHYiE1d20vXyaFk0jxRQAha7R0VVa/UybvM2uiKSGbJrtgIqSWGbVAOQQmgD0pHwB7JjpIrGuCaFzqTTDRBL59XWmvj5p1HN20nHrJoRsOKLSGGSshlMu3laI4zXmp7NCKC7bcbps5GixHj5M54wnw83gEFURkn8E1NGMmC9g3fofs9m5n/YKTy5xeNfd6GaIQdyvZQxSSaBN5D/Nu0FLBUpOQpmmSogfD+3tzdTiv4r0jFupYWt03Vc7S7xHqrxazF/HUbil+vJuJk1+Ybnt033sdn8RkrYLKHUel9YPoU4upcJAyQ== X-Forefront-Antispam-Report: CIP:69.169.224.5;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-5.smtp-out.eu-central-1.amazonses.com;PTR:b224-5.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(704161411799003)(9140799003)(61400799027)(376014)(32142699015)(48200799018)(4113699003)(5113699003)(56012099006)(5063699009)(4143699003)(10067099003)(22082099003)(13003099007)(16102099003)(18002099003)(55112099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: rUupQI6ni8A7kq89cmzcTdpicq+xCvubC0+SQQ7Jym6kQcqy6ui041Yu+kTNdzSgFYBLKL5RYqyKyrqp4QdK/AJ1KzmxsfFtV/n6JW9HjGrzVNUrPI84WysWXMIDUqsiwfGNZDhKgI8VsKP9C6jjVxEQnkQry6gN/ONqtvt1/7owK/u0oi4GGtVaU+63WIc4q2ftcJePvj9PiDLubHw0D2nHeYNMJim3RH/p8npuaDV15CSHOOWJXm0DQJXkwpFJrLU12/Y8Eo4dETnPxUumga4UZgKM7u9ZsSAxBFoGxTDdTQjGAZLG1sTWCGKaSdn8cLRdYdOq5/FpyEAcWV6sauFbjCoU+G7GH0mj0edv4LrdrwhCKJVYryhoQ2JfanuB4a8X1ve9h4ekTQRUXdMsIOx0jW0lrtr3BVgW5p0SIO1BF9YRzVqgci31Asxa7OIz X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-Auto-Response-Suppress: DR, OOF, AutoReply X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 16:31:27.5509 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8ba6811a-50da-4bc0-d918-08df23c74534 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: DB3PEPF0000885E.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB7354 Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [Low] usb-host: usb_host_open() fail path may double-close wrapped hostfd= after libusb_close() -- commit e4ff0c7f70381f2bead74b81a45f4480bcb0c76b Author: Andrey Drobyshev usb-host: don't leak hostdev FD on open failure #VSTOR-137800 This patch stores the caller-supplied hostfd in s->hostfd before libusb_wrap_sys_device() is called. It also closes that fd on the fail: path of usb_host_open(), so a failed open no longer leaks it. > diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c > --- a/hw/usb/host-libusb.c > +++ b/hw/usb/host-libusb.c [ ... ] > @@ -1066,6 +1070,10 @@ fail: > s->dh =3D NULL; > s->dev =3D NULL; > } > + if (s->hostfd !=3D -1) { > + close(s->hostfd); > + s->hostfd =3D -1; > + } > return -1; > } [Severity: Low] Can this close() be a double close of the wrapped fd? Consider the path where usb_host_open() is called with dev =3D=3D NULL, libusb_wrap_sys_device() succeeds, and a later step such as usb_device_attach() fails. Control reaches fail: and runs: libusb_close(s->dh); s->dh =3D NULL; s->dev =3D NULL; } if (s->hostfd !=3D -1) { close(s->hostfd); Because s->hostfd is now set before the wrap call, this close() runs right after libusb_close(s->dh). If the libusb version in use closes a wrapped fd in libusb_close(), the fd is closed twice. The second close() could then hit an unrelated descriptor if another thread reused the number in between. I could not check this against libusb sources. Current Linux backends mark wrapped fds with fd_keep and do not close them, but older releases such as 1.0.23 may behave differently. usb_host_close() already uses the same libusb_close() then close() order, so the new error path relies on the same assumption. Is that assumption valid for all libusb versions that QEMU supports? --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261006-usb-= host_v3-v8-0-72ae4fb8977b@virtuozzo.com?part=3D1