From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f176.google.com (mail-dy1-f176.google.com [74.125.82.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D30A7395DBB for ; Wed, 25 Feb 2026 19:11:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772046709; cv=none; b=KFzUTgqoxbI6MHKBL6NgQsr1QsPZ9eNDAJjNYC7+NlysvTIq3YeJQZM6rALqXsKxTzTy0zXSpn/Orkz9QHFE3138VJf3BgFTRf2KidhCAT6Et295EAVZ+7UADw1YEECbFOtaL3UQ/5KBVB77n86Rfh7rLeoCKzOD4/FfTg6VIRc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772046709; c=relaxed/simple; bh=FnDd5eNGT7mxmTViTVoSjme7ik4tMeLKewxwF8SBya0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=e+R+h+lGOtOVhcAOvEz3Xr5DcZ+CqaM0BR879a0e49jyh6CG1pT7z+94xv7l7ZXCJhfh8zFKLu72jQLU8Vv4MNLXb8/Clg6qFFzRt4lB8gBPW5w6QMrhHQX+vxh4mcZpw1aHeEpJ+Sx+EU5KnbQh8ELDuVwgl7TfKrkOMUs2JLU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=roeck-us.net; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=HmarjDkN; arc=none smtp.client-ip=74.125.82.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=roeck-us.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="HmarjDkN" Received: by mail-dy1-f176.google.com with SMTP id 5a478bee46e88-2ba895adfeaso17278eec.0 for ; Wed, 25 Feb 2026 11:11:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772046707; x=1772651507; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=z0HSZ4dYExbCoLjG4OZkeT7LbBNxZ6IbEkBrJwEZh98=; b=HmarjDkNDuQuIhFR8YXwyPTKMfwYtNo4apvOqzcnH7GdAqvQhvJKtNb3PnlLuT4tBM yXSpQi+6+PP1Wt4TmlPw0PwYEA9ZI21/IXtT9EkKdDAb47y3/vLZloGGipjFX3FfCGM0 mr/g9INDnsffR6b7WdbtLvRfK2drpsY/irOKiKrprPj9sdyXTNXuIFd0oqgav9831RZS JhT5U8BvBHGltz7mj6a813i2I7SF8ELrpRg9Ouu1K27pjJUTW0o43v9W7IsBV5068qXA QL8Q9LlnG4HCZ+XvXLVLvi0CdtNIzCwmyt+8p757niKecuGeQC44KjpabeH/dTSAyVQi pULQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772046707; x=1772651507; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=z0HSZ4dYExbCoLjG4OZkeT7LbBNxZ6IbEkBrJwEZh98=; b=l/oYjYC/LR/dAFEOqOfDsqPC0B+1pkHfsGWSK8jA+ElyE4QqEVhtcweKVGra6s+YYE bRLiBjNBHQL7EgXwYP4CtEPcmAPLvebRxGZHTx6JXiLX/d2kP5WpdYQG+MGw1DgY6Rvq JcZD8jhT/nA5YDLeWgNpzcTDy1hTVg4rXUS4GiNrw2WZ+0VNLBY62FYA+rwivUECtH60 HjNoKqh8nGXQ5KS2fnu/NZ8OJTA8VnYhO8WZBuHoR5GYtB6YPJxvpNIqmyHkhVKkHgPZ jDSITsbO9WW+RZNX3SqY0VopepHEiGyr/ZA7LQcZKqqLck9TbEg1mVqCmnrldYa6LfAz R3ew== X-Forwarded-Encrypted: i=1; AJvYcCUwq4xPVVFo7LSn2at43Lop8KALCoVBZ9w5pisbuZgzCERk9Fu9UF3eXD805F9b0H0xDzkyBcH8TpiNflU=@vger.kernel.org X-Gm-Message-State: AOJu0Yyf62tEWPEt1x+vWRBOS12C3xu9bdpgyMxPtK2HbqaOIfIZQuBa MvxLQ5pYPy28sb6cAMOXTmgruPiowCA6PqnwUOoMC7Kej/4eJf/LAOQN X-Gm-Gg: ATEYQzx1e9ryn/hpIV5YX0L5beB+s88a8HajMBubm/M3pN9BmSB9PP6F3Ky1KsXG3ZZ S3gAN707yvJm6caCoy49bvWevMcCN3b3+J/UqBqJqkigyGO5F4Wu1lq/KKqKzzP7WBQ062pZMAs FHdJaoFEuZsg2p/6bKRrkGz/5p9zJIk4lM8B+4708AWxcjkSdCLxiaqo48gxqfPqLyqos88Teyw OPkYY9lOLov2YjjV0V59y7aOL8mmsxbOMmYca6Hb7wWQtB3N9QpLVFTh1xUmY33I7zg3RYqjWc+ O9OhpwVTCWB8tJ92E8mDd0K+dpVl6c8STr4uf8j9P7jaxJ7BBVlv4Wf3K6Hk4HoItCibqggS8Du 1/HrQM1JJQ0fTr7Sh40m2iihWy/cmmTUP1J3QbQgjUNhA51r5tbcx9XVj7taNIQYj/b4ihzRrlG loZNqIH2xwS8o7Mcqs36E20wXx1riUV/7edOBPmDoq7caMA6k= X-Received: by 2002:a05:693c:3944:b0:2ae:5e93:b69 with SMTP id 5a478bee46e88-2bd7bd24e03mr6487750eec.29.1772046706806; Wed, 25 Feb 2026 11:11:46 -0800 (PST) Received: from server.roeck-us.net ([2600:1700:e321:62f0:da43:aeff:fecc:bfd5]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2bd7dc167d3sm10914523eec.24.2026.02.25.11.11.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Feb 2026 11:11:46 -0800 (PST) Sender: Guenter Roeck Date: Wed, 25 Feb 2026 11:11:45 -0800 From: Guenter Roeck To: Junrui Luo Cc: Ioana Ciornei , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Yuhao Jiang Subject: Re: [PATCH net] dpaa2-switch: add bounds check for if_id in IRQ handler Message-ID: <6027f2f2-43ab-41f9-9fd3-c91c4ae7a70a@roeck-us.net> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi, On Thu, Jan 29, 2026 at 12:55:13AM +0800, Junrui Luo wrote: > The IRQ handler extracts if_id from the upper 16 bits of the hardware > status register and uses it to index into ethsw->ports[] without > validation. Since if_id can be any 16-bit value (0-65535) but the ports > array is only allocated with sw_attr.num_ifs elements, this can lead to > an out-of-bounds read potentially. > > Add a bounds check before accessing the array, consistent with the > existing validation in dpaa2_switch_rx(). > > Reported-by: Yuhao Jiang > Reported-by: Junrui Luo > Fixes: 24ab724f8a46 ("dpaa2-switch: use the port index in the IRQ handler") > Signed-off-by: Junrui Luo > --- > drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c > index b1e1ad9e4b48..33f0842b5dc9 100644 > --- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c > +++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c > @@ -1531,6 +1531,10 @@ static irqreturn_t dpaa2_switch_irq0_handler_thread(int irq_num, void *arg) > } > > if_id = (status & 0xFFFF0000) >> 16; > + if (if_id >= ethsw->sw_attr.num_ifs) { > + dev_err(dev, "Invalid if_id %d in IRQ status\n", if_id); > + goto out; > + } An experimental AI code review agent produced the following feedback: Will jumping to the out label here cause an interrupt storm? It looks like this bypasses the dpsw_clear_irq_status() call at the end of the function. If the hardware interrupt status isn't cleared, it might leave the interrupt asserted and cause the handler to trigger continuously. Should this code clear the status before returning? It seems to me that it has a point, and that the code should at least attempt to reset the interrupt status. Please let me know if this is correct or if this is not a concern. Thanks, Guenter > port_priv = ethsw->ports[if_id]; > > if (status & DPSW_IRQ_EVENT_LINK_CHANGED) > > --- > base-commit: a040afa3bca415019d96a586b96b5f17b1f55a90 > change-id: 20260129-fixes-98a0f7607a88 > > Best regards, > -- > Junrui Luo >