From nobody Wed Nov 19 01:56:08 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass header.i=teddy.astie@vates.tech; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=vates.tech ARC-Seal: i=1; a=rsa-sha256; t=1763125551; cv=none; d=zohomail.com; s=zohoarc; b=gZtGBdz8cwJTUGZCjPfpXFbiIycgzlfZPN4Hw6P+xjY2vNObENBcUsoG2phLz3VANGTBWRXSVpMAQ63NaVoC5sIYxZfFhZzrGiiqD+67EaGFidMN9k2GNTAxddS32hS79Hs2WcW6vUqejzjQXLWYr06phoBqFplWrxC6b0euY+U= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1763125551; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=It5TUr8BuYqVt4O3sGG623FLGRNdl49Ql9BxMXSKPpc=; b=FpuJ4Bf27rOawrpkUNtp/nBOEzm1ZG46gEQRFNI+LncC2z5wdJ9Ahq7pLyBeNST3jG/oLyvIHl+UmtVy2pIKF9Y1ChK/hCSIKM1kr0VSa1ABFkm8TgIWW1Wb4TjyUoY63G93GJHtlfBsTjBnvaVJ438QaU2U5ZNtOwtj25iVW98= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=teddy.astie@vates.tech; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1763125551388364.91545801961263; Fri, 14 Nov 2025 05:05:51 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.1162650.1490215 (Exim 4.92) (envelope-from ) id 1vJtUX-0005Xb-OH; Fri, 14 Nov 2025 13:05:29 +0000 Received: by outflank-mailman (output) from mailman id 1162650.1490215; Fri, 14 Nov 2025 13:05:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vJtUX-0005XU-KX; Fri, 14 Nov 2025 13:05:29 +0000 Received: by outflank-mailman (input) for mailman id 1162650; Fri, 14 Nov 2025 13:05:28 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vJtUW-0005XM-Kk for xen-devel@lists.xenproject.org; Fri, 14 Nov 2025 13:05:28 +0000 Received: from mail180-15.suw31.mandrillapp.com (mail180-15.suw31.mandrillapp.com [198.2.180.15]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 93cf890c-c15a-11f0-980a-7dc792cee155; Fri, 14 Nov 2025 14:05:22 +0100 (CET) Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail180-15.suw31.mandrillapp.com (Mailchimp) with ESMTP id 4d7HS12QYyzPm0ZmR for ; Fri, 14 Nov 2025 13:05:21 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 9da0dd0ef9aa453886466546575bd6d2; Fri, 14 Nov 2025 13:05:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 93cf890c-c15a-11f0-980a-7dc792cee155 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1763125521; x=1763395521; bh=It5TUr8BuYqVt4O3sGG623FLGRNdl49Ql9BxMXSKPpc=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=ge9zS8PWJP+ThMA20WNhisg8Pmrvt1wm0IkuOJ5PqRkOcWFc1wAiiZ7w42Oxm8Bxr DGe+lt8IlQg+N5PmMBv2+oIRM/m7rk0E+uW0hrGOSYF8dXkghc1CnAiR/+CFWoQPuo zLWodP7bV9fyWTbgWU9erq4gOWDddfcNdAeg1g1w5wVWuankOpaA6NAFifGzlGGKIw OSzdquel8XzhUWE4w8EMdil43UyeHifsmWRjXW6skJBtSZUvlH4ehK+NwQbxr0CXfh j+Kf6JNN/6D38VkUh+2oBwURT6iJTiIzOTRsPf17ydfOevmn9wLPv66CwWrRvRzYIB SdIMEG75DrplA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1763125521; x=1763386021; i=teddy.astie@vates.tech; bh=It5TUr8BuYqVt4O3sGG623FLGRNdl49Ql9BxMXSKPpc=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=0jDB+2ZC4MPia9N9tJh8xSMrJB3HOiIgs4crDs3ff/S0AaHWmpfEoImsQXExy0LTr 3BXCGyrqf4gIextglPYjc7+Iz25QZbUJTLZKGWVeUZ7n6bClbk4tO6+KVSCVILs49I V0rtT9fSnOmoFgoSVa9qD0nnYc5XbqDqfmBnMr//KIP7WYqgSWP7PLO1Tvb+bEJ4Rn Rr4jkQnqpVkyvK8+tZ5ObzV1/ecXnxtQ9vqMXAHs/Ecf+68S6WojMC/LJX0aGDHthT NVpr65TgXTURamf5YDCrE7cbWDXDygqaEGpC+/nk+LS/jWZVviVnsZHUJD7wp6RKua OPZEjCDXZgZqw== From: "Teddy Astie" Subject: =?utf-8?Q?[PATCH]=20ioreq:=20Assert=20with=20out=20of=20bounds=20vCPU=20ID?= X-Mailer: git-send-email 2.51.2 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1763125519558 To: xen-devel@lists.xenproject.org Cc: "Teddy Astie" , "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , "Julian Vetter" Message-Id: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.9da0dd0ef9aa453886466546575bd6d2?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20251114:md Date: Fri, 14 Nov 2025 13:05:21 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity teddy.astie@vates.tech) (identity @mandrillapp.com) X-ZM-MESSAGEID: 1763125553125158500 Content-Type: text/plain; charset="utf-8" A 4K page appears to be able to hold 128 ioreq entries, which luckly matches the current vCPU limit. However, if we decide to increase the domain vCPU limit, that doesn't hold anymore and this function would now silently create a out of bounds pointer leading to confusing problems. All architectures have no more than 128 as vCPU limit on HVM guests, and have pages that are at most 4 KB, so this case doesn't occurs in with the current limits. Assert if the vCPU ID will lead to a out of bounds pointer. No functional change. Reported-by: Julian Vetter Signed-off-by: Teddy Astie --- Not sure if this is the best approach, perhaps preventing compilation if the vCPU limit is higher than what the ioreq page can hold is preferable ? xen/common/ioreq.c | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/common/ioreq.c b/xen/common/ioreq.c index f5fd30ce12..b2ef46ed7b 100644 --- a/xen/common/ioreq.c +++ b/xen/common/ioreq.c @@ -99,6 +99,7 @@ static ioreq_t *get_ioreq(struct ioreq_server *s, struct = vcpu *v) =20 ASSERT((v =3D=3D current) || !vcpu_runnable(v)); ASSERT(p !=3D NULL); + ASSERT(v->vcpu_id < (PAGE_SIZE / sizeof(struct ioreq))); =20 return &p->vcpu_ioreq[v->vcpu_id]; } --=20 2.51.2 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech