Inferring 1-Minimal Trigger Configurations for Assessing Linux Kernel CVE Triggerability

Inferring 1-Minimal Trigger Configurations for Assessing Linux Kernel CVE Triggerability

arXiv:2608.15225v1 [cs.CR] 15 Aug 2026

TONGJIE WEI, Nanjing University of Science and Technology, China PENG ZHANG∗ , Nanjing University of Science and Technology, China ZHIWEN HU, Nanjing University of Science and Technology, China XUPU HU, Nanjing University of Science and Technology, China CHEN LYU, Shandong Normal University, China GANGYAN ZENG∗ , Nanjing University of Science and Technology, China Vendors assessing Linux kernel CVEs need to know whether a bug is triggerable under production-tailored configurations, not merely whether a version is affected, yet upstream reproducers and vulnerability databases rarely provide configuration-level context. We study minimal trigger-configuration inference: given a CVE entry and a target kernel version (optionally a baseline .config), we synthesize a Kconfig-satisfiable option set that remains effective after make olddefconfig and, when a reproducer is available, still triggers under a specified evaluation protocol; we then prune it to a 1-minimal (subset-minimal) boundary for evaluation. Our framework FCC links vulnerability cues to build-system symbols, completes implicit prerequisites under olddefconfig feedback to avoid silent rollback, and performs runtime-validated minimization guided by dependency topology. We evaluate on KernJC and KernelCTF, totaling 88 CVEs across multiple kernel versions. On the 88-CVE set, FCC improves the post-make olddefconfig configuration success rate from 62.5% (55/88) to 96.6% (85/88) over an olddef-only injection baseline; on the KernJC set, FCC reduces the average candidate set size by 78.7% compared to KernJC (Avg. 14.72 vs. 69.00 options per CVE). A stage-wise analysis of time and token costs shows that Stage I dominates overhead, while CVE-focused evidence selection substantially reduces this cost. By returning an effective and auditable 1-minimal configuration boundary, FCC helps vendors scope triggerability against their deployment configurations with a clear, tool-supported decision line. CCS Concepts: • Security and privacy → Software security engineering; Operating systems security; • Software and its engineering → Software testing and debugging. Additional Key Words and Phrases: Linux kernel, vulnerability reproduction, trigger configuration ACM Reference Format: Tongjie Wei, Peng Zhang, Zhiwen Hu, Xupu Hu, Chen Lyu, and Gangyan Zeng. 2026. Inferring 1-Minimal Trigger Configurations for Assessing Linux Kernel CVE Triggerability. Proc. ACM Softw. Eng. 3, ISSTA, Article ISSTA152 (October 2026), 22 pages. https://doi.org/10.1145/3832243 ∗ Peng Zhang and Gangyan Zeng are the corresponding authors.

Authors’ Contact Information: Tongjie Wei, Nanjing University of Science and Technology, School of Cyber Science and Engineering, Nanjing, China, weitongjie@njust.edu.cn; Peng Zhang, Nanjing University of Science and Technology, School of Cyber Science and Engineering, Nanjing, China, zhang_peng@njust.edu.cn; Zhiwen Hu, Nanjing University of Science and Technology, School of Cyber Science and Engineering, Nanjing, China, huzhiwen@njust.edu.cn; Xupu Hu, Nanjing University of Science and Technology, School of Cyber Science and Engineering, Nanjing, China, huxupu@njust.edu.cn; Chen Lyu, Shandong Normal University, Jinan, China, lvchen@sdnu.edu.cn; Gangyan Zeng, Nanjing University of Science and Technology, School of Cyber Science and Engineering, Nanjing, China, gyzeng@njust.edu.cn.

This work is licensed under a Creative Commons Attribution 4.0 International License. © 2026 Copyright held by the owner/author(s). ACM 2994-970X/2026/10-ARTISSTA152 https://doi.org/10.1145/3832243 Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

ISSTA152:2

1

Tongjie Wei, Peng Zhang, Zhiwen Hu, Xupu Hu, Chen Lyu, and Gangyan Zeng

Introduction

For Linux kernel vulnerability risk assessment, vendors often care less about whether a kernel version is affected and more about whether a vulnerability is triggerable under production-tailored kernel configurations [35]. Many CVEs manifest only under specific configuration combinations [7, 28, 34], and there is a substantial configuration gap between upstream reproduction environments and product kernels. To address this gap, we study minimal trigger-configuration inference for vulnerability reproduction. Given a CVE entry, a target kernel version, and optionally a baseline .config and a runnable proof-of-concept (PoC), we synthesize a triggering option set that (i) satisfies Kconfig constraints, (ii) remains effective after make olddefconfig1 , and (iii) triggers the vulnerability under an oracle-defined evaluation protocol (Sec. 4.1) validated in our upstream QEMU/KVM setting. We then prune it to a 1-minimal (subset-minimal) triggering option set that serves as an actionable evaluation boundary for production deployments; without a runnable PoC, we only output an effective configuration boundary. In practice, fuzzing-oriented platforms such as syzbot [14] often reproduce bugs under feature-rich, coverage-oriented kernel configurations, whereas production kernels are typically tailored for specific workloads and devices [17]. For deployments that rely on a bounded set of stock cloud or distribution images, such as Google Cloud public OS images [16], triggerability can often be assessed by running the available PoC on those images. This work focuses on the more difficult setting of vendor- and downstream-tailored kernels, where maintainers must determine whether an upstream CVE remains triggerable under the deployed effective configuration, since upstream reproducibility does not necessarily imply downstream triggerability [17, 34–36]. Moreover, mainstream vulnerability databases such as the NVD [25] typically report affected kernel version ranges but rarely provide configuration-level context [7, 23, 28], making it difficult to assess triggerability in real-world production settings. Upstream reproducers often trigger bugs under coverage-oriented configurations, yet they rarely expose (1) which configuration options are necessary to reach and trigger the vulnerable code path and (2) whether these options can be pruned into a small, auditable boundary while preserving matched trigger evidence. Static dependency-based configuration inference helps reduce manual search, but dependency expansion alone is ill-suited for cross-subsystem runtime context and for dependency drift across kernel versions. Our focus is complementary to reproducer adaptation across kernels/environments: we keep the reproducer fixed and target the missing configuration prerequisites that must remain effective after make olddefconfig. Therefore, turning “triggerable under a production configuration” into an actionable and auditable conclusion calls for an end-to-end pipeline that (a) recovers functional prerequisites from vulnerability information, (b) synthesizes a buildable configuration that remains effective under Kconfig constraints, and (c) removes redundancy under dynamic trigger evidence until converging to a 1-minimal evaluation boundary under the protocol. Three practical issues make this pipeline non-trivial. First, configurations determine not only whether code is compiled, but also whether it becomes reachable at runtime; trigger chains are often scattered across subsystems, so relying on local static clues alone can miss prerequisites or introduce substantial over-approximation. Second, due to Kconfig constraints, a configuration is not effective simply because an option is written in .config: critical options may be silently rolled back during make olddefconfig when prerequisites are unsatisfied, causing reproduction to fail even when options appear enabled. Third, the configuration space grows exponentially with the

1 The command make

olddefconfig updates an existing kernel configuration for a target version by assigning default values to newly introduced options and resolving Kconfig constraints; options with unsatisfied prerequisites may be silently unset. Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

Inferring 1-Minimal Trigger Configurations for Assessing Linux Kernel CVE Triggerability

ISSTA152:3

number of features, while dependencies and implementations evolve across versions; minimizing configurations at a controlled cost without losing matched trigger evidence is therefore challenging. Recent work has started to automate the identification of configuration options relevant to kernel vulnerabilities. A representative approach, KernJC [28], infers vulnerability-related options by constructing a Kconfig dependency graph, thereby reducing manual effort. However, static dependency expansion alone is insufficient for reproduction-oriented inference of a minimal triggering boundary under make olddefconfig constraint resolution and runtime trigger evidence. Specifically, it faces three limitations: (1) over-approximation—the inferred set often contains many options irrelevant to the runtime triggering path, making it hard to derive an actionable boundary; (2) version sensitivity—Kconfig dependencies evolve substantially across kernel versions, so static graphs do not generalize reliably; and (3) no validated effectiveness after make olddefconfig—even when correct candidates are identified, explicitly enabling them may still be overridden during make olddefconfig due to constraints such as depends on and select, leading to the practical failure mode of “correct identification but failed reproduction.” These limitations motivate three core challenges for triggerability evaluation under production configurations. Challenge 1: Identifying implicit runtime-context prerequisites along cross-subsystem trigger chains. Critical configuration prerequisites are often scattered across drivers, architectures, and core subsystems. Relying solely on build-level static dependency graphs can miss runtime preconditions required by the trigger chain, or introduce many irrelevant options that inflate the candidate set. Challenge 2: Kconfig-constrained configuration synthesis with validated effectiveness after make olddefconfig. Kconfig is a logical system with implicit prerequisites; enabling an option directly in .config does not guarantee that it remains enabled in the final configuration. During make olddefconfig, the build system may revert or override options according to dependency relations, disabling critical switches and breaking reproduction. Challenge 3: Denoising/minimizing configurations under kernel version evolution. Static inference inevitably produces an over-approximate set, while dependencies drift across versions through additions, removals, and refactoring, invalidating previously inferred information in the target version. Naive option-by-option pruning easily leads to combinatorial explosion. The key question is how to denoise efficiently using dynamic trigger evidence while leveraging dependency topology to constrain the search and converge to a 1-minimal triggering boundary at a controllable cost. We present FCC (FindCveConfig), an automated framework that infers a minimal kernel configuration boundary for triggering Linux kernel vulnerabilities under an oracle-defined protocol. FCC targets determining whether a vulnerability is triggerable for a specified kernel version and configuration context in our upstream QEMU/KVM setting, and provides a tool-supported workflow for customized production environments. Importantly, FCC uses the LLM only for Stage I candidate identification, Stage II constraint parsing, and Stage III trigger-evidence matching; retained options are still validated by make olddefconfig-based effectiveness and build/run checks. Concretely, FCC addresses the three challenges as follows. For Challenge 1, FCC builds a semantic profile by jointly analyzing the CVE description in NVD, the corresponding CWE information, and external resources referenced in disclosures, and uses it to guide targeted mining over Kconfig, Makefile, and other build specifications to capture dispersed prerequisites and reduce over-approximation. For Challenge 2, FCC models Kconfig constraints, performs dependency completion and consistency checking, and validates buildability so that critical options remain effective after make olddefconfig. For Challenge 3, FCC performs dependency-topology-guided minimization under dynamic trigger evidence, constraining the search order and pruning strategy so that the candidate set empirically converges to a 1-minimal triggering boundary for the target version within a controlled time budget.

Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

ISSTA152:4

root dir.

Tongjie Wei, Peng Zhang, Zhiwen Hu, Xupu Hu, Chen Lyu, and Gangyan Zeng CONFIG_NET /net

/vmw_vsock /drivers

CONFIG_BPF CONFIG_VSOCKETS CONFIG_VHOST_VSOCK

/virtio Directory node Dir. relationship Cont. relationship

CONFIG_VIRTIO_VSOCKETS CONFIG_VIRTIO (not set) CONFIG_VIRTIO_PCI (not set)

(a) Kconfig dependency directory tree

.config File (partially presented)

/net/vmw_vsock/Kconfig (partially presented)

1 CONFIG_NET = y 2 CONFIG_BPF = y 3 CONFIG_GENERIC_NET_UTILS = y 4 CONFIG_PCI = y 5＋CONFIG_VSOCKETS = y 6＋CONFIG_VHOST_VSOCK = y 7＋CONFIG_VSOCKETS_DIAG = y 8＋CONFIG_VSOCKETS_LOOPBACK = y 9 - CONFIG_VIRTIO_VSOCKETS = y 10 # CONFIG_VIRTIO is not set 11 # CONFIG_VIRTIO_PCI is not set

config VIRTIO_VSOCKETS depends on VSOCKETS && VIRTIO /drivers/virtio/Kconfig (partially presented) config VIRTIO help This option is selected by any driver which implements the virtio bus, such as CONFIG_VIRTIO_PCI, CONFIG_VIRTIO_MMIO, CONFIG_RPMSG or CONFIG_S390_GUEST.

(b) .config after make olddefconfig

(c) Related Kconfig file

Fig. 1. Motivating failure mode: “candidate set” ≠ effective, triggerable configuration under make olddefconfig. (a) Relevant Kconfig constraints for CVE-2021-26708. (b) After injection, make olddefconfig may silently roll back options (“+” kept enabled; “-” disabled), breaking PoC triggering. (c) Root cause: some prerequisites are enabled only through feasible select-mediated paths (and conditional contexts), so forcing a dependent option in .config is insufficient.

We evaluate FCC on 88 historical Linux kernel CVEs spanning multiple versions (32 from KernJC and 56 from KernelCTF), comparing against KernJC and an olddef-only injection baseline. On the KernJC set, FCC maintains full CVE coverage while reducing redundancy, decreasing the average candidate set size from 69.00 to 14.72 options per CVE (RQ1; Table 1). Compared with the olddef-only baseline, FCC improves the post-make olddefconfig configuration success rate from 62.5% (55/88) to 96.6% (85/88) (RQ2; Fig. 6). On the 32 KernJC CVEs with runnable PoCs, FCC further reduces the Stage I candidate set from 14.72 to a final boundary of 1.63 options per CVE on average while preserving matched trigger evidence under the same protocol (RQ3; Table 2). For RQ4, we profile per-stage time/token costs (Fig. 7). In summary, this paper makes the following major contributions. • We introduce and formalize the task of minimal trigger-configuration inference for vulnerability reproduction, and motivate its role in production risk assessment. • We propose FCC, which performs vulnerability-semantics-driven candidate mining over build specifications (e.g., Kconfig and Makefile) to recover triggering prerequisites beyond static dependency expansion; the LLM is used only for candidate identification, constraint parsing, and trigger-evidence matching, while all options are validated by make olddefconfig-based effectiveness checks and build/run validation. • We design Kconfig-constrained dependency completion with build validation to ensure that critical options remain effective after make olddefconfig. • We propose a dependency-topology-guided runtime minimization algorithm that yields a 1-minimal triggering boundary under the oracle-defined protocol, and validate it on the KernJC dataset with KernJC and an olddef-only baseline. 2 2.1

Motivation A Motivating Example

Figure 1 shows why a “vulnerability-related” option list can still fail to produce an effective, triggerable configuration once make olddefconfig resolves Kconfig constraints. We use CVE2021-26708 (net/vmw_vsock) as an example; Fig. 1(a) highlights the relevant constraints. Many dependency-based inference pipelines (with KernJC as a representative) generate a candidate set from code locations and Kconfig relations, inject it into .config, and run make olddefconfig to obtain a buildable configuration. However, candidates written as enabled may not survive make olddefconfig: Fig. 1(b) shows silent rollback (“+” kept; “-” disabled) despite explicit Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

Inferring 1-Minimal Trigger Configurations for Assessing Linux Kernel CVE Triggerability

ISSTA152:5

assignments. In this case, CONFIG_VIRTIO_VSOCKETS is rolled back by make olddefconfig, and the PoC stops producing the same trigger signature under our protocol. The root cause is reflected in Fig. 1(c). Besides depending on VSOCKETS, VIRTIO_VSOCKETS also depends on VIRTIO. In the target version/configuration context, VIRTIO may not be directly userselectable (e.g., no prompt) and is typically enabled via select from drivers such as VIRTIO_PCI, VIRTIO_MMIO, RPMSG, and S390_GUEST. Thus, forcing VIRTIO_VSOCKETS=y is not enough; keeping it enabled requires enabling at least one feasible selector path that turns on VIRTIO. This make olddefconfig rollback is a recurring failure mode of one-shot injection baselines, which we quantify later under the olddef-only baseline (RQ2). Overall, we need to (i) ensure trigger-critical options remain effective after make olddefconfig and (ii) remove redundancy to obtain a small, auditable boundary. 2.2

Key Ideas

The example suggests three requirements: (1) map vulnerability evidence to build-system symbols; (2) ensure effectiveness under make olddefconfig; and (3) minimize using runtime evidence. Concretely, Stage I builds a candidate set 𝐶, Stage II repairs it into an effective set 𝑆 that survives make olddefconfig, and Stage III prunes 𝑆 to a 1-minimal boundary 𝑆 min under the trigger oracle. Vulnerability artifacts (e.g., NVD reports, patches, PoCs, and references) are unstructured and rarely map directly to CONFIG_* symbols. We combine build-evidence cues (e.g., file paths, module/interface names, macros) with semantic cues (e.g., triggering mechanism, subsystem, preconditions) to seed and constrain candidate discovery, reducing over-approximation early. Trigger-critical switches must remain enabled after make olddefconfig. This requires handling forward prerequisites (depends on), select-mediated enabling paths, and conditional contexts (if/source). For non-user-selectable symbols, at least one feasible enabling branch must be completed; we iteratively repair missing prerequisites under make olddefconfig feedback until options become stably effective or are deemed unsatisfiable under bounded search. Since static dependencies cannot certify necessity, we minimize via a disable–build–run loop and accept a removal only if the configuration stays effective and the run matches the same bug signature under the protocol. 3 3.1

Preliminaries Task and Goal

We study minimal trigger-configuration inference for Linux kernel vulnerability reproduction. Given a CVE entry with its artifacts (e.g., description, patch, PoC and references), a target kernel version, and optionally a baseline .config, FCC aims to (i) assess triggerability under a specified evaluation protocol and (ii) derive a small, auditable configuration boundary. The output is a configuration boundary 𝑆: a satisfiable set of CONFIG_* assignments (e.g., y/m) that remains enabled in the effective .config after make olddefconfig. When a runnable reproducer (PoC) is available, building and booting the kernel with the effective .config and executing the reproducer should yield matched trigger evidence (e.g., a crash or a KASAN report); we then prune redundant assignments while preserving this evidence to obtain a 1-minimal triggering boundary. FCC requires a runnable reproducer to claim triggerability; without one, it does not claim triggerability and outputs only an effective (post-make olddefconfig) configuration boundary. 3.2

Setting and Assumptions

Our reproduction setting targets a controlled environment built from upstream Linux kernel source code rather than executing a PoC directly on a distribution’s default kernel. The configuration Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

ISSTA152:6

Tongjie Wei, Peng Zhang, Zhiwen Hu, Xupu Hu, Chen Lyu, and Gangyan Zeng

context, when provided, serves as a baseline for evaluating triggerability, while the upstream-based build enables tighter control over confounding factors (e.g., heavy customization and non-upstream patches in distribution kernels). Concretely, we generate a .config for the target version, compile it into a bootable kernel image (e.g., bzImage) via the Kbuild [29] system, and boot the resulting kernel together with a root filesystem in QEMU/KVM. We then run the PoC inside the virtualized system and use kernel logs (e.g., crash traces or KASAN reports) to determine whether matched trigger evidence is observed. FCC aims to derive a production-tailored configuration boundary while validating it in this controlled upstream-based setting; applying the resulting boundary to heavily patched distribution kernels or hardware-specific environments may require additional adaptation that is orthogonal to the configuration-effectiveness problem studied here. 3.3

Key Definitions

Kconfig, Kbuild, and Effective Configuration. The Linux kernel’s configurable build process is governed jointly by Kconfig [30] and Kbuild [29]. Kconfig specifies CONFIG_* symbols and logical constraints among them, while Kbuild (realized through the Makefile hierarchy) translates whether a symbol is enabled into concrete compilation decisions, such as building code into the kernel image or as a loadable module. Configuration constraints commonly include depends on, which requires condition 𝑌 to hold before option 𝑋 can be enabled, and select, which forces option 𝑌 to be enabled when 𝑋 is enabled. We explicitly distinguish between a written configuration, i.e., values manually set in .config, and an effective configuration, i.e., the final .config obtained after running make olddefconfig. The olddefconfig step fills in default values according to Kconfig rules and may silently disable options whose prerequisites are unsatisfied; consequently, an option written as enabled does not guarantee that it remains enabled (as y or m) in the effective .config. We treat an option as effective only if (i) it retains its intended value in the effective .config and (ii) a subsequent build confirms that Kbuild realizes the corresponding compilation units in the expected artifact form, i.e., built into the kernel image for =y or produced as a .ko module for =m. Candidate Set and Minimal Triggering Boundary. We define the candidate set 𝐶 as the collection of CONFIG_* options inferred from vulnerability artifacts (e.g., CVE description, patch, and references) and build system files (e.g., Kconfig and Kbuild Makefiles) as potentially relevant to triggering. The candidate set may contain redundant options, and some options may not remain enabled in the effective .config produced by make olddefconfig. A triggering configuration boundary 𝑆 is a set of CONFIG_* assignments that is satisfiable under Kconfig constraints, remains enabled in the effective .config after make olddefconfig, and produces matched trigger evidence when the PoC is executed. We call 𝑆 1-minimal (subset-minimal) if removing any single assignment from it causes at least one of the following to fail under the same evaluation protocol: (i) the configuration becomes ineffective after make olddefconfig, (ii) the kernel cannot be built/booted, or (iii) matched trigger evidence is no longer observed. This notion of minimality is defined for an operational evaluation boundary, where necessity is judged by buildability/bootability, effectiveness, and trigger evidence under the protocol. Trigger Evidence. After executing the PoC in our reproduction environment, we may observe concrete abnormal behaviors, such as a system crash or a KASAN report; we treat such observable abnormalities as trigger evidence. To support stable minimization, we compare evidence using a consistent matching rule and accept an option removal only when the matched trigger evidence is still observed. Concretely, we use a bug signature extracted from logs (e.g., sanitizer/crash type and a normalized stack-trace pattern) to decide whether two runs correspond to the same bug. Evaluation Protocol. Under our setting, a configuration is considered reproducible if (i) it satisfies Kconfig constraints and, after make olddefconfig, the assignments in the boundary remain enabled in the effective .config and are realized by Kbuild in the compiled artifacts, and Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

