From nobody Thu Apr 2 23:56:16 2026 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (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 7BD19309EE6 for ; Wed, 25 Mar 2026 22:30:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.47 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774477824; cv=none; b=Jo0aBc4jAfF5IO1bCHVm+A+/xAfpDgRBUwWbCmNhdGPtBRyv41GAT3DJpV1nuE7jzjA1J6VA9d2YtYOlnHuyXlYlNA+obdmReAC2j0BlAefE4y5yqHyyOTkxTcGhjqG8ZX8pTDYeBwJnDQ83a2OoX3nLzYuv0BNoZVfcJDaCkaw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774477824; c=relaxed/simple; bh=aVsJnN7w8bGYA++sn11zM0enc+DQ6LpFZuNiTAz/6SE=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=qpH3UiPz8gjGrs0kDlsjpZyRymc2MonrVhj7sJ7Pf9z8pzuyqZi7Rxa/mQxiDOmrvCMrP9X9BNG8ptGM3agrG5M7bJBU3MWJb7UUTeQWjBpqL5gOd+2J0Qpj9hRLBDcZ1bP4BPyY6VxqOo+rDl60MkNULcaxqs1qmtoD5LSZJ70= 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=lJoyitPq; arc=none smtp.client-ip=209.85.128.47 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="lJoyitPq" Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-48334ee0aeaso2930625e9.1 for ; Wed, 25 Mar 2026 15:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20251104; t=1774477821; x=1775082621; darn=vger.kernel.org; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:from:to:cc:subject:date:message-id:reply-to; bh=vDxNd9ffxWopSnwz8xRnL4Pi1cvcdDlFkiCHaQSotPc=; b=lJoyitPqr0jm+6Is7StsaQbHmWD08GsP9Z4N7pbXFJCqCL2BGo83GklESY05U9S2N1 M7xi/jU9DFtowXxUofDtkMPRVjtY1Xa3sVwUE/kkgDSdOrkkAI7bUnt/mJGQL4QR7K04 Cd3FH7uqQMp1+CqccxR2rp67DZqTDWZ+HrwzXq/1DmYTRRfGfbQOywEqXOgn/zTVP+7U vMGx2wwmulqPz+jDdO5TDbLDNWOOqXKwGOK/z6QT9RIxZXL3UebjILYqDnLIrzMcGC7d 4AeQWhVFWKvAACK5x0SfyTpzPBAzq7qH2fXKBir3XM4dlHg9A/jKHA20DkKO4rhg7Uuw yjqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774477821; x=1775082621; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vDxNd9ffxWopSnwz8xRnL4Pi1cvcdDlFkiCHaQSotPc=; b=m1BolgdJShkK6Wbox1XF+7DXaumxvhU196hjELgw2lKbi9NsUvK15YAtrvizcwcGhx 1gAgN1QlG/d+Z/O78Kt8rT3Cy88uDI9A9k2vNMrSl7GjaIp0Rl4z1PEyUpxVrDyg4cLd Xa9/HByaV/RWo+YEy4tP/Il1CY7bc/gm0Q8qFn0XdfH7WBOb13X31cRLuVSZRCuEjpDm ewN5oCSUrfOnWDbzvY2vG5kny2ZyGT53AzdkW1Ls38Gsy0zN65b9Zfy6rbo9B6zM5o/R Do1umfRShLPZCN4vLnTpkpJHQrAlUSQ8v8lhGUjRpjD5Gj8dkVH7CNcIIVvxs6Lpy7Hy T7Tw== X-Gm-Message-State: AOJu0Yyfq0KBY3myFwcO4yhaVGeLb4ryNX/vkBcXxPQ18UMHyQkfayIg Re+ibPpa8dJAvNagufPDazWRy1OOMLvR9qq0R6Tt2/3HcfD3/RdeX8/S X-Gm-Gg: ATEYQzzMh/VnonfWgosSc8cxXIbeoYr7WB1wFWyanDOIJmun5MUBLYpTDOutvUcoZJi 4PdK6TF4siTzZQwE8MYt1Mdf0Qth8DmwZmLkbNMD5Zmp0fi4e/P7ZytiDIzYSYdgAiZrsosHHCd Y/OnG+k2RDwEkpJNkyV/AbrbKG7zv23bBUBreiDxTukhktH1b8eV6gX3whYgRMSHjQBnZlnUVTJ 680O5mEtqxJ8qBS+3citWulhflGIFlCyfyEPnQh/EyxtPvafdjUzCEyX2x6VLyYdy4wVjzRoQJk RC7VjhwLhNpZvw1O6+PhtOIu+Nd90QvulaHLIjec63QDC6P5YvyvVPHrRj99M2HZ7aYmrs2TK3p /GPeIOU22dy+sSeaigmHtyktvhqhlu7zOQnUWD6MtEXZDqxpvynl/69L7LpteHf/7D8ECEjUZu3 rEMoZ5GBb1WCNvl/yQh94= X-Received: by 2002:a05:600d:16:b0:485:3a27:a961 with SMTP id 5b1f17b1804b1-48715f03047mr57886105e9.0.1774477820260; Wed, 25 Mar 2026 15:30:20 -0700 (PDT) Received: from [192.168.0.108] ([2a02:8071:5392:3220::bcad]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4871fb382cbsm11033625e9.5.2026.03.25.15.30.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Mar 2026 15:30:19 -0700 (PDT) From: Marc Buerg Date: Wed, 25 Mar 2026 23:29:50 +0100 Subject: [PATCH v4] sysctl: fix uninitialized variable in proc_do_large_bitmap 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: quoted-printable Message-Id: <20260325-fix-uninitialized-variable-in-proc_do_large_bitmap-v4-1-6fbdc832d9ba@googlemail.com> X-B4-Tracking: v=1; b=H4sIAN1hxGkC/6XOTW7CMBAF4Ksgr+vKPxAaVtwDVdFkPA4jOXbkp FYLyt0xrJDaFV2+p9H75ipmykyzOGyuIlPhmVOsYfu2EXiGOJBkV7MwyjTKaiM9f8uvyJEXhsA XcrJAZuhDvYxyygk7l7oAeaCu52WESVqFDfktoMadqMNTprryQE+fNZ95XlL+efxQ9L39F1e01 NLuwBnnHHijj0NKQ6AROLxjGsXdLObZ2b/kmOo0zvcayIP52P/p2Genfcmx1WnRo/W+UajaX86 6rjfb7RW+yQEAAA== X-Change-ID: 20260312-fix-uninitialized-variable-in-proc_do_large_bitmap-30c6ef4ac1c5 To: Kees Cook , Joel Granados , "David S. Miller" , Octavian Purdila Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Elias Oezcan , Peter Seiderer , Marc Buerg X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1774477818; l=3861; i=buermarc@googlemail.com; s=20260312; h=from:subject:message-id; bh=aVsJnN7w8bGYA++sn11zM0enc+DQ6LpFZuNiTAz/6SE=; b=/Ja3bMOgnnvq78cfu0Z01cSImLl9icRmmXeyQQ+jNmjt8nqD0RK7o2W8wM+zODqgWUnT6/vt/ 1V3e8gfRfztCGaWSbyFiGpEL7RSCFW8kxF83T4gnlQH1B613nteeA8K X-Developer-Key: i=buermarc@googlemail.com; a=ed25519; pk=kBZIEGh9yNUzqCz87kygF7XqwPxTWvwm4+HUrOuckyM= proc_do_large_bitmap() does not initialize variable c, which is expected to be set to a trailing character by proc_get_long(). However, proc_get_long() only sets c when the input buffer contains a trailing character after the parsed value. If c is not initialized it may happen to contain a '-'. If this is the case proc_do_large_bitmap() expects to be able to parse a second part of the input buffer. If there is no second part an unjustified -EINVAL will be returned. Initialize c to 0 to prevent returning -EINVAL on valid input. Fixes: 9f977fb7ae9d ("sysctl: add proc_do_large_bitmap") Signed-off-by: Marc Buerg Reviewed-by: Joel Granados --- When writing to /proc/sys/net/ipv4/ip_local_reserved_ports it is possible to receive an -EINVAL for a valid value. This happens due to an uninitialized variable in the proc_do_large_bitmap() function, namely char c. To trigger this behavior the variable has to contain the later explicitly checked '-' char by chance. In proc_do_large_bitmap() it is expected that the variable might be filled by the proc_get_long() function with the trailing character of the given input. But only if a trailing character exists within the passed size of the buffer. The proc_get_long() function can set c if the length of the parsed long is smaller than the given size of the buffer containing the user input. This is not the case if the buffer only contains the port value (e.g. "123") and sets the size exactly to that (3). Meaning if there is no trailing character, c will not be set. If no trailing character is present we still do a c =3D=3D '-' check. If the uninitialized variable contains this char the function continues parsing. It will now set err to -EINVAL in the next proc_get_long() call, as there is nothing more to parse. Initializing c to 0 will solve the problem. The problem will only arise sporadically, as the variable must contain '-' by chance. On the affected system CONFIG_INIT_STACK_NONE=3Dy was enabled. Further, when enabling eBPF tracing to dump contents of the stack the issue disappears, which would fit the current explanation as a root cause for the observed behavior. --- Changes in v4: - Re-include set c to 0 - Drop check against left - Move trailers - Removed Reviewed-by: Peter Seiderer - Link to v3: https://lore.kernel.org/r/20260319-fix-uninitialized-variable= -in-proc_do_large_bitmap-v3-1-9cfc3ff60c09@googlemail.com Changes in v3: - Add Reviewed-by: Peter Seiderer - Re-include bug context into cover letter - Link to v2: https://lore.kernel.org/r/20260317-fix-uninitialized-variable= -in-proc_do_large_bitmap-v2-1-6dfb1aefa287@googlemail.com Changes in v2: - Drop initialization of c to 0 - Include checking that left is non-zero before checking against c - Link to v1: https://lore.kernel.org/r/20260312-fix-uninitialized-variable= -in-proc_do_large_bitmap-v1-1-35ad2dddaf21@googlemail.com --- kernel/sysctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sysctl.c b/kernel/sysctl.c index 9d3a666ffde1..c9efb17cc255 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -1118,7 +1118,7 @@ int proc_do_large_bitmap(const struct ctl_table *tabl= e, int dir, unsigned long bitmap_len =3D table->maxlen; unsigned long *bitmap =3D *(unsigned long **) table->data; unsigned long *tmp_bitmap =3D NULL; - char tr_a[] =3D { '-', ',', '\n' }, tr_b[] =3D { ',', '\n', 0 }, c; + char tr_a[] =3D { '-', ',', '\n' }, tr_b[] =3D { ',', '\n', 0 }, c =3D 0; =20 if (!bitmap || !bitmap_len || !left || (*ppos && SYSCTL_KERN_TO_USER(dir)= )) { *lenp =3D 0; --- base-commit: 80234b5ab240f52fa45d201e899e207b9265ef91 change-id: 20260312-fix-uninitialized-variable-in-proc_do_large_bitmap-30c6= ef4ac1c5 Best regards, --=20 Marc Buerg