From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (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 1F40F38552A for ; Mon, 23 Mar 2026 08:52:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774255950; cv=none; b=geksN45L6a5bAzRuc4AuyfC7VdyzfJeq/c5/hssaBXy8YooCvRI962onkGnp+knRSB1QfjsQwjTMdYrpv4lthIATxVaBDGAwhxAcvbSmeeHNfgK8iTZQ2JmfCAVmmZw/SeW2g8V7v+WekOSDnQ5megctOLVRrDbV1TqwXUZZvpE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774255950; c=relaxed/simple; bh=9v1HMebiUFD7NqApnl09itbULrmS3JgtmdGF7k1A8x4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dwEdguga7A0dtxdLaLfmjTGwlUVtzZRooQmmlOy014xBHlwmX6DpHI56A6amhLNECYa5tIhaqMXJTwoffnPUX8ifpO7Uv0fiIWO+nURsIRMMGlBU+xmq5vEE2Hr6b/xNNuCtHkr2Ronon3qBgmwt1B6SS9SLJ+kMD082n6KMMUk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=blackwall.org; spf=none smtp.mailfrom=blackwall.org; dkim=pass (2048-bit key) header.d=blackwall.org header.i=@blackwall.org header.b=IBjQ9zI8; arc=none smtp.client-ip=209.85.221.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=blackwall.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=blackwall.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=blackwall.org header.i=@blackwall.org header.b="IBjQ9zI8" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-43b48ac2727so3022786f8f.3 for ; Mon, 23 Mar 2026 01:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackwall.org; s=google; t=1774255945; x=1774860745; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=GqKpzbuA/S+8i7zqfBIIbpWVnTVfMXFfrKGWqBVGMaM=; b=IBjQ9zI8aqOg2v/jDeBp5lZnoAPYyxhgq7JlYdBewy9SiDw+Vh61g6gwbWpPpSRr3h aJRqGU6GRkQWp8w4lomlL/XYYBUx8k4mSw2QEUUUvZHadi1IcZB2qTGuM25HMQsmS/MN zmUUMdt1ArEBL6m2NYDgByDo5ECeFb4UO/c1ZTdWrJspld8VqEZSd72CL7ag1Dn/+o0l 9FEYHYERKqmXbtFYmo6+phnsuOd9seo/dEfOA6jiDR97wulcSEu5zxBox/+rJo62IqaN 3PxvjBRqgMW6jw/rCYt6/D9ZPoCXUOpyruUzopfNmhBzI0mgbMbuFczjXei67FEyCoVt 1c8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774255945; x=1774860745; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GqKpzbuA/S+8i7zqfBIIbpWVnTVfMXFfrKGWqBVGMaM=; b=lVLvN+fNYx20NtRI/b0lTeSE9UAbCYlBjpZ5ri7GKzdFiO+lbjB7KEbD7vcwMY+Uk7 VywXNXp1qrFiagPjI9afAKie0n1Fzvd0QxQjKfS90/U2fj4wXGjU6f7NUyQKSTJNlF62 Ivl7qOAMJAhZGJmzd3rFMA6z1ErhL1Z2w3fZD2XhLoT5VaiUvGo+jdAlt/GMwr3LcrNy qvmTmDFMoPit81RZEZo66I2LV5KJ7UK5/DnKPx0TN8eUcG44aG004nHz0+98TmAQ3Xc1 w41U1ydjiPt0jL3/buEi/Xw0NNPd9n96TGGmGq7plUXEjLvoHB8HT8eeOUwxHt75mfzp JE/Q== X-Forwarded-Encrypted: i=1; AJvYcCW1I4HJG7f35xGrn8BqLuD661OYGiGa5hsCS66xuOCun7BKqw10lhyHuhXT9o0BHxHMEZiS70b0NSXB0OM=@vger.kernel.org X-Gm-Message-State: AOJu0Yw7TF7F7VQ4WDRz9DP1jrKsczYWvzBtskasD1kadnSaHEHipVkL t3uYJV8Y0yqBwKht9jkSLURiBPTzklGJoAgzcZcV8dRz8ccJRj1cXFnY63ERecohGpU= X-Gm-Gg: ATEYQzwfD1zToR43cMg/IbyAtBSkU4ReKv/7YAZJjU9+DEW/pTi1wv3SxhZ6ZIqJZi5 mGOL5tv1ZPdRV+eZifiVvwwwQlAZVz1Nr6WR29ltNhrO6SKiDnWrIZ1Qd3KsNPmofdvY619jqAb bUvVVDSoBBO2RLpOuxGQ/se4RgkhDpb1Kyc7ajkb6ZLGo9rnRfcsw6uN4aUYj8rpg64F4xx/INT FJ+6UEXYB23UCb5bCECCNlEo7eEjznUMxIDgMDrCAjVz61hpRzp/GNiWsQ+t7lG1paRRyqtdwEP wTI7kRj5oKqsiJM9cboW06+GuHi+CYkuxM7BiwcMxWteriU7ctsvztJvTkyZw5bJn4N3hgwpNDV kvEnRO2NgW4MRKa6kUPUsWDmh4YwU/psFODuybLij5iWWzlNkKJAOuzDOMvAxnaw/qaduJVyK1+ TLKwWsA2fMbk8c7h0onClODD+YPivVrYWhyzws1vD20+DFcA== X-Received: by 2002:a05:6000:2302:b0:43b:4312:2ca6 with SMTP id ffacd0b85a97d-43b64242f2cmr18936468f8f.2.1774255945122; Mon, 23 Mar 2026 01:52:25 -0700 (PDT) Received: from localhost (78-154-15-142.ip.btc-net.bg. [78.154.15.142]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-43b6471a27csm29774775f8f.36.2026.03.23.01.52.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Mar 2026 01:52:24 -0700 (PDT) Date: Mon, 23 Mar 2026 10:52:23 +0200 From: Nikolay Aleksandrov To: sunichi Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, kuniyu@google.com, gnault@redhat.com, leitao@debian.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] net/mpls: fix missing NULL check in mpls_valid_fib_dump_req Message-ID: References: <20260323071515.1945612-1-sunyiqixm@gmail.com> 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: <20260323071515.1945612-1-sunyiqixm@gmail.com> On Mon, Mar 23, 2026 at 03:15:15PM +0800, sunichi wrote: > The attribute tb[RTA_OIF] is dereferenced without verifying if it is NULL. > If this attribute is missing in the user netlink message, it will cause a > NULL pointer dereference and kernel panic. > > Add the necessary check before using the pointer to prevent the crash. > > Signed-off-by: sunichi > --- > net/mpls/af_mpls.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c > index d5417688f69e..28bbea30aae3 100644 > --- a/net/mpls/af_mpls.c > +++ b/net/mpls/af_mpls.c > @@ -2174,6 +2174,8 @@ static int mpls_valid_fib_dump_req(struct net *net, const struct nlmsghdr *nlh, > int ifindex; > > if (i == RTA_OIF) { > + if (!tb[i]) > + return -EINVAL; > ifindex = nla_get_u32(tb[i]); > filter->dev = dev_get_by_index_rcu(net, ifindex); > if (!filter->dev) > -- > 2.34.1 > Why necessary ? Did you actually test and see any problem? RTA_OIF is parsed as NLA_U32 according to rtm_mpls_policy and nla_for_each_attr walks over all attributes in the msg which means it is set and we must have at least that many bytes available for the attribute. So how can it be NULL?