Inferring 1-Minimal Trigger Configurations for Assessing Linux Kernel CVE Triggerability

ISSTA152:7

(ii) building and booting the kernel with the effective .config and executing the PoC produces matched trigger evidence. The concrete oracle definitions and protocol parameters (e.g., signature matching and repeated runs) are specified in Sec. 4.1, and the evaluation settings (e.g., datasets and timeouts) are specified in Sec. 5. Scope and Threat Model. FCC targets configuration prerequisites for triggering a vulnerability with a given reproducer in a controlled environment. For downstream assessment, the inferred boundary should be interpreted as a configuration precondition, not as a standalone exploitability result. FCC targets deployments in which a production-tailored kernel exposes the relevant kernel interface to inputs beyond vendor- or administrator-controlled code, such as untrusted local users, tenant workloads, sandboxed applications, containers, guest workloads, or network/device inputs that can reach the vulnerable subsystem. If the relevant interface is reachable only by trusted vendor code, the inferred boundary should be interpreted as a configuration precondition rather than an exploitable-risk conclusion. It does not aim to synthesize exploits, strengthen reliability beyond the stated protocol, or cover distribution-specific patch stacks and proprietary hardware dependencies. When a vulnerability requires unavailable hardware, privileged setup, or non-upstream components, FCC may fail to validate triggerability even if the vulnerability is affected at the source level; we treat such cases as outside the scope of protocol-defined trigger validation. 4 4.1

Method Definitions and Oracles

Given a CVE with its artifacts (description, patch, external references, and an optional proof-ofconcept (PoC)), a target kernel version 𝑣, and an optional baseline configuration 𝐵 (defaulting to defconfig), FCC outputs a configuration boundary. We represent a boundary as a set of CONFIG_* assignments 𝑆 (e.g., forcing a symbol to y or m) applied as overrides on top of 𝐵. When a runnable PoC allows establishing a reference bug signature, FCC further minimizes the boundary to a 1-minimal triggering boundary 𝑆 min . We write 𝐵 ⊕ 𝑆 to denote injecting 𝑆 into 𝐵 (i.e., assignments in 𝑆 override 𝐵 for the same symbol). Convention: In the pseudocode, we treat an “assignment” as its target symbol together with an intended enabling value; adding/removing an element corresponds to enforcing/not enforcing that assignment in the boundary. When 𝑆 min is defined, it satisfies the following properties under the evaluation protocol. (i) Effectiveness: after injecting 𝑆 min into 𝐵 and running make olddefconfig, each assignment in 𝑆 min remains in its intended state in the resulting effective .config, and the build artifacts confirm Kbuild realization of the corresponding units (built-in or module). (ii) Triggering: building and booting the kernel from this effective .config and executing the PoC produces matched trigger evidence. (iii) 1-minimality (subset-minimality): for every 𝑠 ∈ 𝑆 min , removing 𝑠 (i.e., not enforcing that assignment) causes at least one of the following to fail under the same protocol: (a) matched trigger evidence is no longer observed, (b) the kernel cannot be built/booted, or (c) the boundary becomes ineffective after make olddefconfig. This minimality is operational: it is defined for a buildable, protocol-validated boundary. Without a runnable PoC (or if no reference signature can be established), FCC does not claim triggerability and outputs only an effective (post-make olddefconfig) boundary 𝑆. We instantiate the above properties with two oracle functions. Effectiveness oracle Effective(𝐵, 𝑆). We run make olddefconfig on 𝐵 ⊕ 𝑆 to obtain Olddef(𝐵 ⊕ 𝑆). The oracle returns true if and only if (a) each assignment in 𝑆 has its expected value in the resulting effective .config; and (b) the subsequent build succeeds and confirms that the retained assignments are realized by Kbuild in the artifact form implied by their effective values, i.e., built into the kernel Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

ISSTA152:8

CVE entry

Tongjie Wei, Peng Zhang, Zhiwen Hu, Xupu Hu, Chen Lyu, and Gangyan Zeng I. Candidate identification

II. Dependency completion

III. Config minimization

Evidence Collection

Consistency Check

Candidate Ordering

Vulnerability lib.

Workflow LLM analysis

Cue Normalization Config Mapping

config set (candidate)

Constraint Parsing

config set (completed)

Reverse Tracing

Greedy Pruning config set (1-Min)

Fig. 2. Overview of FCC’s workflow (Stage I: candidate identification; Stage II: dependency completion; Stage III: config minimization).

image for =y or produced as loadable modules for =m. Otherwise, including configuration rollback, missing expected artifacts, or build failures, it returns false. Triggering oracle Trigger(𝐾, 𝑃). We execute the PoC 𝑃 on a booted kernel instance 𝐾 (built from an effective .config). The oracle returns true only if a trigger signal is observed and the observed evidence matches a bug signature. Trigger signals include panic/oops, KASAN/KMSAN reports, or a crash with a consistent signature. We extract a bug signature from kernel logs using an LLMassisted matcher (e.g., sanitizer/crash type, top stack frames, and key subsystem/function tokens). To reduce false positives, FCC establishes a reference signature Σref from an initial triggering run; subsequent tests are considered triggering only if they match Σref . If Σref cannot be established (e.g., the initial run does not yield a matchable signature), FCC does not claim triggerability and falls back to outputting only an effective boundary. Failures to boot, execute, or timeouts, as well as outputs that cannot be matched reliably, are treated as non-triggering. To handle non-deterministic triggering, we use Trigger𝑡 : we repeat the execution 𝑡 times and deem the vulnerability triggered if at least 𝜏 runs return true (i.e., match Σref ). In this work we set 𝑡 = 5 and 𝜏 = 1. Note that in this paper, “minimal” refers to 1-minimality (subset-minimality), not minimum-cardinality optimality. 4.2

Overview

FCC follows the three-stage workflow in Fig. 2 and maintains four artifacts: vulnerability cues 𝐿, a candidate set 𝐶, an effective boundary 𝑆, and a dependency graph 𝐺. Stage I constructs 𝐶 from vulnerability artifacts and build specifications. Stage II completes missing prerequisites under make olddefconfig feedback, yielding an effective boundary 𝑆 and an edge set 𝐸 used to build 𝐺. Stage III minimizes 𝑆 under the triggering oracle, guided by 𝐺, and outputs 𝑆 min when trigger validation is available. 4.3

Candidate Identification

Stage I derives a candidate set 𝐶 related to the vulnerability’s triggering conditions to constrain subsequent completion and minimization. We start from the NVD entry (CVE description and CWE) and incorporate an associated PoC when available. We then parse the NVD reference list to obtain URLs and tags (e.g., Vendor Advisory, Patch, Exploit). For each URL, we retrieve the page and extract the main textual content by removing non-content elements (e.g., scripts/styles) and boilerplate sections (e.g., navigation, footers, tables of contents, and comments). We retain CVE-specific information (e.g., affected components/versions, triggering conditions, and patch/mitigation details) and summarize it to control context length. References without substantive text are excluded; if the evidence remains insufficient, we fall back to the CVE description and CWE text only. For reproducibility, we snapshot and cache retrieved contents (raw HTML and extracted text) with access timestamps, and run cue extraction on cached snapshots. Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

Inferring 1-Minimal Trigger Configurations for Assessing Linux Kernel CVE Triggerability

ISSTA152:9

Step 1 Cue normalization prompt [Input]: CVE ID, Content (CVE Description/CWE Description/References/PoC) [Task]: Analyze the given [CVE_ID] and [Content], extract vulnerability-related information, determine its relevance to the following two types of cues, and summarize relevant content into the two types respectively if relevant. 1. Semantic cues: Detail the vulnerability’s triggering mechanism, associated components, and pre-requisite conditions for triggering; 2. Build-evidence cues: Enumerate specific evidence within the kernel source tree and configuration system (e.g., Kconfig options, affected files / directories, module names, function names, and key macros/constants). [Output]: Each entry must be a dictionary containing the following core elements: [CVE ID, Content Type, Semantic Cues, Build-evidence Cues] Step 2 Config mapping prompt [Input] : CVE ID, CVE Description, CWE Description, Semantic Cues, Build-evidence Cues, Makefile [Task]: Given the specified [CVE ID], use the [CVE Description] and [CWE Description] to semantically complete the normalized cues [Semantic Cues] and [Build-evidence Cues], and then, taking the normalized cues together with the provided [Makefile], identify the kernel configuration options related to triggering the vulnerability. [Output]: All configuration options are included in a list in the following format (JSON Only): [ CONFIG_XXX , CONFIG_YYY , CONFIG_ZZZ ]

Fig. 3. FCC candidate identification: a two-step prompting workflow. (1) Cue normalization extracts configuration-relevant semantic cues and build-evidence cues from heterogeneous vulnerability sources. (2) Config mapping infers kernel options by combining the normalized cues with build specifications.

From the evidence context, we extract configuration-relevant cues and normalize them into two types: semantic cues describing the triggering mechanism, involved components, and preconditions; and build-evidence cues providing anchors such as file paths, module names, key interfaces/function names, and macros/constants. We then construct prompts with the normalized cue set 𝐿 and build specifications, guiding the model to map cues to kernel configuration options and produce a candidate set 𝐶 (Fig. 3). We constrain outputs to a machine-parsable schema (Sec. 5). In Stage I, the model is used only to propose candidates; candidates are retained or discarded by make olddefconfigbased effectiveness checking and, when applicable, trigger validation. We fix the model version and decoding parameters (e.g., temperature = 0) and log prompts/responses for replay. 4.4

Dependency Completion

Stage II addresses the “set ≠ effective” failure mode, where directly writing inferred options into .config can still lead to silent rollback after make olddefconfig. Consistency Check. FCC injects the boundary into baseline 𝐵 and runs make olddefconfig to obtain Olddef(𝐵 ⊕ 𝑆). If an assignment fails to reach its intended state (e.g., rolled back to not set or otherwise altered), it is treated as ineffective. FCC iteratively completes prerequisites for ineffective targets until they become stably effective or a termination condition is met (empty worklist, maximum iterations, or no satisfiable branch under bounded search). Constraint Parsing. For each ineffective target symbol 𝑥, FCC locates its definition in the Kconfig corpus and extracts constraints from: (i) the config block for 𝑥 and its depends on expression, (ii) enclosing if/endif contexts, and (iii) conditional contexts at each source site along the inclusion chain that brings the definition into the build. Backtracking stops once either (1) all symbols referenced in the source-site conditions are enabled in the realized configuration, or (2) FCC reaches the Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

ISSTA152:10

Tongjie Wei, Peng Zhang, Zhiwen Hu, Xupu Hu, Chen Lyu, and Gangyan Zeng

