From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 204F81D45E8 for ; Sat, 14 Mar 2026 09:37:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773481057; cv=none; b=GCF9DhGid6xIoaz13eMGhm/KqvcjSEuImtMKZx/ml6lEbgV+w/7WKSSHk9aAOzpVjmR7JnzZcnb5+CYYdVMdDRRY+D5y8gyN2TCTO1v9jasma3N6IAp0TDxeeqV59vAjmKpfi9BHWUtzCMujDZp0ypp0w2wtGdkKNNgTQMbpGCs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773481057; c=relaxed/simple; bh=PW82vmyUoBo5SVpPvpbFQcYkYuhkW+kzsIfiM0ZCnUY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YPKmz+69iUhxHXeXZWBLERhq6mkR4eSR7Pfs1dZ/rw/UoDLDvTEV54E9tvspDG7ihVNrEAIqc6dhQ316ueADc8pCt0w6KjnKWOF6lk/7T8MZ1akf1lfQZCUP2LUR3XwOrxF0CRNyvgxmpbmPDNInixhxysdM+LUOQUEg8XPWQ1I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=googlemail.com; spf=pass smtp.mailfrom=googlemail.com; dkim=pass (2048-bit key) header.d=googlemail.com header.i=@googlemail.com header.b=BCtUQJE1; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=googlemail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=googlemail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=googlemail.com header.i=@googlemail.com header.b="BCtUQJE1" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-485410a0a8aso26770555e9.2 for ; Sat, 14 Mar 2026 02:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20230601; t=1773481054; x=1774085854; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=VxsA2YZ471Q/xGiQuKEeLiqvlRJiwCfIC45xI+go3Hg=; b=BCtUQJE1Rhvg2C17QMxGnp6flTDLEW3x1RPaYtxhVGqxIE21LJeOMOkPUHDuJLIVRA O/1IssRmLAFe0LXojhHfrt7WeAmvyXb631QakA46BvEt+RB+pIZZ3x5OjfKQaMPinTA7 NBPUeweElMXn4MpSyFsQLtwGu951wZt6f8rXmkYGDCB5Km1tvd6QbYuFv2ikAN2UQ6d8 VFhwBMmMK2FmeCyVpd1YDD3iazX/heb7XsrMGg+2WzCZrrg9hgU1nForLEaHiXlYOOe9 OSusbP5LQrXZQLhJv+3QCTAVbePFBqgNEymJ+yHJJfmW2+n+v8enwMmcY5Mm+bUjtsj7 Qb2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773481054; x=1774085854; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=VxsA2YZ471Q/xGiQuKEeLiqvlRJiwCfIC45xI+go3Hg=; b=hPEc1LiJ1M0xE/kXjNtyB5L89jr1iabqQAmvifUALrASnnrfBDMVZdPIo3Gb5B55or Trrro99LlcHteZAWsRGrzpHaSSQKMV6BvE3MOsAPLfyzJ/9peGAh6Kx3KKNZh74cVXQn kizxAw+nW3ocqDo+9NQEHqdrrmL1TuZwM2UL3GNjMBRNSg0TO2jBTmVHB+LABIPnwcAG vmHqw6oeUrAB4GoWtNku7cE8P6rp2Mr+yIbeqrwgNvNvue7L4BhsHV0mt0p1TDmVTM6+ wlJtfgEZK1uEYbhHeALqNcz2vDuBUQwQfPbqCcEcGH+Vs9Xdgr0ITAwTXn3Je+1DS6ge 6MYg== X-Forwarded-Encrypted: i=1; AJvYcCUp6hsNMD6y/qRA5yKmCQTPdZJi7jLuSEd75lCXPBpZ9iLlFSkLv9zMnndOb4L+qPEQkoDAyUpv+MA5Rz0=@vger.kernel.org X-Gm-Message-State: AOJu0YzuhpZG42JnpEgd9k6v5Kzd3PI8NxEgoLtT7fbePr0/nb0TxzE5 J+GBbPaC6G/sezjpLWGWJ9Ba/ibxEgC9Oh8/lnW74qZYNeaEch7dio+N X-Gm-Gg: ATEYQzyxRV1fREid1iZ1kPOk8jdpnbnd9HDvvhO/GgrQQxGinrX78yW3rst/agV/hPz ommmZNBZbStXomanc8AefEdYot4qLQ/k2/fiaCMaDtkQIpG+3w8fLMQGsGZs5zJbbmN8OQdiYDq OB6PkqdsMnh4ElPNhDy388bIxpyDdBhWP/g9K+Lh63DvYewByNAsxwdooo7ERG0R83mpL2gL2Bo AKXeU81exMkQGpTcNp+42zn7tggHjJ6Fm1u4MbbFkAHmaPNJ3nCilL3nyYlC36bcNdn1+NuCnaw 1ERi8VpXZkXILaleT7QhO4BuNuLmJcWcaiXKFVmIEhkchvfKg+lwwWdj2TRQGqyxN3SmPSiu96P 7gVheGrTwW3lv/bAQht2DZvoRdW5+KGEgozGH9jgjZm2rTT0BvF5IoA3Z94VqrSS1DIWiwGmQO3 WAu99ANIbTzGlDOKE4OA1N3Qo0p02cDMczifI/kSEvMaA= X-Received: by 2002:a05:600c:1388:b0:483:badb:618f with SMTP id 5b1f17b1804b1-485567050dcmr98705965e9.25.1773481054070; Sat, 14 Mar 2026 02:37:34 -0700 (PDT) Received: from ccde1gl2920.wdf.sap.corp ([130.214.226.57]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48557c89186sm113974345e9.1.2026.03.14.02.37.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Mar 2026 02:37:33 -0700 (PDT) From: Marc Buerg To: ps.report@gmx.net Cc: buermarc@googlemail.com, elias.rw2@gmail.com, joel.granados@kernel.org, kees@kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH ] sysctl: fix uninitialized variable in proc_do_large_bitmap Date: Sat, 14 Mar 2026 10:37:25 +0100 Message-ID: <20260314093725.12429-1-buermarc@googlemail.com> X-Mailer: git-send-email 2.43.7 In-Reply-To: <20260313121708.137dae22@pc-1> References: <20260313121708.137dae22@pc-1> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hello Peter, Thanks for your feedback and the idea. You are correct proc_get_long() does not set @tr if @size is zero, therefore, left in proc_do_large_bitmap() should be zero when we expect @tr to not be written to and c still being uninitialized. > Would the better fix be: > > diff --git a/kernel/sysctl.c b/kernel/sysctl.c > index 354a2d294f52..89db88552987 100644 > --- a/kernel/sysctl.c > +++ b/kernel/sysctl.c > @@ -1427,7 +1427,7 @@ int proc_do_large_bitmap(struct ctl_table *table, in= > t write, > left--; > } > > - if (c == '-') { > + if (left && c == '-') { > err = proc_get_long(&p, &left, &val_b, > &neg, tr_b, sizeof(tr_b), > &c); This would explicitly fix the problem as it enforces that we only check if we know c contains what we want to check for. Fixing it like you proposed seems better to me. I am somewhat conflicted because leaving c uninitialized allows that a similar problematic access of c could be made in the future. Initializing c could prevent that. I also do not see an immediate downside, but that could just be my naivety. Further, that part would now behave similar to when we apply the default hardening configuration, if my understanding is correct. On the other hand, we do not read c later on, and I do not see a reason why the function would change significantly. Still, it feels more defensive to me to also set c to 0. In the end, I am not so used to the kernel coding style. Is there anything that can be argued against providing both? If you think this is unnecessary I am happy to follow your reasoning and go with only the check for left being non-zero. Kind Regards, Marc