From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oo1-f47.google.com (mail-oo1-f47.google.com [209.85.161.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 F0EC73382F4 for ; Tue, 14 Jul 2026 13:36:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784036166; cv=none; b=ouSWrJ5SvWfZbFUUh8FuwH0eeBr39sYCuzSao0Q85u98hVxwMlKlafWKVkkki0v98GIH7kmlFTf0VYNf3ihNkRG5zLXHRIOTJS+WsVDF+WzfvYootS+ijk9H9ylfQjZC68rQGw7I6eQdCxfY+A49+AmKrkWAntAWcPWQfIis+fI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784036166; c=relaxed/simple; bh=LntuTkEkcpgOciuQLLeQw3UnDTxWIKJmuj8XrBupXRM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=s6RbX8BtWBuoTNcqhAwTpOkILx7v+aqeF6o+KNvuiv/NCdmXXKg/VBodRAWWKsyPs46GU4zuafQBUpLuoG0mVVOM30aLsgIOY229Q//iA4z0N7RgLeJku3xgO3koisDs/8LetLI6+VUPZnJNbA3YO9Zofp8XRSxmGV8JlvVEh5c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=F1Su1TbF; arc=none smtp.client-ip=209.85.161.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="F1Su1TbF" Received: by mail-oo1-f47.google.com with SMTP id 006d021491bc7-6a375ba035eso541941eaf.3 for ; Tue, 14 Jul 2026 06:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1784036163; x=1784640963; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=WtnsB/5RqMWNV05DRP1OqiXZh9YAB0wkSwZwc1lWL1o=; b=F1Su1TbF7X46qcSplLRyh9eXrd8MKWrMU1QtH+U3ClhKRT5oLLt1WkGISS/EmUnaRc ZqHOrl8uf2XbkBSeCGjvZE91To/dXNRQm8fHB9eCO6sJBOskm8QsmI4pWVBqbseXnx2z sW76q0KvYj/YyzQjGVcW3arJ0v8sVXBY8k78g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784036163; x=1784640963; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=WtnsB/5RqMWNV05DRP1OqiXZh9YAB0wkSwZwc1lWL1o=; b=ImPcUGm9j/h+Jh+HoeoQbt7jevtTXrZ8orNCiIlyC60c1z0Z6j8GtuP1xqEor0mcd2 YsEw7t+tx1krO8pX9ELnSw/SJlxXyKF+8vuoZSzE8qUMEnMzMBPsC6zCSfVLWZbgWBZq m391Y80+mAvRNZULpqCKGAYg5PlAZFv9f0gqzVFYtxLyGiQwqnuOO0oGFZSCvIup3CIi bSZbOHpsfk1C43pfWxzY2737bJfnmx4NvPO92nGCWDY7UIN9zK+Z7JoVqNIrk6s20YGG Vk9VwqlWYk5xz85joS1fJxUNIqDwBv9advhuXgiXGHwj7J/UZ2CGHTZD0bfOp/eUiL5e IOjQ== X-Forwarded-Encrypted: i=1; AFNElJ/tqKRbaulE5NYa1+5eUcZxXlWXOLFDoqqWfiZYYLzQUcbXG1qodu+Z4pjhJDQhU6OjQlpm2siA2ERdvjE=@vger.kernel.org X-Gm-Message-State: AOJu0YxTK4MZFiZzbjxBuf/7EljgZjQt0zYQ2rUi7RoRyGZUjgzmp4A8 shzAmBtOi2J9T1x9vvbKYSm2t9+n0ZOCKRTudatTF87oavUtmAKo035aYnxQoaOzoQ== X-Gm-Gg: AfdE7cnYZTtpbljKW0AKvweaFnOoABTxrKO6uUyw7y40ilkke3QDgVmDDQNKvnlrupY lboVGApPBIp5qO1rMVjQ8a7zwO7rkWP7Zj/0rw+wFi4KpLka5okuhTPYzRXP5QzP2M+gysnbtj5 FRY0OItsIdfeTOLQQXR9QdBeN+JpEb+CXAkFdG30uY+Kbjuq9gmTQVIui1SYzLYAfePlVwzmneY x2uRpNyDBanZRFbM/mKTbJ8jZGGJ+ZXIlJAKORiKE3D0LCVPWScQHSnLztWwrypUAo66WIyr5tb zsYyHyuIe/FKz4ZKFpNuFOpduCj40GCaCctX/UWqgr2Ot9UUGlqB2t1llrfDVmgga3VIWlCM5Z8 UYOyc5a4A191hovSG34ZBQ96MhE8E3vVX9mhFHodKa6ekft7jZ7y2fDZA4SdHDTXwmsOTZiiEvY f8J3eBfpE= X-Received: by 2002:a05:6820:1694:b0:69d:f0c2:73f6 with SMTP id 006d021491bc7-6a39a5921fcmr8099401eaf.16.1784036162714; Tue, 14 Jul 2026 06:36:02 -0700 (PDT) Received: from chromium.org ([174.51.25.52]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-6a377bd9cb1sm11688216eaf.15.2026.07.14.06.36.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2026 06:36:02 -0700 (PDT) From: Simon Glass To: LKML Cc: Simon Glass , Nathan Chancellor , Nicolas Schier , Xingjing Deng , linux-kbuild@vger.kernel.org Subject: [PATCH] kconfig: abort rather than loop for ever on EOF Date: Tue, 14 Jul 2026 07:35:42 -0600 Message-ID: <20260714133545.3294648-1-sjg@chromium.org> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kbuild@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit When a non-interactive 'make oldconfig' or 'syncconfig' meets a new int or hex symbol whose default cannot be applied, conf_string() reads a value from stdin. At end of file fgets() returns NULL, no value is set and the loop asks again. The result is an endless loop which fills the output until it exhausts memory, rather than a clean failure. Detect this in conf_string(): if the value cannot be set and stdin is at end of file, stop with an error that names the symbol. Note that a symbol with no default doesn't trigger this, since sym_calc_value() falls back to 0, which is accepted at end of file. The loop is triggered by a broken Kconfig file, with a default whose text fails sym_string_valid(). Such mistakes do creep in from time to time and are hard to debug, since the build fills the log with repeated prompts instead of pointing at the offending symbol. Some bad defaults draw a parse-time warning, but menu_validate_number() accepts a reference to any int or hex symbol, so a cross-type reference loops with no warning at all. For example, "0xff" is not a valid int value: config HEXSYM hex default 0xff config VAL int "Value" default HEXSYM Interactive use is unaffected, since feof() only becomes true once a read actually hits end of file: an invalid answer at a terminal still re-prompts, while Ctrl-D at such a prompt exits with the error instead of looping. bool and tristate symbols and choices already accept the default on an empty line, so they still take their defaults in a non-interactive build. Tested with int and hex symbols carrying such defaults: with empty stdin, the code without this change produces around 190MB of repeated prompts within two seconds, while with the change it exits 1 naming the symbol. Piped and interactive (pty) sessions still re-prompt on an invalid answer and then accept a valid one. A new string symbol with no default still takes the empty string at end of file, since any text is valid for a string. Signed-off-by: Simon Glass --- scripts/kconfig/conf.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c index c368bec5ab60..fe8ba09b0039 100644 --- a/scripts/kconfig/conf.c +++ b/scripts/kconfig/conf.c @@ -348,6 +348,23 @@ static int conf_string(struct menu *menu) } if (def && sym_set_string_value(sym, def)) return 0; + + /* + * A new int or hex symbol whose default fails validation + * cannot be set from an empty answer. When standard input is + * exhausted, as it is for a non-interactive oldconfig or + * syncconfig, re-asking would loop forever and grow the output + * until it exhausts memory. Stop with an error that names the + * symbol instead. String symbols accept any text, and bool and + * tristate symbols (conf_sym()) and choices (conf_choice()) + * accept the default on an empty line, so they are unaffected. + */ + if (feof(stdin)) { + fprintf(stderr, + "\nerror: no value for new symbol '%s' at end of input\n", + sym->name); + exit(1); + } } } --- base-commit: 59dee6d28756c629f3a0bb56266f80e36ef7c99c branch: kconfig-eof -- 2.43.0