Algorithm 1 Dependency completion (𝑢 → 𝑣 means keeping 𝑢 effective requires 𝑣). Input: 𝐶, 𝐵, 𝐿, 𝑆𝑟𝑐 Output: 𝑆, 𝐸 1: 𝑆 ← 𝐶; 𝐸 ← ∅ 2: (𝐶 𝑓 𝑔𝐹𝑖𝑛𝑎𝑙, 𝐷𝑖𝑠𝑎𝑏𝑙𝑒𝑑) ← 𝑂𝑙𝑑𝑑𝑒 𝑓 𝐶ℎ𝑒𝑐𝑘 (𝐵, 𝑆) 3: 𝑄 ← 𝐷𝑖𝑠𝑎𝑏𝑙𝑒𝑑; 𝑉 𝑖𝑠𝑖𝑡𝑒𝑑 ← ∅; 𝑖𝑡𝑒𝑟 ← 0 4: while 𝑄 ≠ ∅ and 𝑖𝑡𝑒𝑟 < 𝐼𝑇 𝐸𝑅_𝑀𝐴𝑋 do 5: 𝑖𝑡𝑒𝑟 ← 𝑖𝑡𝑒𝑟 + 1 6: 𝑥 ← 𝑝𝑜𝑝 (𝑄); 7: if 𝑥 ∈ 𝑉 𝑖𝑠𝑖𝑡𝑒𝑑 then continue 8: end if 9: 𝑉 𝑖𝑠𝑖𝑡𝑒𝑑 ← 𝑉 𝑖𝑠𝑖𝑡𝑒𝑑 ∪ {𝑥 } 10: 𝐾 𝑓 𝑟𝑎𝑔 ← 𝐸𝑥𝑡𝑟𝑎𝑐𝑡𝐾𝑐𝑜𝑛𝑓 𝑖𝑔𝐹𝑟𝑎𝑔𝑚𝑒𝑛𝑡𝑠 (𝑆𝑟𝑐, 𝑥) 11: 𝑌𝑚𝑖𝑠𝑠 ← 𝐴𝑛𝑎𝑙𝑦𝑧𝑒𝑀𝑖𝑠𝑠𝑖𝑛𝑔𝐷𝑒𝑝𝑠 (𝐶 𝑓 𝑔𝐹𝑖𝑛𝑎𝑙, 𝑥, 𝐾 𝑓 𝑟𝑎𝑔) 12: for each 𝑦 ∈ 𝑌𝑚𝑖𝑠𝑠 do 13: 𝐸 ← 𝐸 ∪ {𝑥 → 𝑦}; 𝑆 ← 𝑆 ∪ {𝑦} 14: 𝑆𝑒𝑙 ← 𝐹𝑖𝑛𝑑𝑆𝑒𝑙𝑒𝑐𝑡𝑜𝑟𝑠 (𝑆𝑟𝑐, 𝑦) 15: for each 𝑎 ∈ 𝑃𝑟𝑢𝑛𝑒𝐵𝑦𝐶𝑙𝑢𝑒𝑠 (𝑆𝑒𝑙, 𝐿, 𝑘) do 16: 𝐸 ← 𝐸 ∪ {𝑦 → 𝑎}; 𝑆 ← 𝑆 ∪ {𝑎} 17: end for 18: end for 19: (𝐶 𝑓 𝑔𝐹𝑖𝑛𝑎𝑙, 𝐷𝑖𝑠𝑎𝑏𝑙𝑒𝑑𝑁 𝑒𝑤) ← 𝑂𝑙𝑑𝑑𝑒 𝑓 𝐶ℎ𝑒𝑐𝑘 (𝐵, 𝑆); 𝑄 ← 𝑄 ∪ 𝐷𝑖𝑠𝑎𝑏𝑙𝑒𝑑𝑁 𝑒𝑤 20: end while 21: return (𝑆, 𝐸)

top-level Kconfig and no further enclosing source site exists. To avoid redundant parsing and cyclicinclusion overhead, FCC deduplicates visited nodes (Kconfig file path, source statement location) and merges repeated conditional constraints before completion. Reverse Dependency Tracing. Many interface/aggregation symbols (e.g., VIRTIO) are not directly user-selectable; they are often enabled implicitly via select from other options. If we only traverse forward prerequisites (depends on), we may miss such feasible enabling paths. For a missing prerequisite symbol 𝑦 of a target 𝑥, FCC searches the Kconfig corpus for select y and collects potential selector options Selectors(𝑦). These selectors represent alternative satisfaction branches for keeping 𝑦 effective in the current context. We filter branches using semantic cues and cap the retained branches to 𝑘 (we use 𝑘 = 1) to control branching. Selected selector options are added to 𝑆, and any additional prerequisites they introduce are handled by subsequent make olddefconfigfeedback iterations. Edge Convention. We use a directed edge 𝑢 → 𝑣 to denote that keeping 𝑢 effective requires 𝑣 under the current context. This covers both standard prerequisites induced by depends on/if/source and satisfaction branches induced by select-mediated enabling. Algorithm 1 presents the completion procedure. Here, 𝑆𝑟𝑐 denotes the Kconfig corpus for version 𝑣. OlddefCheck runs make olddefconfig on 𝐵 ⊕ 𝑆 and returns the realized configuration and the subset of targets in 𝑆 that fail to keep their intended states. Graph Construction. From the completed boundary 𝑆 and edge set 𝐸, we construct 𝐺 = (𝑉 , 𝐴, 𝐷 in ) with 𝑉 = 𝑆, 𝐴[𝑢] = {𝑣 | (𝑢, 𝑣) ∈ 𝐸}, and 𝐷 in (𝑣) = |{𝑢 | (𝑢, 𝑣) ∈ 𝐸}|. Thus, 𝐷 in (𝑣) is the number of current assignments that depend on 𝑣; isolated assignments remain in 𝑉 with dependent count zero. Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

Inferring 1-Minimal Trigger Configurations for Assessing Linux Kernel CVE Triggerability config set (completed)

Config pruning (delete 𝑐𝑜𝑛𝑓𝑖𝑔𝑖 )

Kernel Compilation

Kernel & PoC Run

Vul. trigger?

ISSTA152:11

No

config set (1-Min)

(𝑐𝑜𝑛𝑓𝑖𝑔𝑖 is essential)

Yes (𝑐𝑜𝑛𝑓𝑖𝑔𝑖 is not essential)

Fig. 4. Runtime-feedback-driven configuration minimization workflow.

4.5

Config Minimization

Stage III removes redundant assignments while preserving matched trigger evidence. We use a runtime feedback loop as shown in Fig. 4: for each candidate assignment 𝑐, we tentatively remove it, re-run make olddefconfig, rebuild and boot the kernel, and execute the PoC, judging triggerability using Trigger𝑡 (Sec. 4.1). If build/boot fails, or the run no longer matches the reference signature, 𝑐 is treated as non-removable. We prioritize candidates with 𝐷 in (𝑐) = 0 (no dependents) to reduce cascading deactivation; each candidate is attempted at most once. If 𝑐 is necessary, we freeze its prerequisite closure to preserve satisfiability and operational 1-minimality. Algorithm 2 instantiates this loop using 𝐺 = (𝑉 , 𝐴, 𝐷 in ). It initializes a worklist 𝑄 with candidates that have no dependents, and maintains: Tried, to attempt each candidate at most once, and Frozen, to prevent removing assignments in the prerequisite closure of a necessary one. IsRedundant(𝑐, 𝑆, 𝑃) implements the try-remove test described above. If 𝑐 is removed, we decrement the dependent counts of its prerequisites 𝑣 ∈ 𝐴[𝑐] and push newly-unblocked prerequisites with 𝐷 in (𝑣) = 0 into 𝑄. If 𝑐 is necessary, PropagateNecessity freezes 𝑐’s prerequisite closure along outgoing edges. Algorithm 2 Config Minimization (1-minimal) Input: 𝐺 = (𝑉 , 𝐴, 𝐷 in ), 𝑆, 𝑃 Output: 𝑆 min 1: 𝑄 ← {𝑣 | 𝐷 in (𝑣) = 0}; 𝑇𝑟𝑖𝑒𝑑 ← ∅; 𝐹𝑟𝑜𝑧𝑒𝑛 ← ∅ 2: while 𝑄 ≠ ∅ do 3: 𝑐 ← 𝑝𝑜𝑝 (𝑄) 4: if 𝑐 ∈ 𝑇 𝑟𝑖𝑒𝑑 ∨ 𝑐 ∈ 𝐹𝑟𝑜𝑧𝑒𝑛 then continue 5: 𝑇 𝑟𝑖𝑒𝑑 ← 𝑇 𝑟𝑖𝑒𝑑 ∪ {𝑐} 6: if 𝐼𝑠𝑅𝑒𝑑𝑢𝑛𝑑𝑎𝑛𝑡 (𝑐, 𝑆, 𝑃) then 7: 𝑆 ← 𝑆 \ {𝑐} 8: for each 𝑣 ∈ 𝐴[𝑐] do 9: 𝐷 in (𝑣) ← 𝐷 in (𝑣) − 1 10: if 𝐷 in (𝑣) = 0 then 11: 𝑄 ← 𝑄 ∪ {𝑣 } 12: end if 13: end for 14: else 15: 𝑃𝑟𝑜𝑝𝑎𝑔𝑎𝑡𝑒𝑁 𝑒𝑐𝑒𝑠𝑠𝑖𝑡𝑦(𝑐, 𝐹𝑟𝑜𝑧𝑒𝑛, 𝐺) 16: end if 17: end while 18: return 𝑆 min ← 𝑆

5

Experimental Setup

We conduct experiments to evaluate FCC and answer the following research questions (RQs). • RQ1: Configuration identification and redundancy. Can FCC identify a vulnerabilitytriggering candidate option set while introducing as few irrelevant options as possible? We Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

ISSTA152:12

Tongjie Wei, Peng Zhang, Zhiwen Hu, Xupu Hu, Chen Lyu, and Gangyan Zeng

compare FCC with KernJC [28] in terms of candidate-set redundancy and coverage of the available reference option sets. • RQ2: Correctness of dependency completion. When candidate options become ineffective due to unmet dependencies, can FCC recursively infer and add the required prerequisites so that critical options remain enabled in the final .config? We evaluate FCC’s ability to complete dependencies for critical options on two datasets [12, 28]. • RQ3: Effectiveness of runtime-validated minimization. While preserving PoC triggerability, can FCC remove redundant configuration options through runtime validation? We compare configuration size before and after minimization, record the number of pruning attempts, and verify that the minimized configuration can still trigger the vulnerability. • RQ4: Efficiency of FCC stage-wise execution. What is the resource cost of FCC across its three stages, and which stage dominates the end-to-end execution cost? We measure token consumption and execution time for candidate identification, dependency completion, and runtime-validated minimization. We further evaluate a CVE-focused evidence-selection variant of Stage I to quantify the reducible overhead in the dominant stage. 5.1

Evaluation Datasets

