From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (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 1CF4A37E308 for ; Mon, 23 Mar 2026 08:52:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774255949; cv=none; b=gJNBoJIVN26CHEabH2UNxR1vnYnnUKg2bjfwB8E2a0eO5uCYej9YgnU0vL/abqDxcoxhjeWA9eMPPw56uZSU4KHWf3LMFWTyof+/axN8y4CMsh7l4Bpb4TjaAjelMcwv6W4s5KuK76bHAjIPLcFyGkbFXEIpD3O3keSLmts+P9A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774255949; c=relaxed/simple; bh=9v1HMebiUFD7NqApnl09itbULrmS3JgtmdGF7k1A8x4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=II3ArO90i0zplJa4J8o4rB1msJpuaG/Da8jurqI/CBAY/PUqq3sZkh/nit+0AIDufcX7X4vYrkKOmxir05mpfBIOKoXKMmH77n8LsDrZny/gsn1ZqzHulf1zIWtRbfnlcrPFmjQh4gGmWhnMsJ+/L1lsLPGWQ46WraiN4PGG3dM= 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.48 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-f48.google.com with SMTP id ffacd0b85a97d-439c6fc2910so2871650f8f.0 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=DQ1RlisOBKt9S9RgCO2GjzFIiVjMTcGaRXQqkBpzNLJLN2jUPvJcrjb3yST0hvJuuu BnHdaNseYwJnyEOwlo608xbg15rVaWBWmn9r7ToNYYRJFYUZOypoKtvrG7FsV6AM7pvY GNalJGF93AMBCvuhITu6HdSzM2RxjZdomUOkQS+K26o6b0zkpy0K3Wy7ASfe+S3vsa6U 3OYt9LoKsZazZyTNgtNampwIDPwEduen78vLkQvATjum+4MqJPRj3aQFoUZ4RB5XALgF hobn4HD4A3qtylI9xBABC4G3g+9VhMgC0aHhAgerQlONCK4HPQFS87Hrf4EkVbhS2KZv 0Ubw== X-Forwarded-Encrypted: i=1; AJvYcCX6fTmWzimxBAbSaWRgo+sKyuaLpoVh4vPbf7R++zE/LBVZghre7T0Lb2UPmPwxHcZX8Q/M2cY=@vger.kernel.org X-Gm-Message-State: AOJu0YzcFq1J72AqfparkldPNWYfOfAk6W/AGFVJsitUYf0UueoVTOJZ A6whPpPzaSpfjWKuLrKULGqlp2onA9exQPCgshMc0fEF7qE/OixlXAjRHeqLIZ0+YuI= X-Gm-Gg: ATEYQzy3dkQhWc1lrMHYOftd+rtvZKEY4ck9AtQ3GlgWF2SvemZCXuFBu/ngOWiYEUT Z3+NevRbDnVZyqSlTXVcZ3/JUvv0PdbDOV6X7SbOI2wsbf5Rz3rpYMqDUxwPK0McldWOS8XU5B8 ZrmAaTrFMAbJPo8fmO5mNIx+ieKdB2e0p/4jy4fpY3+GkQpiGS1dcVriJhzgITbgJocxoWyyrac UvHNobYpnHxxRm2avKiS0/ewspnqMfn49FC+dpGZb4H43SXMFkNruDByoifXYmpVdVPvaChpJNd CXxbiip8qKxGJGknJxQEGUxAX5Erm1PpAFg425VYWmtWTPlksJbu5b6G5KzElQprgyVS+MJo1zC JJPwIvq0dEG0y5q4HJcP5LGGXMv95DrN/SlHPjWAz7jsmeodBPE9dOw291qyZkMliImXKi3KU5G O59el2fJkeyFXjM/eTnPFMQpqm3uRaVv4uUnB72/OZbww8Mg== 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: netdev@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?