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 7DC0919A2A3 for ; Thu, 4 Jun 2026 09:21:21 +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=1780564882; cv=none; b=SwTrpAs7NareqWLgxQKabAQbMcMXwd6srxgao0tJAiMa7gGXzrqimVQDjiCqRtdCCoJZbcfAhDfHO/PXDyY4i6fwZYz+AW9KmF3aAtAnQlx/YmdWaOsSXO5wuCOHaRXAzsSJUjuAd1Oncqezny+OLWq2qYmkRClz84K3WhsHT+Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780564882; c=relaxed/simple; bh=2vqmCQS4aPWjnswsEAV7Pf+ET2M4MPxRVHxE7nuRyyc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=UpyCq043NA7nWhlOXBH9+4qRjcIfRvhjKrkRqHIpoNxIAotVI8bbgwPxagR7xTAIxeHSy2mO5UQ29BH5mvZmLhuPAVoXRhfxvs+X+1jpvG192h5y4S6PL7bvI1rS9qrYuBx6xi6rc3+4cLWYpdqrYCucOa1PbLrzmAa2T5DmxYs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EF+bKFKc; 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="EF+bKFKc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63FEB1F00893; Thu, 4 Jun 2026 09:21:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780564881; bh=tr84TP5c9/EKfIqfcOWASH0/qw8l5IXOdg3NjDD9ey4=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=EF+bKFKcY+nZBShGidsieS/rb2nRkzXA+I3stVHc8N0asB/pDZrIexbDRtiA6LjIx 0TWmoC6ceFIkfI8iR/5gByI4/eBtUrsY0LG1lpGua5r4QmcmvGQxBn6pET9spby4uP KIcBIuWqgZbTyeOQo/n/avJkSW8EuL1z36WgqPrbx0suCGqXZGTkUsgyMvjdIwaFNd 6FASgf/Z93kcLgMeR/mNMsE90XurP/UJjfQVzrAzfD5B50ZJhza+0rXWYlAPrDiOBN tFafSxnnxwb1uFFCxw7dK44LZvgHkhewRSunSgIf2xUPjnEiSc0ZKtWipWBcgZuAar Eb7NrQSwqg0NA== From: Thomas Gleixner To: Aaron Tomlin Cc: neelx@suse.com, sean@ashe.io, steve@abita.co, mproche@gmail.com, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] genirq: Enforce monotonic increase contract in irq_get_next_irq() In-Reply-To: <20260604020149.1148697-1-atomlin@atomlin.com> References: <20260604020149.1148697-1-atomlin@atomlin.com> Date: Thu, 04 Jun 2026 11:21:17 +0200 Message-ID: <87fr3264qa.ffs@fw13> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Wed, Jun 03 2026 at 22:01, Aaron Tomlin wrote: > When an IRQ descriptor is corrupted in memory (e.g., via an out-of-bounds > write by a rogue driver), the descriptor's internal IRQ number may be > zeroed out. Which means the system integrity is compromised. > During iteration via for_each_active_irq(), irq_get_next_irq() relies on > irq_desc_get_irq(desc) to retrieve the next IRQ number. If a descriptor is > corrupted, this can result in returning an IRQ number (e.g., 0) that is > strictly less than the requested offset. This breaks the fundamental > forward-progress guarantee of the iterator. > > This contract violation causes catastrophic unsigned integer underflows in > callers. For instance, show_all_irqs() in fs/proc/stat.c calculates > padding using (i - next). A corrupted descriptor returning 0 forces a > massive unsigned underflow, trapping the CPU in an extensive loop inside > show_irq_gap() and triggering a soft lockup watchdog. > > While the underlying issue is a memory corruption bug, core iterators > should be resilient against returning values that violate their own > mathematical boundaries and induce lockups in other subsystems. Seriously? If memory is corrupted and corruption is detected, then the only sensible thing is to panic the machine and not papering over in a particular instance and hope that this is the only side effect. Thanks, tglx