We evaluate FCC on the KernJC dataset [6] and the KernelCTF dataset [12], both containing Linux kernel CVE samples. The KernJC dataset includes proof-of-concept (PoC) programs for 66 CVEs, together with the configuration option sets identified by KernJC. The KernelCTF dataset contains 57 CVEs, and each CVE’s description document specifies the configuration options that must be additionally enabled beyond the default configuration. We refer to such options required on top of the default configuration as critical configuration options. Since FCC is designed to assess and synthesize vulnerability-triggering configurations under production-tailored settings, our evaluation focuses on vulnerabilities that require enabling additional options beyond the default configuration. To this end, we manually reproduced all 66 CVEs in the KernJC dataset and found that 34 can be successfully triggered under the default configuration generated by make defconfig without enabling any extra options. These CVEs do not exercise FCC’s ability to identify and complete critical configuration options and are therefore excluded from our evaluation set. As a result, we retain the remaining 32 CVEs from the KernJC dataset that require additional configuration beyond defconfig. KernJC and KernelCTF overlap on one CVE. After removing this overlap from KernelCTF, our final evaluation dataset consists of 88 CVEs (32 from KernJC and 56 from KernelCTF). We use this 88-CVE dataset to evaluate FCC’s capability in configuration identification and dependency completion (RQ1 and RQ2). For RQ1, KernelCTF provides document-level required options and is used as the external reference for coverage evaluation. For KernJC, which does not provide document-level ground truth for critical configuration options, we evaluate whether the initial candidate sets contain the runtime-validated trigger boundary and how much redundancy they introduce. We further perform a KernJC-start minimization control to check whether minimizing the KernJC-provided sets leads to the same trigger-preserving boundary as FCC. RQ3 is conducted on the 32 KernJC CVEs with runnable PoCs. 5.2

Baseline

Baseline for RQ1. KernJC [28] is a representative approach for Linux kernel CVE configuration analysis. It infers vulnerability-related options primarily from Kconfig dependency relations and provides identified configuration sets for the CVEs in its dataset, making it suitable for comparison. Baseline for RQ2. For the configuration injection step, we use an olddef-only baseline strategy: after injecting candidate options into .config, we run make olddefconfig once to normalize Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

Inferring 1-Minimal Trigger Configurations for Assessing Linux Kernel CVE Triggerability

ISSTA152:13

the configuration under Kconfig constraints and obtain the final effective configuration used for building. This baseline captures the standard kernel build behavior where options with unmet dependencies may be silently disabled during configuration normalization. 5.3

Evaluation Metrics

We report evaluation metrics aligned with the four research questions. Configuration Identification (RQ1). We evaluate identification quality from two perspectives: coverage of critical configuration options and redundancy of the inferred candidate set. Let 𝐶 denote the candidate set inferred by a method (FCC or KernJC), and let 𝐾 denote the critical option set when document-level critical-option labels are available. We define a CVE as covered if all critical options are included in the candidate set (i.e., 𝐾 ⊆ 𝐶). Accordingly, we report CVE Coverage (%) as the percentage of CVEs in the dataset that are covered. To measure redundancy, we report the Average Candidate Set Size (Avg. |𝐶 |). Since the goal is to encompass 𝐾 with as few irrelevant options as possible, a smaller |𝐶 | (under high coverage) indicates lower redundancy. For KernelCTF CVEs, 𝐾 is taken from the accompanying documents (i.e., options that must be enabled beyond defconfig). For the KernJC dataset, the provided configuration sets contain redundant options and do not include document-level ground-truth critical configuration options. We therefore use the runtime-validated trigger boundary as the reference set for RQ1. This boundary is first obtained by FCC’s minimization and then cross-checked by a KernJC-start minimization control: starting from each KernJC-provided set, removing the options outside this boundary still preserves effectiveness and the same trigger signature. Thus, on KernJC, CVE coverage measures whether a candidate set contains the experimentally confirmed trigger boundary, while Avg. |𝐶 | measures the redundancy introduced to contain that boundary. Dependency Completion (RQ2). Dependency completion is evaluated based on two dimensions: effectiveness after configuration normalization and efficiency of the inference process. For each CVE, we inject the completed configuration into .config, run make olddefconfig, and verify whether all critical options in 𝐾 remain enabled in the final configuration. We report: (i) the configuration success rate, defined as the percentage of test cases (CVEs) for which all critical options take effect without rollback; and (ii) the convergence efficiency, measured by the number of inference iterations required for FCC to reach a stable configuration state. Runtime-Validated Minimization (RQ3). We evaluate minimization efficiency and convergence using structural and procedural statistics of the minimization process. Specifically, we report (i) the configuration reduction rate, measured by the number of options before and after minimization (|𝐶 | vs. |𝑆 min |); (ii) the size of the dependency graph used in minimization, including the number of nodes |𝑉 | and edges |𝐴|; and (iii) the total number of pruning rounds until convergence. We additionally verify that 𝑆 min preserves PoC triggerability under the trigger oracle. Runtime and Token Overhead (RQ4). We measure per-CVE wall-clock time and LLM token use for each FCC stage. Stage I covers evidence collection, cue normalization, and candidate identification; Stage II covers dependency completion and repeated make olddefconfig checks; Stage III covers runtime-validated minimization, including kernel compilation, VM booting, and PoC execution. Because Stage III requires runnable PoCs, we report it on the KernJC subset; for KernelCTF, we report Stage I and Stage II overhead only. 5.4 Implementation Details We report the implementation and environment details required for exact replay, including the toolchain/kernel build settings, oracle parameters (timeouts and iteration limits), and the fixed LLM version/decoding configuration used in Stage I. The FCC prototype is implemented in approximately 3,200 lines of Python code, leveraging the LangChain framework for orchestration. Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

ISSTA152:14

Tongjie Wei, Peng Zhang, Zhiwen Hu, Xupu Hu, Chen Lyu, and Gangyan Zeng

FCC fetches CVE pages and external references, extracts plain text, and caches snapshots for replay. We use OpenAI GPT-5.1 (snapshot: gpt-5.1-2025-11-13) with temperature 0. The model is invoked for Stage I candidate identification, Stage II constraint parsing, and Stage III triggerevidence matching. We enforce JSON outputs with schema/regex checks and retry invalid responses, flagging persistent failures for manual inspection. For consistency and fairness in comparison with KernJC, we strictly adopt the same target kernel versions as used in KernJC for experiments on the KernJC dataset. For the KernelCTF dataset, we additionally apply KernJC’s version identification procedure to determine the corresponding target kernel version for each CVE. This ensures that FCC and KernJC perform configuration inference, dependency completion, and trigger validation under the same (or equivalent) version context, avoiding biases introduced by kernel-version discrepancies. Stage III runs on a 144-core Intel Xeon Platinum 8352V server with 500 GB RAM. We compile the Stage II completed configuration, boot the kernel with a BusyBox rootfs [33] under QEMU/KVM [5], and run the PoC inside the VM. Experiments use Ubuntu 20.04.6 LTS; kernels ≤ 4.x are built in an Ubuntu 16.04.7 Docker container to avoid toolchain incompatibilities. FCC validates Kbuild realization by mapping each retained option to its Kbuild Makefile entry and checking the expected output. For example, CONFIG_NF_TABLES maps to obj-$(CONFIG_NF_ TABLES) += nf_tables.o; =y requires the object in built-in.a/built-in.o, and =m requires a .ko listed in modules.order. FCC records the matched entry and observed output as audit evidence. To ensure deterministic evaluation and prevent resource exhaustion, we enforced strict iteration limits and timeouts throughout the pipeline. Specifically, during the dependency completion process in Stage II, we set the maximum number of iterations to 10 to effectively preclude infinite loops during dependency inference. For the configuration minimization phase in Stage III, we imposed explicit timeout thresholds for critical operations: the maximum time allowed for kernel compilation is set to 300 s, while both virtual machine booting and PoC execution are strictly limited to 60 s. Any operation exceeding these time windows is deemed a failure for the current iteration.

6 Experimental Results 6.1 Configuration Identification and Redundancy (RQ1) Table 1 presents the performance of FCC and KernJC in configuration identification on two evaluation datasets (KernJC and KernelCTF). On the KernJC dataset (32 CVEs), both FCC and KernJC successfully covered all 32 CVEs under the runtime-validated trigger-boundary reference. FCC achieves full coverage with substantially fewer candidate options: 471 candidates in total (Avg. 14.72 per CVE), compared to 2208 candidates for KernJC (Avg. 69.00 per CVE). To check whether this reference boundary is specific to FCC’s starting set, we perform a KernJC-start minimization control. For each KernJC configuration set, we remove all options outside FCC’s validated 𝑆 min , rerun make olddefconfig, rebuild and boot the target kernel, and re-execute the PoC. The resulting configurations still pass make olddefconfig, build and boot successfully, and reproduce the same trigger signature for 32 CVEs. This confirms that KernJC and FCC reach the same trigger-preserving boundary on this subset, while FCC starts from a far smaller set. On the KernelCTF dataset (56 CVEs), FCC covers 53 CVEs (94.6%), while KernJC covers 50 CVEs (89.3%). FCC produces a much smaller candidate set (1458 in total; Avg. 27.51 per CVE) than KernJC (10088 in total; Avg. 201.76 per CVE), indicating lower redundancy while maintaining high coverage. Figure 5 shows the frequency distribution of the numbers of identified candidate options, highlighting structural differences between the two methods. FCC exhibits a highly concentrated, Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

Inferring 1-Minimal Trigger Configurations for Assessing Linux Kernel CVE Triggerability

ISSTA152:15

Table 1. Configuration identification performance of FCC and KernJC on two evaluation datasets. “Covered CVEs” counts the number of CVEs whose critical option set 𝐾 is fully included in the candidate set 𝐶. For KernelCTF, the reference set is taken from documented required options; for KernJC, it is the runtimevalidated trigger boundary cross-checked by the KernJC-start minimization control. Dataset

#CVEs

Method

Covered CVEs

Avg. |𝐶 | (Total)

Coverage (%)

KernJC

32

FCC KernJC

32 32

14.72 (471) 69.00 (2208)

100.0 100.0

KernelCTF

56

FCC KernJC

53 50

27.51 (1458) 201.76 (10088)

94.6 89.3

8 4

N u m b e r o f C V E s

1 2

K e r n J C M e d ia n 1 7 .5 0 M e a n 6 9 .0 0

0

1 0 0

1 2

0

2 0 0

3 0 0

4 0 0

F C C M e d ia n 1 2 .5 0 M e a n 1 4 .7 2

8 4 0 0

K e r n J C M e d ia n 2 8 2 .5 0 M e a n 2 0 1 .7 6

8

1 0 0 2 0 0 3 0 0 4 0 0 N u m b e r o f id e n tifie d c o n fig o p tio n s o n K e r n J C - D

4

N u m b e r o f C V E s

1 2

0 0

1 0 0

1 2

2 0 0

3 0 0

4 0 0

F C C M e d ia n 2 5 .0 0 M e a n 2 7 .5 1

8 0

4 0

1 0 0 2 0 0 3 0 0 4 0 0 N u m b e r o f id e n tifie d c o n fig o p tio n s o n K e r n e lC T F - D

