From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f51.google.com (mail-yx1-f51.google.com [74.125.224.51]) (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 D8C622BB17 for ; Tue, 30 Dec 2025 19:35:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767123349; cv=none; b=j4wXtsJ7LTaPmAw7v6o8yZTvQgfSKIobspm79k+2wkOXjLKY1/bNf2WVDY0RU9Zlf6ivA9USCQLYdK0BtNJRI8z8A3fuERDnoylP2AH5PrvC4rKM80zHMt08AlQEa2/qRxjX2runyUk3Ah0rHt56O4Xu645Xp29zghExyMgsi0Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767123349; c=relaxed/simple; bh=2fZeFI8ChalvAPPCVG+1WXDPJh0uoiPyhnhHPGeZFas=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=SPByLK56IfUYfXvc4rUbJiknuWlhOovxKCRrbv4ltXnDe1d/yIKPZSCQOaYyIa80H+fh98YJtUJhIiDUA/PLBqZzafMJFm+T/q3rCM464MixPvS6/+l1g/ueQrNIE8DKQcJwXTDroOTy5cHVr4G/mmLLxISSTccGuqumUz69OFc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=V51zEPOV; arc=none smtp.client-ip=74.125.224.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com 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="V51zEPOV" Received: by mail-yx1-f51.google.com with SMTP id 956f58d0204a3-6446c1a7a1cso8411101d50.3 for ; Tue, 30 Dec 2025 11:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767123347; x=1767728147; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=GbLbN5qo8BhCJ3h1f/M+MLdJNxCUmuM3GwhK4z+mTLA=; b=V51zEPOVHXhb5idn+Y2psWcL0uZLT4o1RLbTrzzj+FzbwJ+yF3yBJaUXmxy0y/QOo8 cmA7/2ODa7NVlS6eaWqwNr8E2b3X4brSS4YFxtJROuBi88PZf0xZiz6zy8DHNFzEcJWb onuwqgXd8ckYSuuHeUFHJY5KjFoqxYC5y0J1B4ogpAlxr+lUW3QNkhGWLcHYWTWalzF1 Nu4oT+T+N8/kT8mVqJQfN3/OqzhtNT5K821J+tOPHecwc+6jQQGaRFYjNzlSMULOgFtf V3JziBFsjaLXp1KwtDAFWUur8br+tW/8iqRSow1zAlAFcknw5yEd8SuuevntaRhDDSvi mMGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767123347; x=1767728147; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=GbLbN5qo8BhCJ3h1f/M+MLdJNxCUmuM3GwhK4z+mTLA=; b=KuRdH/yfA372papJoBeU0arhj7kb4/TxjCQJmpRD4U+QKCpySdMFs5+eO1bsCnuCU8 3ls5NEMNAkEFPKW5ZSeBJYReitkAMRgBguRzSrE6zZl2V5Ff3zm2TLU3HuJqErlO2d5r Nt8cqJMOh9xSpw5RpLKGoH04MGuITrQZO7MaL31ShWu82ERYLxkBdVmGW1uyLt16Zjem IaRQlTyswmokxaqXBZUzWhc/kQV6WnpuGFxruhjFjagrmI208CeDvBI198zp3zarV+ai r4OujstLctbVHWkivd+AiHS1SlEtiaoQ0lzierP7gv7OsgCAYX4Aoh5pQ5u+EG8bZ1g6 YsxQ== X-Forwarded-Encrypted: i=1; AJvYcCVkcz1fLSsaWbd+WjtpX6CkGlJQqQvUtVYxexBWokuHdfSEzt2e7UoQW9mBJ4hfbaYLo6p44RcioqhMyyE=@vger.kernel.org X-Gm-Message-State: AOJu0YzC5ALoajQR+eqKP0bHJ5PHUodXNz6uRu1R5/e7QQFWX2UagAbO opSBa0N2t8E5vE7tkkKgrMzyv7VzcSrxf+sxG0kiRryJxawlKdoK3xDS X-Gm-Gg: AY/fxX5ttn6MH0bSsbd6TxtK8W4z8bqIld8skQUCXUTbd/saQ3/in+JRsdj7t4+zl9Z xY9Jhj0uqEx62KVMBGZqp7ZiYlXb3nxhp4CiXR8gNvj3pJTEMGh4VM4XpL5ItJ3cEAObBvlQR9s 56B+NNOIp7g3zY3Ja5dHp3otbrwc4H9kPCicezb9zVNlrbuPXrEgRppInGMXcu4W4O9xe0Pr7n5 AV/t4/qx+2o3DKQBPC00qjvo+4+n7Eo0NA2CQ8pTOUNG7yE1S8wcY9+Ee8emkmCJk4rmXASsyre Oy5BSe4NEINyA703W8sW46AUCSMvXb76ksTJY3r9j4SZMsQBQ/P7/E6hwkC1wK711U8F9j1T/Rt s18j/5iRnL0ezNwmMX2/xfsjcA+naZQNqmlXRCkxq1QRoqpd5VK3d7DNZ1Rc1qEeYY6Njg/+/kp BRXHhKNjh5v6+Z0BS9Zi6RHiHDUk2Ub1YERA+GPwxE0FxJm5P05QfDu0Gz0XA= X-Google-Smtp-Source: AGHT+IGskJuGH1ry4lW++SW/O5+eFpbYgJV1JB4rR83UjJdJAPT2DRTtF+kwsfPk5XXMD9qFGe8aFQ== X-Received: by 2002:a05:690e:1281:b0:646:7d1b:614f with SMTP id 956f58d0204a3-6467d1b653fmr24659651d50.56.1767123346798; Tue, 30 Dec 2025 11:35:46 -0800 (PST) Received: from gmail.com (250.4.48.34.bc.googleusercontent.com. [34.48.4.250]) by smtp.gmail.com with UTF8SMTPSA id 00721157ae682-78fb44f9a42sm128149897b3.29.2025.12.30.11.35.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Dec 2025 11:35:46 -0800 (PST) Date: Tue, 30 Dec 2025 14:35:45 -0500 From: Willem de Bruijn To: Alper Ak , davem@davemloft.net, dsahern@kernel.org, edumazet@google.com, kuba@kernel.org Cc: Alper Ak , Paolo Abeni , Simon Horman , Kuniyuki Iwashima , Breno Leitao , Willem de Bruijn , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Message-ID: In-Reply-To: <20251227073743.17272-1-alperyasinak1@gmail.com> References: <20251227073743.17272-1-alperyasinak1@gmail.com> Subject: Re: [PATCH] net: ipv4: ipmr: Prevent information leak in ipmr_sk_ioctl() 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=utf-8 Content-Transfer-Encoding: 7bit Alper Ak wrote: > struct sioc_vif_req has a padding hole after the vifi field due to > alignment requirements. These padding bytes were uninitialized, > potentially leaking kernel stack memory to userspace when the > struct is copied via sock_ioctl_inout(). > > Reported by Smatch: > net/ipv4/ipmr.c:1575 ipmr_sk_ioctl() warn: check that 'buffer' > doesn't leak information (struct has a hole after 'vifi') > > Fixes: e1d001fa5b47 ("net: ioctl: Use kernel memory on protocol ioctl callbacks") The commit mentions other similar cases. If this is a concern for sioc_vif_req, then it likely would alos be for sioc_mif_req6, which similarly has a hole. > Signed-off-by: Alper Ak > --- > net/ipv4/ipmr.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c > index ca9eaee4c2ef..18441fbe7ed7 100644 > --- a/net/ipv4/ipmr.c > +++ b/net/ipv4/ipmr.c > @@ -1571,6 +1571,7 @@ int ipmr_sk_ioctl(struct sock *sk, unsigned int cmd, void __user *arg) > /* These userspace buffers will be consumed by ipmr_ioctl() */ > case SIOCGETVIFCNT: { > struct sioc_vif_req buffer; > + memset(&buffer, 0, sizeof(buffer)); > > return sock_ioctl_inout(sk, cmd, arg, &buffer, > sizeof(buffer)); sock_ioctl_inout copies the whole struct from userspace, calls a domain specific callback and then copies the whole struct back: if (copy_from_user(karg, arg, size)) return -EFAULT; ret = READ_ONCE(sk->sk_prot)->ioctl(sk, cmd, karg); if (ret) return ret; if (copy_to_user(arg, karg, size)) return -EFAULT; As a result every byte of the memset will be overwritten with the copy_from_user. > -- > 2.43.0 >