From nobody Sat Jul 25 19:28:42 2026 Received: from mail-oo1-f48.google.com (mail-oo1-f48.google.com [209.85.161.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 F11703537FD for ; Tue, 14 Jul 2026 13:36:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.48 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784036165; cv=none; b=pT/aADgbRWaqY5cOgOWlB4mcSaLIKuUvk729TA5TAWe8iuH/4NsoJ7oOV3RxDlpZ9wmuSVEc+VlmqXxyqPmnItXq0bX/QiZOV4WQ8iYthecsKssEflJd2pvCxBpo/ebBzANoL/eyo8jjGbf6a1FEfQLpjnx9pNDfdfcoKTrEWA0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784036165; c=relaxed/simple; bh=LntuTkEkcpgOciuQLLeQw3UnDTxWIKJmuj8XrBupXRM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Iq22T9kfWRVG99R24jjdZCedV2n5jjTrtQateokr9IC+5Z0NZG4EcZScpWa1zxketWf+OU3f1ufI4N7KlHpFlH3pfZJ+F9mEZ1VForuWV5XQOAGQtiIY4JUNEanVA0icsLlvvoxZ9vAjAIOaUkqhv2GzG0xf8KUa2mxUJCl/U4c= 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.48 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-f48.google.com with SMTP id 006d021491bc7-6a37b2643e2so627365eaf.0 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=D7fXSqKdVlV95LvdAyKx/BEbbX7F5tcheph866udrhNeVUuT5K2xgPJHsNt78JSn29 P+cqq6DCkOQ13mdQzWcuDYk3DyNLXwe2PqxF37wPxh4jsrn8zp9apgFx5JQ/zTsQshMO dgCVV93mhJ6vrRHpdYUGv3MOTmMXIq8Fcz4sHpUurnyrfjDBItV7VM9nZ7O5qwUglxAS c9f8FIPdkodI1xjzFbN5O1gMO28efIU47zUoBmtlFpTc+ebOLJo06sB0EL2y9BBBNRa5 glO40vEevYdkeD4ZVkg/YBsTgUA8oLOU3tzJrubYyTxz53hGjVN88I/+81wcPqaHbCvB Zymw== X-Gm-Message-State: AOJu0YzGY1zfrgdufrSObYg81N+wN3FKVQlG2hFOJ8bBbokt1r7ywOxz g8dI4Lssw+NL1Aiv59Vqz4S0USpbNer0ZOyPKWS7Ioe68OWKMyFyeYeRR8zTKJzr/FiL2jccJF6 P937AGA== X-Gm-Gg: AfdE7cniLQu7qDh9fBFLTIO+tDFUZ2ThAMvGB7+bCSJEgWsJ/V60Y2AsqdDlzmxjQ86 SpgdDkTPtTnRZ4pdZKZkes3zjXbKAigmuXVeZzKLRJpHZJXw+8zwqWOjXyIzPmX/TIi8Hqb/6Jp LAqLj3gBRUhaG8gigaqdXAFseRjHGZz7k15+2I11Z6Ha+CIuj4fLPXyAM7MjgV8349nLBD7OFfA TCL6RthavvqhNeD5CsJmehEHFs6HoUvKOzkPpioAoab4H5ynki+evA2SbdAbBF5BeXSx6BpztuD 1kblhSwzgI5Q13SzWgOC/IXNFJ1XUeet0qdwePiqIC45M2lY+dSNS8w/e6ZpJnLj3XG7wda9yG8 q7y0f5bHOkrffuZGs5JYXXgSS0MyokHCrUIcxRh+bXIXUNsaphGFIi6j6k2dgBOlPEu6omNaoWz ntjy9PZ/M= 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-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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); + } } } =20 --- base-commit: 59dee6d28756c629f3a0bb56266f80e36ef7c99c branch: kconfig-eof --=20 2.43.0