Fig. 5. Comparison of FCC and KernJC in the number of identified configuration options on the KernelCTF and KernJC datasets.

left-skewed distribution on both datasets, with most CVEs falling in the low-count range, indicating consistently smaller candidate sets. In contrast, KernJC shows a much broader dispersion with a pronounced long tail, especially on the KernelCTF dataset, where candidate counts vary substantially and extend to high-redundancy regimes. Overall, the figure complements Table 1 by showing that FCC not only reduces redundancy on average, but also does so consistently across CVEs while maintaining high coverage. Answer to RQ1. FCC achieves higher coverage than KernJC on the KernelCTF dataset while producing substantially smaller candidate sets, reducing redundancy for subsequent dependency completion and minimization. On the KernJC dataset, the KernJC-start control reaches the same runtime-confirmed boundary, showing that FCC’s smaller start set (14.72 vs. 69.00 options/CVE) removes redundancy without losing post-make olddefconfig, build/boot success, or trigger evidence. 6.2

Correctness of Dependency Completion (RQ2)

To quantify the effectiveness of FCC in resolving configuration dependency issues, we compare FCC against the olddef-only baseline strategy (running make olddefconfig after injection without additional inference) across all 88 CVEs. Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

ISSTA152:16

3 0 2 0 1 0 0

1 9

B a s e lin e C o m p le tio n F a ilu re 1 2 1

1 6

1 5

3 6

N u m b e r o f C V E s

N u m b e r o f C V E s

4 0

Tongjie Wei, Peng Zhang, Zhiwen Hu, Xupu Hu, Chen Lyu, and Gangyan Zeng

1 0

1 8 2

K e rn JC -D K e rn e lC T F -D (a ) D e p e n d e n c y c o m p le tio n re s u lts o n tw o d a ta s e ts

S u c c e ss F a ilu re

1 1

0

5 0

0

2 1

1

1

0

0

0

1

1 st ro u n d 2 n d ro u n d 3 rd ro u n d 4 th ro u n d 5 th ro u n d 6 th ro u n d (b ) D is trib u tio n o f d e p e n d e n c y c o m p le tio n ite ra tio n ro u n d s

Fig. 6. Effectiveness of dependency completion.

The baseline shows clear limitations in handling implicit constraints: out of 88 test cases, 33 CVEs (37.5%) encounter configuration rollback, where critical options are disabled due to unsatisfied dependencies. Figure 6 illustrates the breakdown of configuration outcomes and the improvement achieved by FCC. Among these 33 baseline-failed cases, FCC resolves 30 (90.9%) through recursive dependency inference, ensuring that all critical options remain effective in the final build. Overall, the configuration success rate improves from 62.5% (55/88) to 96.6% (85/88). We investigate the remaining 3 cases that do not fully take effect. These failures stem from hard environmental constraints rather than defects in the dependency inference algorithm. For instance, attempting to enable architecture-specific options (e.g., CONFIG_CPU_32v7, which is ARM-only) in an x86 reproduction environment is rejected by Kconfig. After excluding such hard crossarchitecture or hardware constraints, FCC demonstrates high efficacy in dependency repair within the reachable software configuration space. Beyond the final success rate, we analyze the number of inference iterations required for FCC to reach a stable configuration. Across the 33 baseline-failed cases, 48.5% (16/33) are resolved within a single inference iteration round, and 33.3% (11/33) within two iteration rounds, indicating that most missing dependencies are shallow. For deeper dependency chains (e.g., CVE-2018-6555, which involves four layers of dependencies), FCC achieves stepwise completion through multiple iteration rounds. Notably, the unresolved cases typically undergo more exploratory iterations (4.3 rounds on average, up to 6), reflecting that FCC traverses candidate dependency branches until reaching unsatisfiable constraints or exhausting the bounded search space. Answer to RQ2. FCC improves the configuration success rate from 62.5% to 96.6% compared to the olddef-only baseline, while converging efficiently in practice on our dataset.

6.3

Effectiveness of Runtime-Validated Minimization (RQ3)

Prior to configuration minimization, we assessed the reliability of the trigger oracle described in Section 4.1. For each CVE, we launched the test environment five times and, in each launch, recorded the number of PoC executions required to trigger the vulnerability; we report the maximum count observed across the five launches. The results indicate high reproducibility: 31 out of 32 CVEs are triggered by the first PoC execution in all five launches. Accordingly, to reduce false negatives due to runtime flakiness, we set the oracle parameters to 𝑡 = 5 and 𝜏 = 1 (as defined in Section 4.1). Table 2 presents detailed statistics of the minimization process for each CVE. Here, Nodes denotes the number of configuration options in the effective set (after dependency completion) that must be explicitly enabled beyond the default configuration, while Edges represents the necessary dependency relations maintained to ensure these options remain effective. Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

Inferring 1-Minimal Trigger Configurations for Assessing Linux Kernel CVE Triggerability

ISSTA152:17

Table 2. Detailed statistics of runtime-validated configuration minimization. PR: Number of pruning rounds. |𝑆 min | denotes the size of the 1-minimal configuration boundary. CVE ID CVE-2016-10150 CVE-2016-4557 CVE-2016-6187 CVE-2017-16995 CVE-2017-18344 CVE-2017-2636 CVE-2017-6074 CVE-2017-8824 CVE-2018-12233 CVE-2018-5333 CVE-2018-6555 CVE-2019-6974 CVE-2020-16119 CVE-2020-25669 CVE-2020-27194 CVE-2020-27830

#Nodes

#Edges

#PR

|𝑆 min |

21 7 10 13 14 7 13 7 4 11 33 20 5 6 7 6

0 0 0 0 3 0 0 0 0 7 38 19 0 0 0 4

21 7 10 13 13 7 13 7 4 10 32 19 5 6 7 5

2 1 1 1 2 1 1 1 1 1 2 2 1 1 1 2

CVE ID CVE-2020-28941 CVE-2020-8835 CVE-2021-22555 CVE-2021-26708 CVE-2021-27365 CVE-2021-34866 CVE-2021-3490 CVE-2021-3573 CVE-2021-42008 CVE-2021-43267 CVE-2022-0995 CVE-2022-1015 CVE-2022-25636 CVE-2022-32250 CVE-2022-34918 CVE-2023-32233

#Nodes

#Edges

#PR

|𝑆 min |

5 6 15 14 13 10 20 5 12 10 8 12 8 21 42 12

0 0 6 15 11 0 5 0 0 0 0 0 0 6 0 0

5 6 14 12 13 10 20 5 12 10 8 12 8 20 42 12

2 1 2 4 2 1 1 3 3 1 1 2 3 2 1 2

On this dataset, the dependency topology constructed by FCC is structurally sparse. Correspondingly, the number of pruning rounds is typically close to the number of Nodes, suggesting near-linear behavior in practice under FCC’s dependency-guided pruning order. We also quantify the size reduction before and after minimization. The candidate configuration sets generated by FCC in the initial stage contain 14.72 options on average. Following pruning via the runtime feedback loop, the minimized configuration sets contain 1.63 options on average, corresponding to a configuration reduction rate of 88.93%. Compared to KernJC’s average of 69.00 options on the same CVEs, FCC yields a much more compact configuration boundary, with an average size equal to approximately 2.36% of the baseline size. This reduction also contextualizes FCC against fuzzing-oriented configurations. Syzkaller’s Linux-kernel configuration guide recommends feature-rich options for coverage, diagnostics, and bug detection [13], and links to a syzbot reference configuration [15]. We use that linked reference configuration (upstream-apparmor-kasan.config) only as a scale reference: it contains 4,206 enabled CONFIG_* entries set to y or m. Such configurations are appropriate for bug discovery but too broad for identifying the options required for a known CVE to remain triggerable. FCC instead prunes the CVE-derived effective set to a 1-minimal boundary, reaching 1.63 trigger-preserving options per CVE on average. Finally, in all 32 test cases, the minimized configuration sets pass validation under the trigger Oracle: the kernel built from the minimized configuration can still execute the PoC and reproduce the expected crash or error report under the same protocol. This indicates that FCC’s “try-removevalidate” loop converges to an oracle-level 1-minimal set without breaking triggerability on our dataset. We discuss threats to validity and generalization considerations in Sec. 8. Answer to RQ3. FCC’s topology-guided runtime minimization removes redundant configuration options while preserving vulnerability triggerability under the evaluation protocol. On the KernJC CVEs, FCC achieves an 88.93% reduction on average (14.72 to 1.63 options), yielding a compact 1-minimal evaluation boundary. 6.4

Efficiency of FCC Stage-Wise Execution (RQ4)

Figure 7 reports per-CVE time and token costs. Stage I dominates FCC’s overhead: 1977 s / 291.8k tokens on KernJC-D and 502 s / 86.6k tokens on KernelCTF-D, because it processes noisy CVE Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

ISSTA152:18

Tongjie Wei, Peng Zhang, Zhiwen Hu, Xupu Hu, Chen Lyu, and Gangyan Zeng

evidence before candidate mapping. Stage I′ pre-filters retrieved references before prompting, without using validation outcomes: it keeps pages whose extracted text contains target-CVE evidence and excludes generic or non-substantive pages that inflate context length. Candidate mapping and all deterministic validations remain unchanged, so Stage I′ measures avoidable evidence-processing overhead rather than a different inference/validation pipeline. Stage I′ reduces costs to 532 s / 56.2k tokens on KernJC-D and 304 s / 40.4k tokens on KernelCTF-D, i.e., 26.9% / 19.3% and 60.5% / 46.6% of the original time/token costs, respectively. Stage II remains lightweight, taking 68 s / 2.1k tokens per CVE on KernJC-D and 72 s / 1.4k tokens on KernelCTF-D. Stage III is reported on KernJC-D because it requires runnable PoCs; its per-CVE cost of 717 s mainly reflects repeated build/boot/PoC runs, while its LLM token use of 21.6k tokens is attributable to trigger-evidence matching. Across Stage III validation runs, rebuilds and reboots take 91 s and 5 s on average, respectively. 1 .0 × 1 0 4

2 .4 × 1 0 3

2 .4 × 1 0 3

5 .0 × 1 0 3

5 .0 × 1 0 3

1 .2 × 1 0

1 .2 × 1 0 3

E x e c u tio n tim e (s )

1 .0 × 1 0 4 7 .5 × 1 0 3 2 .5 × 1 0 3 0 .0

N u m b e r o f to k e n s

1 .5 × 1 0 6 1 .2 × 1 0 6 9 .0 × 1 0 5 6 .0 × 1 0 5 3 .0 × 1 0 5 0 .0

7 .5 × 1 0 3

S ta g e I

S ta g e II S ta g e III

S ta g e I S ta g e II S ta g e III (a ) P e rfo rm a n c e o n K e rn J C -D

2 .5 × 1 0 3 0 .0 1 .5 × 1 0 6 1 .2 × 1 0 6 9 .0 × 1 0 5 6 .0 × 1 0 5 3 .0 × 1 0 5 0 .0

1 .8 × 1 0 3

1 .8 × 1 0 3 3

