From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A6DC63002DD for ; Sat, 23 May 2026 09:53:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779530007; cv=none; b=msbZzUjrPp2VDUYrl81ehzasW8Bu7lG41Rz281D8OMYFJO1lWTDfq10t4BNoIVjZr48gf2z41JODMg1P5KYA2Tg0zc/0/NiWYMWvCbe4/ydyIzWg3MEgjowI/GLh1zkPcqLw45fATBqquFXS/MCChH7vT4VVrFr3ci9uMGXXDr8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779530007; c=relaxed/simple; bh=kPAKSJLHQ30cIcHATbpFmb++HfDPTsMVXIB3L+B3Syg=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=NMF+3houaZLyu9zyeta4w7PsoBn5lrZSjZkUhNtP7freLWwUrKZVHI0H6OVQaH74EgupClHwoaU1oDUlSm0j0NkiC36lBnDmXeQ/0aVKgr5kWLpvkqbzM7anLZ56EC8YXj6u4H7xWEkWlwfcMESgLCEmXVODSndX9DVY72WRTkk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UIPYFyte; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UIPYFyte" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3B6E91F000E9; Sat, 23 May 2026 09:53:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779530006; bh=uwRJUUfj/z00/IoOBCweiKTZBo4dheyaDimJf55EYM0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=UIPYFyteb8WTsavnSWsQvw3mBW4Hv2AoXLhxeruyDsa/z65S7R/t6S0VQFyFPea81 s2CImTXQKdWiQCbOt57fUlE3F8/+lUhr8anOQ/cymNiLIy6X8vQP3/lV54EovluQnM 4FVUCCIeF3vXJguyaKE30swNl80itDJ4MtpYTZMyyWCz4DCqSEEYsTuNQTBUZ/2QL/ Hfp4XX6jPFzEvLG3FOrUqON/pjJG0W5K1CqHyLyt8criq4IpC8iXIHacdD3CJY86F8 d4q0Jz0EvTd+KfqdayMHq++ct+X1nwmcoDFncirfNsC6qpcJEcJoTVNzt6uRAvCotu UsHvGLhiKSiag== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wQj2q-00000005VxA-14y0; Sat, 23 May 2026 09:53:24 +0000 Date: Sat, 23 May 2026 10:53:23 +0100 Message-ID: <86zf1qv4do.wl-maz@kernel.org> From: Marc Zyngier To: Mostafa Saleh Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, tglx@kernel.org Subject: Re: [PATCH] irqchip/gic-v4: Harden against bogus command line In-Reply-To: <20260521130503.4103369-1-smostafa@google.com> References: <20260521130503.4103369-1-smostafa@google.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: smostafa@google.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, tglx@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 21 May 2026 14:05:03 +0100, Mostafa Saleh wrote: >=20 > When accidentally setting =E2=80=9Ckvm-arm.vgic_v4_enable=3D1=E2=80=9D on= the wrong > setup that has no MSI controller device tree node (it exists but > not used) and GICv4, it caused a panic as =E2=80=9Cgic_domain=E2=80=9D is= NULL and > the kernel attempted to access its ops. When you say "that has no MSI controller device tree node", does it mean that the ITS has not been probed at all? > > Originally, I hit this on an older kernel, but was able to reproduce > it on upstream with Qemu by hacking this unreasonable setup. >=20 > [ 33.145536] Unable to handle kernel NULL pointer dereference at virtua= l address 0000000000000028 > [ 33.145658] Mem abort info: > [ 33.145751] ESR =3D 0x0000000096000006 > ... > [ 33.154057] CPU: 1 UID: 0 PID: 295 Comm: lkvm-static Not tainted 7.1.0= -rc4-ge3f15ad3970e #5 PREEMPT > [ 33.156922] Hardware name: linux,dummy-virt (DT) > [ 33.158780] pstate: 81402005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYP= E=3D--) > [ 33.160340] pc : __irq_domain_instantiate+0x1d4/0x578 > [ 33.162602] lr : __irq_domain_instantiate+0x1cc/0x578 >=20 > Add a hardening check to avoid the NULL access, and fail the VM > creation in that case. >=20 > Signed-off-by: Mostafa Saleh > --- > drivers/irqchip/irq-gic-v4.c | 3 +++ > 1 file changed, 3 insertions(+) >=20 > diff --git a/drivers/irqchip/irq-gic-v4.c b/drivers/irqchip/irq-gic-v4.c > index 8455b4a5fbb0..7e39f7eae85f 100644 > --- a/drivers/irqchip/irq-gic-v4.c > +++ b/drivers/irqchip/irq-gic-v4.c > @@ -159,6 +159,9 @@ int its_alloc_vcpu_irqs(struct its_vm *vm) > { > int vpe_base_irq, i; > =20 > + if (!gic_domain) > + return -EINVAL; > + > vm->fwnode =3D irq_domain_alloc_named_id_fwnode("GICv4-vpe", > task_pid_nr(current)); > if (!vm->fwnode) I think this check is a good few levels too late. If you want to fix this, I'd rather make sure that kvm_vgic_global_state.has_gicv4 is reliable and covers this case. Which means making sure that gic_kvm_info::has_v4 is itself reliable. If my above understanding is correct, I'd expect the following (untested) hack to help. Thanks, M. diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-= its.c index 291d7668cc8da..e6b9fee1b6786 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -5838,6 +5838,7 @@ int __init its_init(struct fwnode_handle *handle, str= uct rdists *rdists, =20 if (list_empty(&its_nodes)) { pr_warn("ITS: No ITS available, not enabling LPIs\n"); + rdists->has_vlpis =3D false; return -ENXIO; } =20 --=20 Without deviation from the norm, progress is not possible.