6 .0 × 1 0 2 S ta g e I

S ta g e I'

S ta g e I S ta g e I' (b ) Im p ro v e m e n t o n K e rn J C -D

0 .0

6 .0 × 1 0 2 S ta g e I

S ta g e II

8 .0 × 1 0 5 6 .0 × 1 0 5 4 .0 × 1 0 5 2 .0 × 1 0 5 0 .0

S ta g e I S ta g e II (c ) P e rfo rm a n c e o n K e rn e lC T F -D

0 .0

8 .0 × 1 0 5 6 .0 × 1 0 5 4 .0 × 1 0 5 2 .0 × 1 0 5 0 .0

S ta g e I

S ta g e I' 2 5 % ~ 7 5 % 1 .5 I Q R M e d ia n M e a n O u tlie rs

S ta g e I S ta g e I' (d ) Im p ro v e m e n t o n K e rn e lC T F -D

Fig. 7. Runtime and token overhead of FCC. Stage I′ denotes the CVE-focused evidence-selection variant of Stage I.

Answer to RQ4. Stage I is the main overhead source and can be substantially reduced by CVE-focused evidence selection. Stage II remains lightweight, while Stage III’s cost reflects the repeated build/boot/PoC validation needed to preserve runtime triggerability. 7 7.1

Discussion Using the 1-Minimal Boundary for Production Assessment

FCC’s 1-minimal boundary should be used as a configuration-level trigger predicate, not as an exact symbol checklist or a standalone exploitability claim. A production assessment should normalize the vendor configuration on the corresponding kernel tree (e.g., via make olddefconfig or a vendorequivalent process) and compare against the effective configuration. The comparison is role-aware: core options guarding the vulnerable subsystem, interface, driver, or compilation unit must remain effective and Kbuild-realized, whereas dependency-enabling options are witnesses and may be replaced by equivalent selector paths. For example, a kernel that realizes CONFIG_VIRTIO through CONFIG_VIRTIO_MMIO can satisfy the same dependency even if FCC retained CONFIG_VIRTIO_PCI. This conclusion remains configuration-level. Vendor patches, architecture/hardware constraints, and deployment reachability may still prevent runtime triggering; with a runnable PoC, triggerability should be confirmed by matched trigger evidence on the production-effective configuration. Otherwise, FCC reports configuration-level reachability only. Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

Inferring 1-Minimal Trigger Configurations for Assessing Linux Kernel CVE Triggerability

7.2

ISSTA152:19

Error Analysis of Incomplete Cases

Table 3 reports symbol-level omissions or rejected branches, not CVE-level trigger failures. The three Stage I omissions are recoverable because dependency completion can still reach the missed symbols from broader Stage I anchors, such as CIFS, UNIX, or VSOCKETS; if such anchors are also missed, FCC may not recover the prerequisite. In contrast, the three rejected Stage II branches are guarded by architecture- or hardware-specific constraints, such as ARM-only or PMU/KVM-dependent paths, and cannot remain effective in our x86 setting. FCC therefore rejects them after make olddefconfig and Kbuild validation rather than treating them as ordinary missing dependencies.

Table 3. Symbol-level error analysis of incomplete or rejected branches. Type Stage I omission Stage I omission Stage I omission Stage II constraint Stage II constraint Stage II constraint

8

CVE ID CVE-2023-5345 CVE-2024-36972 CVE-2025-21756 CVE-2019-6974 CVE-2024-26808 CVE-2023-6931

Symbol CONFIG_SMBFS CONFIG_AF_UNIX_OOB CONFIG_VSOCKETS_LOOPBACK CONFIG_KVM_ARM_HOST CONFIG_VDSO CONFIG_HW_PERF_EVENTS

Error source SMB3 evidence mapped to CONFIG_CIFS OOB logic hidden behind AF_UNIX Loopback transport not explicit in PoC KVM/VFIO/IOMMU cues vDSO artifacts in PoC perf_event_open() usage

FCC outcome Recovered via CONFIG_CIFS Recovered via CONFIG_UNIX Recovered via CONFIG_VSOCKETS Rejected as ARM-only under x86 Rejected due to ARMv7 dependency Rejected as ARCH/PMU-specific path

Threats to Validity

Internal Validity. Stability of LLM-based inference. Stage I uses an LLM to parse unstructured descriptions; output variability may change the initial candidate set 𝐶 (RQ1). Mitigation: we fix the LLM version and use temperature 0, and treat LLM outputs only as candidates—all options are deterministically validated by Kconfig constraints and make olddefconfig, which filters hallucinations before they enter the final buildable configuration. Scope of Kconfig value types. FCC focuses on boolean/tristate reachability, consistent with Kconfig’s select semantics. Non-boolean int, hex, and string symbols are inherited from the baseline and make olddefconfig unless vulnerability evidence explicitly constrains their values; in our 88-CVE benchmark, no minimized boundary required such a constraint. Reliability of the trigger oracle. Kernel reproducers can be flaky (especially races), so oracle errors may either over-prune necessary options or retain redundant ones (RQ3). Mitigation: we use a repeated-run oracle Trigger𝑡 (𝑡 = 5, 𝜏 = 1) with signature matching; however, this does not guarantee oracle-level 1-minimality under extremely low-probability triggers. External Validity. Dataset representativeness. We evaluate on 88 CVEs from KernJC and KernelCTF, which may not cover all subsystems or proprietary drivers. We exclude 34 defconfigtrivial cases and release the CVE list and filters to make the scope explicit; conclusions mainly apply to upstream vulnerabilities with public reproduction artifacts and are limited when only text descriptions are available. Generalizability to downstream kernels. FCC is validated on upstream kernels. Applying an inferred boundary to distribution or vendor-patched trees still requires vendor-side adaptation: normalizing the production configuration on the downstream tree, mapping vendor-only options or patches to the inferred boundary, and confirming interface reachability. Triggerability also remains conditional on the required architecture, hardware, and virtualization environment. Hardware and environmental constraints. The remaining 3 RQ2 failures are environmentlimited (e.g., arch-specific options unavailable on our infrastructure). FCC does not emulate missing peripherals or cross-architecture setups; therefore, triggerability is conditional on the required virtualization/hardware environment. Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

ISSTA152:20

9

Tongjie Wei, Peng Zhang, Zhiwen Hu, Xupu Hu, Chen Lyu, and Gangyan Zeng

Related Work

Vulnerability reproduction often fails due to missing or mismatched context [23]. Configuration prerequisites are often under-specified and hard to trace from artifacts [7]; for kernels, even automated environment generation remains configuration-sensitive [28]. We position FCC on Kconfig/Kbuild-aware reasoning, outputting an effective (post-make olddefconfig) boundary and, with a PoC, an operational 1-minimal triggering boundary. Vulnerability reproducibility and missing reproduction context. Reports frequently omit reproductioncritical details and can be internally inconsistent; vulnerability databases may also contain noisy affected-version information [8, 23, 24]. Prior work either recovers coarse configuration-related evidence from artifacts [7] or refines affected-version ranges using commit/code evidence [3]. In contrast, FCC synthesizes prerequisites that survive make olddefconfig and supports protocol-guided minimization when trigger evidence exists. Automation of reproduction and cross-environment adaptation. PoC/exploit adaptation and analysis pipelines mainly target portability across kernels/versions or ecosystems [4, 20, 22, 27, 35]. FCC instead keeps the reproducer fixed and infers configuration prerequisites that may be missing or become ineffective after Kconfig/Kbuild constraint resolution. Kernel configuration inference and Kconfig/Kbuild-aware analysis. KernJC expands static Kconfig dependencies to identify vulnerability-related options [28]. Related work studies traceability/documentation [2], scalable sampling [10], specification defects [26], conflict resolution [11], and variability bugs [1]. FCC adds post-make olddefconfig effectiveness/Kbuild realization checks and, with a PoC, derives a runtime-validated 1-minimal boundary under a fixed protocol. LLMs for reproduction and debugging assistance. LLM-based systems generate tests/steps and use feedback for reproduction (e.g., LIBRO [21], AdbGPT [9], CrashTranslator [18], ReBL [31]) and can be improved via self-debugging training (e.g., LeDex [19]). In contrast, FCC confines LLMs to candidate identification, constraint parsing, and evidence matching, then gates them by make olddefconfig-based effectiveness checks and protocol-defined trigger validation.

10

Conclusion

This paper targets trigger-configuration inference for Linux kernel CVEs under production-tailored settings, where upstream reproducers often omit configuration context and static dependency expansion is prone to rollback under make olddefconfig and over-approximation. We presented FCC, which mines configuration candidates from vulnerability evidence, completes Kconfig prerequisites under make olddefconfig feedback, and prunes options using runtime trigger evidence. FCC outputs a configuration boundary that is effective after make olddefconfig and 1-minimal under an oracle-defined protocol validated in our upstream QEMU/KVM setting. On 88 historical CVEs, FCC improves over KernJC (RQ1) and an olddef-only injection baseline (RQ2): the post-make olddefconfig effectiveness rate increases from 62.5% to 96.6%, and the average candidate set size on the KernJC dataset drops from 69.00 to 14.72 while retaining coverage. On the 32 KernJC CVEs with runnable PoCs, FCC further reduces the option set from 14.72 to 1.63 on average without changing the matched trigger signature under the same protocol (RQ3). Stage-wise analysis identifies Stage I as the main overhead source and CVE-focused evidence selection as an effective way to reduce this cost (RQ4). FCC claims triggerability only when a runnable PoC is available, and applying the inferred boundaries to heavily patched downstream kernels or hardware-specific environments may require additional adaptation.

Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

Inferring 1-Minimal Trigger Configurations for Assessing Linux Kernel CVE Triggerability

11

ISSTA152:21

Data Availability

All experimental data and source code used in this paper are available at https://github.com/Cyberwei10/FCC; an accompanying artifact is archived on Zenodo [32]. Acknowledgments We would like to thank the anonymous reviewers for their insightful and detailed feedback. This work is funded by Basic Research Program of Jiangsu (BK20252040, BK20251414). References [1] Iago Abal, Jean Melo, Ştefan Stănciulescu, Claus Brabrand, Márcio Ribeiro, and Andrzej Wąsowski. 2018. Variability Bugs in Highly Configurable Systems: A Qualitative Analysis. ACM Trans. Softw. Eng. Methodol. 26, 3, Article 10 (Jan. 2018), 34 pages. doi:10.1145/3149119 [2] Jobayer Ahmmed, Myra B. Cohen, and Paul Gazzillo. 2024. Towards Automated Configuration Documentation. In Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering (Sacramento, CA, USA) (ASE ’24). Association for Computing Machinery, New York, NY, USA, 2256–2261. doi:10.1145/3691620.3695311 [3] Lingfeng Bao, Xin Xia, Ahmed E. Hassan, and Xiaohu Yang. 2022. V-SZZ: automatic identification of version ranges affected by CVE vulnerabilities. In Proceedings of the 44th International Conference on Software Engineering (Pittsburgh, Pennsylvania) (ICSE ’22). Association for Computing Machinery, New York, NY, USA, 2352–2364. doi:10.1145/3510003. 3510113 [4] Tiffany Bao, Ruoyu Wang, Yan Shoshitaishvili, and David Brumley. 2017. Your Exploit is Mine: Automatic Shellcode Transplant for Remote Exploits. In 2017 IEEE Symposium on Security and Privacy (SP). 824–839. doi:10.1109/SP.2017.67 [5] Fabrice Bellard. 2005. QEMU, a Fast and Portable Dynamic Translator. In 2005 USENIX Annual Technical Conference (USENIX ATC 05). USENIX Association, Anaheim, CA, 41–46. https://www.usenix.org/conference/2005-usenix-annualtechnical-conference/qemu-fast-and-portable-dynamic-translator [6] Bonan Ruan. 2026. KernJC Dataset. https://github.com/NUS-Curiosity/KernJC/tree/main/db [7] Ligeng Chen, Jian Guo, Zhongling He, Dongliang Mu, and Bing Mao. 2021. RoBin: Facilitating the Reproduction of Configuration-Related Vulnerability. In 20th IEEE International Conference on Trust, Security and Privacy in Computing and Communications, TrustCom 2021, Shenyang, China, October 20-22, 2021. IEEE, 91–98. doi:10.1109/TrustCom53373. 2021.00030 [8] Lingyan Ding, Xingya Wang, Zhenyu Chen, and Song Huang. 2025. POSVIA: Inconsistency analyzer for open-source Proof-of-Concept reports. Information and Software Technology 188 (2025), 107868. doi:10.1016/j.infsof.2025.107868 [9] Sidong Feng and Chunyang Chen. 2024. Prompting Is All You Need: Automated Android Bug Replay with Large Language Models. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering (Lisbon, Portugal) (ICSE ’24). Association for Computing Machinery, New York, NY, USA, Article 67, 13 pages. doi:10.1145/ 3597503.3608137 [10] David Fernandez-Amoros, Ruben Heradio, Christoph Mayr-Dorn, and Alexander Egyed. 2023. Scalable Sampling of Highly-Configurable Systems: Generating Random Instances of the Linux Kernel. In Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering (Rochester, MI, USA) (ASE ’22). Association for Computing Machinery, New York, NY, USA, Article 89, 12 pages. doi:10.1145/3551349.3556899 [11] Patrick Franz, Thorsten Berger, Ibrahim Fayaz, Sarah Nadi, and Evgeny Groshev. 2021. ConfigFix: interactive configuration conflict resolution for the Linux kernel. In Proceedings of the 43rd International Conference on Software Engineering: Software Engineering in Practice (Virtual Event, Spain) (ICSE-SEIP ’21). IEEE Press, 91–100. doi:10.1109/ICSESEIP52600.2021.00018 [12] Google. 2026. kernelCTF rules. https://google.github.io/security-research/kernelctf/rules.html. [13] Google. 2026. Linux Kernel Configs for Syzkaller. https://github.com/google/syzkaller/blob/master/docs/linux/kernel_ configs.md. [14] Google. 2026. syzbot. https://syzkaller.appspot.com/upstream. [15] Google. 2026. syzbot upstream-apparmor-kasan Reference Configuration. https://github.com/google/syzkaller/blob/ master/dashboard/config/linux/upstream-apparmor-kasan.config. [16] Google Cloud. 2026. OS images. https://docs.cloud.google.com/compute/docs/images [17] Sanan Hasanov, Stefan Nagy, and Paul Gazzillo. 2025. A Little Goes a Long Way: Tuning Configuration Selection for Continuous Kernel Fuzzing. In Proceedings of the IEEE/ACM 47th International Conference on Software Engineering (Ottawa, Ontario, Canada) (ICSE ’25). IEEE Press, 795–807. doi:10.1109/ICSE55347.2025.00042 [18] Yuchao Huang, Junjie Wang, Zhe Liu, Yawen Wang, Song Wang, Chunyang Chen, Yuanzhe Hu, and Qing Wang. 2024. CrashTranslator: Automatically Reproducing Mobile Application Crashes Directly from Stack Trace. In Proceedings Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

ISSTA152:22

Tongjie Wei, Peng Zhang, Zhiwen Hu, Xupu Hu, Chen Lyu, and Gangyan Zeng

of the IEEE/ACM 46th International Conference on Software Engineering (Lisbon, Portugal) (ICSE ’24). Association for Computing Machinery, New York, NY, USA, Article 18, 13 pages. doi:10.1145/3597503.3623298 [19] Nan Jiang, Xiaopeng Li, Shiqi Wang, Qiang Zhou, Soneya Binta Hossain, Baishakhi Ray, Varun Kumar, Xiaofei Ma, and Anoop Deoras. 2024. LeDex: Training LLMs to Better Self-Debug and Explain Code. In Advances in Neural Information Processing Systems, A. Globerson, L. Mackey, D. Belgrave, A. Fan, U. Paquet, J. Tomczak, and C. Zhang (Eds.), Vol. 37. Curran Associates, Inc., 35517–35543. doi:10.52202/079017-1120 [20] Zheyue Jiang, Yuan Zhang, Jun Xu, Xinqian Sun, Zhuang Liu, and Min Yang. 2023. AEM: Facilitating Cross-Version Exploitability Assessment of Linux Kernel Vulnerabilities. In 2023 IEEE Symposium on Security and Privacy (SP). 2122–2137. doi:10.1109/SP46215.2023.10179286 [21] Sungmin Kang, Juyeon Yoon, and Shin Yoo. 2023. Large Language Models are Few-Shot Testers: Exploring LLM-Based General Bug Reproduction. In Proceedings of the 45th International Conference on Software Engineering (Melbourne, Victoria, Australia) (ICSE ’23). IEEE Press, 2312–2323. doi:10.1109/ICSE48619.2023.00194 [22] Lukas Maar, Florian Draschbacher, Lukas Lamster, and Stefan Mangard. 2024. Defects-in-Depth: Analyzing the Integration of Effective Defenses against One-Day Exploits in Android Kernels. In 33rd USENIX Security Symposium (USENIX Security 24). USENIX Association, Philadelphia, PA, 4517–4534. https://www.usenix.org/conference/usenixsecurity24/ presentation/maar-defects [23] Dongliang Mu, Alejandro Cuevas, Limin Yang, Hang Hu, Xinyu Xing, Bing Mao, and Gang Wang. 2018. Understanding the Reproducibility of Crowd-reported Security Vulnerabilities. In 27th USENIX Security Symposium (USENIX Security 18). USENIX Association, Baltimore, MD, 919–936. https://www.usenix.org/conference/usenixsecurity18/presentation/ mu [24] Viet Hung Nguyen, Stanislav Dashevskyi, and Fabio Massacci. 2016. An automatic method for assessing the versions affected by a vulnerability. Empirical Softw. Engg. 21, 6 (Dec. 2016), 2268–2297. doi:10.1007/s10664-015-9408-2 [25] NVD. 2026. National Vulnerability Database. https://nvd.nist.gov. [26] Jeho Oh, Necip Fazıl Yıldıran, Julian Braha, and Paul Gazzillo. 2021. Finding broken Linux configuration specifications by statically analyzing the Kconfig language. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. New York, NY, USA, 893–905. doi:10.1145/3468264.3468578 [27] Pansilu Pitigalaarachchi, Xuhua Ding, Haiqing Qiu, Haoxin Tu, Jiaqi Hong, and Lingxiao Jiang. 2023. KRover: A Symbolic Execution Engine for Dynamic Kernel Analysis. In Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (Copenhagen, Denmark) (CCS ’23). Association for Computing Machinery, New York, NY, USA, 2009–2023. doi:10.1145/3576915.3623198 [28] Bonan Ruan, Jiahao Liu, Chuqi Zhang, and Zhenkai Liang. 2024. KernJC: Automated Vulnerable Environment Generation for Linux Kernel Vulnerabilities. In Proceedings of the 27th International Symposium on Research in Attacks, Intrusions and Defenses (Padua, Italy) (RAID ’24). Association for Computing Machinery, New York, NY, USA, 384–402. doi:10.1145/3678890.3678891 [29] The kernel development community. 2026. Kbuild. https://docs.kernel.org/kbuild/kbuild.html [30] The kernel development community. 2026. Kconfig Language. https://www.kernel.org/doc/html/next/kbuild/kconfiglanguage.html [31] Dingbang Wang, Yu Zhao, Sidong Feng, Zhaoxu Zhang, William G. J. Halfond, Chunyang Chen, Xiaoxia Sun, Jiangfan Shi, and Tingting Yu. 2024. Feedback-Driven Automated Whole Bug Report Reproduction for Android Apps. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (Vienna, Austria) (ISSTA 2024). Association for Computing Machinery, New York, NY, USA, 1048–1060. doi:10.1145/3650212.3680341 [32] Tongjie Wei, Peng Zhang, Zhiwen Hu, Xupu Hu, Chen Lyu, and Gangyan Zeng. 2026. Inferring 1-Minimal Trigger Configurations for Assessing Linux Kernel CVE Triggerability (Artifact). doi:10.5281/zenodo.20988950 [33] Nicholas Wells. 2000. BusyBox: A Swiss Army Knife for Linux. Linux J. 2000, 78es (Oct. 2000), 10–es. https: //www.linuxjournal.com/node/4238 [34] Qiushi Wu, Yue Xiao, Xiaojing Liao, and Kangjie Lu. 2022. OS-Aware Vulnerability Prioritization via Differential Severity Analysis. In 31st USENIX Security Symposium (USENIX Security 22). USENIX Association, Boston, MA, 395–412. https://www.usenix.org/conference/usenixsecurity22/presentation/wu-qiushi [35] Xiaochen Zou, Yu Hao, Zheng Zhang, Juefei Pu, Weiteng Chen, and Zhiyun Qian. 2024. SyzBridge: Bridging the Gap in Exploitability Assessment of Linux Kernel Bugs in the Linux Ecosystem. In 31st Annual Network and Distributed System Security Symposium, NDSS. doi:10.14722/ndss.2024.24926 [36] Xiaochen Zou, Guoren Li, Weiteng Chen, Hang Zhang, and Zhiyun Qian. 2022. SyzScope: Revealing High-Risk Security Impacts of Fuzzer-Exposed Bugs in Linux kernel. In 31st USENIX Security Symposium (USENIX Security 22). USENIX Association, Boston, MA, 3201–3217. https://www.usenix.org/conference/usenixsecurity22/presentation/zou

Received 2026-01-30; accepted 2026-06-25 Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA152. Publication date: October 2026.

Related documents

• Inferring 1-Minimal Trigger Configurations for Assessing Linux Kernel CVE Triggerability#612646
• Inferring 1-Minimal Trigger Configurations for Assessing Linux Kernel CVE Triggerability#611169
• CVE-2026-83196 — CRITICAL 9.1#923742
• CVE-2026-97935#1098377
• CVE-2026-83229 — CRITICAL 9.1#923744