Cuda-Gen：一种基于 API 知识图覆盖驱动的CUDA模糊测试框架

Cuda-Gen： An API-knowledge-graph coverage-driven fuzzing framework for CUDA libraries

摘要

在人工智能驱动的时代，NVIDIA CUDA库已成为加速计算密集型任务不可或缺的工具，但由于其闭源代码和独特的编程范式，其安全性评估仍然严重不足。现有研究还没有专门针对CUDA库的漏洞挖掘工具。本文讨论了对CUDA库进行模糊测试所面临的挑战：1） 缺乏指导导致生成的测试驱动能够覆盖的API范围有限；2） 基于大模型生成的测试驱动在输入变异方面效率低下。本文提出了一种名为Cuda-Gen的新工具，用于发现CUDA库中的潜在漏洞。Cuda-Gen能够从零开始为各种CUDA库函数生成测试驱动，执行高效的参数变异，并适配多种CUDA库的需求。首先，利用大语言模型（LLM）从CUDA文档和示例代码中提取语义关系，构建知识图谱，从而优先考虑API交互与上下文依赖关系。提出API覆盖位图，以引导模糊测试器探索测试不足的库函数。此外，API知识图谱还结合编译器诊断信息来修复错误的桩代码，从而提升编译成功率。随后，Cuda-Gen使用大模型分析并解耦参数依赖关系，区分可变参数，对其进行参数隔离变异，以提高变异效率。在3个CUDA版本（12.4、12.7和13.0）以及6个被广泛使用的库（如 cuBLAS、cuFFT）上的评估表明，Cuda-Gen相较于基线工具 Fuzz4all，平均实现了2.97倍的API覆盖率和4.0倍的API边覆盖率。实验还发现了3个未知漏洞，已由NVIDIA安全团队验证。

Abstract

In the AI-driven era， NVIDIA CUDA libraries have become indispensable for accelerating compute-intensive tasks， yet their security assessment remains critically understudied due to closed-source code and unique program.gming paradigms.Existing efforts primarily focus ontarget CUDA compiler vulnerabilities （e.g.， NVCC）， but leaving library-level risks largely unexplored.overlook broader library-specific risks.This The paper addresses the challenges of fuzzing CUDA libraries： 1） the absence of guidance narrows the set of APIs that generated harnesses can reach； and 2） input mutation remains inefficient for LLM-generated harnesses.We propose Cuda-Gen， Aa new tool called Cuda-Gen has been proposed， aimed at uncovering potential vulnerabilities in the CUDA libraries.Cuda-Gen has the ability tocan generate testing harnesses for various CUDA library functions from scratch， perform efficient parameter mutation， and adapt to the needs of multiple CUDA libraries.First， LLMs are used to extract semantic relationships from CUDA documentation and sample codes， constructing a knowledge graph that prioritizes API interactions and contextual dependencies.We introduce anThe API coverage bitmap is proposed to guide the fuzzer to explore under-tested library functions.AdditionallyBesides， we integrate the API knowledge graph is also combined with compiler diagnostics to automatically repair erroneous harnesses， thereby improving compilation success rates.Subsequently， Cuda-Gen employs the LLMs to analyze and decouple parameter dependencies， separates out the mutable parameters， and performs parameter-isolated mutation on them to enhance mutation efficiency.Evaluated across three CUDA releases （12.4， 12.7， and 13.0） on eightsix widely adopted libraries （e.g.， cuBLAS， cuFFT）， Cuda-Gen achieves on average 2.97× improvements inhigher API coverage and 4.0× improvements insuperior API edge coverage over the baseline tool Fuzz4Allrelative to baseline （Fuzz4all）， on average.The experiments uncovered 43 unknown vulnerabilitiesbugs， validated by NVIDIA’s security team.

Graphical abstract

关键词

模糊测试 / 基于大语言模型的知识图谱 / CUDA库安全 / API覆盖位图

Key words

fuzzing / LLM-based knowledge graph / CUDA libraries security / API coverage bitmap

人工智能已成为现代社会不可或缺的一部分，广泛应用于从基于文本的问答系统^［1］、智能代码自动补全^［2］到自动驾驶系统^［3］等各类场景。其迅速普及在很大程度上得益于规模定律^［4］，该定律表明随着计算资源和数据量的增加，模型能力会出现显著提升。这些进步依赖于加速计算框架的支撑，其中NVIDIA的CUDA^［5］生态系统已成为训练大规模人工智能系统的主流框架。

但是，CUDA框架本身的安全漏洞尚未得到足够重视，目前仅有少量研究涉及CUDA特定漏洞的发现。据我们的调查，目前还没有专门针对CUDA库函数这一丰富生态进行漏洞挖掘的模糊测试工具。如图1a所示，CUDA具有多层次的结构层级。在最上层是用户编写的应用程序（用device标注），其既可以直接在GPU上运行，也可以调用CUDA库例程。在这些应用程序之下，是本研究关注的领域特定库（如用于傅里叶变换的cuFFT），以及CUDA运行时库提供的更多通用例程。在最底层是CUDA驱动，库函数和用户应用程序最终都必须通过它与GPU进行交互。

CUDASmith^［6］受CSmith^［7］启发，通过生成合成的内核函数来对CUDA编译器（NVCC）进行模糊测试。其局限在于只针对NVCC，而忽视了庞大的库函数接口面。Fuzz4ALL^［8］是一种基于大语言模型的多编译器模糊测试器，只需向其输入CUDA文档即可指向 NVCC，模型的生成能力使其能够覆盖相当数量的 CUDA API。然而，其生成的代码存在高度同质化问题。Moneta^［9］则通过模拟GPU行为，在无物理GPU 的情况下对图形驱动进行高吞吐量测试。但这一方法同样仅聚焦于CUDA驱动，难以覆盖库函数。此外，还有一些研究^［10-11］针对GPU编程框架（如OpenCL、WebGL），但与CUDA的相关性较低。尽管OpenCL 和WebGL也与图形驱动交互，但它们并不会调用任何CUDA库函数。

对CUDA库进行模糊测试主要面临以下困难。首先，CUDA的闭源特性阻碍了传统的覆盖引导型模糊测试器（如AFL^［12］和AFL++^［13］）有效发现漏洞。典型的基于QEMU^［14］的黑盒模糊测试方法也无法奏效，因为QEMU无法跟踪GPU指令。因此，在闭源情况下，函数之间的依赖关系难以获取，测试驱动的编写具有很强的随机性。其次，是如何高效地变异测试驱动的输入。依赖大语言模型（LLM）来执行参数变异效率极低，而传统模糊测试的变异方法又不适合CUDA库测试驱动中存在的大量语义相关参数。传统变异方法在CUDA库中失效的原因在于：自动生成的测试驱动往往暴露出多个参数，这些参数的取值范围和相互依赖关系不透明。例如，AFL、AFL++、LibFuzzer^［15］及其优化变异策略（如Mopt^［16］和havoc-mab^［17］），在这种多参数场景下都无法提供针对性的优化。此外，GPU-CPU架构差异导致传统的fork机制不可用，从而限制了输入的吞吐量。如图1b所示，NVCC将源代码（.cu文件）编译为宿主端的汇编代码和机器码，同时将设备端代码编译为PTX（并行线程执行）和SASS（流处理汇编器）代码，并在CPU与GPU上异步执行（通过屏障机制避免数据竞争错误）。最后，需要显式的数据同步以获取计算结果。需要强调的是，设备端代码既不支持传统模糊测试中的fork机制，也无法利用CPU的插桩技术。这些问题共同导致测试驱动执行效率低下。

因此，CUDA库模糊测试的挑战如下： 1） 挑战1：由于缺乏覆盖率引导，CUDA库的闭源特性导致测试驱动的生成呈现无方向性的随机性；2） 挑战 2：在CUDA库模糊测试的多参数场景下，如何选择变异目标并执行高效的参数变异仍然是一个待解决的问题。

为了解决上述挑战，我们提出了Cuda-Gen，一种基于API知识图谱驱动覆盖率的模糊测试框架，专门面向多样化的CUDA库。API知识图谱将领域特定的知识融入提示中，使通用大语言模型（LLMs）能够更好地适应专业化领域。在CUDA代码生成中这个小众领域中（相较于C、Python、Java等主流语言），API知识图谱能够有效引导LLMs生成更易编译的 CUDA代码。

我们从CUDA手册和官方示例中提取API知识，构建知识图谱，用于指导后续基于LLM的测试驱动生成。该图谱明确捕获4个关键要素：API调用、API调用序列、API签名以及描述信息。为系统性地扩展 API组合的覆盖率，同时避免冗余探索，我们基于API 知识图谱构建了一个位图（bitmap）。该位图通过动态排除已执行过的API组合，引导测试过程，将计算资源集中在罕见的API调用路径上，从而显著缓解挑战1。针对挑战2，Cuda-Gen利用LLM识别可变参数及其依赖关系，并通过专门设计的模板执行参数隔离变异，确保语法与语义的正确性，同时更高效地覆盖参数空间。在本文中，参数隔离变异指的是对每个独立参数进行独立的字节级变异，而不是像传统模糊测试器那样将所有变异目标拼接成一个字节流再进行字节级修改。

本文的主要贡献总结如下：1）据我们所知，Cuda-Gen是第一个专门用于CUDA库测试的模糊测试框架。在API知识图谱的引导下，它能够从零开始系统性地测试CUDA函数。2）为应对库测试中大量复杂参数带来的挑战，Cuda-Gen利用大语言模型的语义理解能力识别可变参数及其依赖关系，并执行参数隔离变异，以更高效地探索参数空间。3）在跨3个CUDA版本、覆盖6个CUDA库的实验验证中，Cuda-Gen相比基线实现了2.97倍的API覆盖率和4.0倍的API边覆盖率。同时，Cuda-Gen 已向NVIDIA开发者报告了3个确认漏洞。

1 背景

在库API模糊测试中，测试驱动的生成需要具备较高的语法与语义正确性，以确保可靠的执行。越来越多的研究者借助大语言模型（LLMs）的能力，来合成此类测试驱动，并不断地提升其复杂性与多样性。例如，深度学习库的模糊测试已从单一API 的独立测试^［18］发展到丰富的多调用序列^［19］。将这一趋势扩展到CUDA库时，人们自然希望能够生成同样复杂的测试驱动。然而，CUDA的闭源特性限制了直接提取API之间依赖关系的可能性。我们观察到，开发者在编写CUDA内核时通常会参考官方手册和已有示例代码。因此，我们提出大语言模型同样可以挖掘这些资料来推断API关系。在程序分析的数据流和控制流视角的引导下，我们提示模型不仅要捕获API 之间的调用依赖，还要学习他们在语义上所要求的执行顺序。

灰盒模糊测试在发现漏洞的有效性在很大程度上依赖于覆盖率引导的探索。对于作为闭源黑盒的 CUDA库而言，建立此类引导并非易事。鉴于 GraphFuzz^［20］对API级别的边进行变异、TitanFuzz^［21］则通过大语言模型随机替换库调用，我们提出了类似于传统代码覆盖率位图的API覆盖位图。该结构可以引导模糊测试器优先探索未被触及的API，并防止生成高度同质的测试驱动。

传统的基于C语言的应用程序模糊测试通常将程序输入视为一个连续的二进制文件，并对其执行字节级变异。该设计最大限度地减少了I/O开销，并被固化为标准行为，例如AFL^［12］、libFuzzer^［15］和LLVM sanitizers中的LLVMFuzzerTestOneInput（）。在这种测试驱动中，开发者必须显式地对字节流进行切片，以提取具体的函数参数。为了避免破坏定长字段，灰盒模糊测试器会在初始探索阶段尝试推断不可变的标记。其通常对短字节序列应用轻量级变异（例如单比特翻转），并监控控制流的变化。如果观察到显著偏离，说明这些字节很可能编码了刚性结构，应保持不变。此类推断过程本质上是随机的，并且与源代码级别的控制流紧密耦合。已有研究（例如Hopper^［22］）指出其不完整性，并提出结合跨API依赖关系提示来进行增强。然而，这些技术的前提是具备灰盒可见性，而在闭源的CUDA库中这一条件并不存在。因此，在 CUDA模糊测试中，如何确定参数间的依赖关系并据此执行有针对性的变异仍然是一个悬而未决的挑战。

在测试诸如数据库这类高度结构化的目标时，模糊测试器^［23-26］通常采用参数隔离变异，而不是整体参数变异。这些工具将每个数据库操作视为一个原子操作单元。变异的方式包括添加、删除或修改单个操作单元，从而确保语法正确性，而整体参数变异往往会破坏这种正确性。受以上已有研究的启发，我们将这一范式移植到CUDA程序中。但与数据库不同，CUDA内核并不受严格约束，因此在执行安全的参数隔离变异之前，框架必须首先对输入进行规范化处理。

因此，我们摒弃整体参数变异的方法，改为对每个参数分别独立地进行变异。该策略消除了无意破坏固定结构的风险，并且在理想化模型下，以及在相同的变异执行次数下能够提高触发漏洞的概率。

2 相关工作

CUDA库的漏洞发现需要结合以下两个互补的研究视角：1）将CUDA视为一个独立的编程框架，其具有独特的语法和执行语义，现有的CUDA专用测试方法在方法论上具有直接的参考价值；2）面向库函数模糊测试的一般性技术，它们为CUDA库的API级漏洞检测提供了可迁移的策略。因此，我们从这两个角度对相关研究工作进行分析，以便为本文的贡献提供背景和定位。

2.1 CUDA专用模糊测试技术

以往针对CUDA的漏洞研究主要集中在CUDA驱动和NVCC编译器，这也促使本文聚焦于CUDA库的模糊测试，因为该领域的研究仍然不足。在NVCC测试工具方面，CUDASmith利用了传统且有效的差分测试方法来发现漏洞。具体为通过在CPU和GPU上分别执行代码，并将结果差异作为模糊测试的判定依据。CUDASmith^［6］、CSmith^［7］和CLSmith^［10］一脉相承（从命名也可见端倪），都采用差分测试的方法，分别用于模糊测试NVCC、OpenCL（可视作CUDA的开源替代方案）以及C编译器（如gcc和clang）。然而，CUDASmith也存在一些局限性。它几乎只关注NVCC，并且只覆盖了少量的CUDA库函数。此外，由于其起源于CLSmith，其测试用例仍然基于OpenCL模型，而当代CUDA与OpenCL已有显著差异。因此，CUDASmith并不能为现代CUDA库函数提供全面覆盖。其他研究则针对CUDA驱动函数。例如Sorensen等^［27］和Alglave等^［28］设计了PTX代码集，用于测试CUDA的内存分配相关函数，以发现GPU内存漏洞。Moneta^［9］受 Syzkaller^［29］（一种CPU内核测试工具）启发，通过模拟GPU指令输入，在无需GPU的情况下测试CUDA驱动，从而实现了高吞吐率（可达数百线程），并不受硬件限制。但这种方法仅覆盖了有限的驱动API，因为硬件差异导致模拟行为不足。此外，还有一些研究^{［11，18，30-32］}主要测试构建在CUDA之上的上层应用，如WebGL和深度学习框架（例如 PyTorch、Keras）。这些应用会调用部分CUDA函数以实现高效 GPU加速，因此在测试时会间接覆盖部分CUDA API。尽管如此，这些方法仅覆盖CUDA API的极小部分，并且并非专为CUDA本身的测试而设计。

2.2 通用库API模糊测试

在对库 API 进行模糊测试时，一个主要挑战是测试驱动的自动生成。对于开源库模糊测试器，如GraphFuzz^［20］、Hopper^［22］、Utopia^［33］和PyRTFuzz^［34］，通常通过从源代码中提取抽象语法来推断函数级依赖关系，从而合成测试驱动。这类方法主要能保证语法正确性，但生成的测试驱动往往缺乏语义丰富性。受到LLM强大的代码理解和生成能力的启发，近期有研究者开始利用LLM辅助提升库模糊测试。例如：PromptFuzz^［35］针对C库，通过在OSS-Fuzz^［36］框架生成的测试驱动上加入LLM扩展，在漏洞发现效果上优于Hopper。受PromptFuzz启发，CKGFuzz^［37］也面向C库，利用LLM^［38］提取的API知识图谱来指导API 组合生成。FuzzGEN++^［39］使用LLM解决在测试OEM Android库时遇到的兼容性问题。WhiteFox^［19］和TiTanFuzz^［21］则在深度学习库上进行差分模糊测试，借助LLM引导对现有测试驱动进行变异。上述工作均假设目标库是开源的^［40］。然而，当目标库是闭源时，如何利用LLM保持较高的测试驱动生成成功率，依然是一个关键的开放问题。在另一类工作中，mGPTFuzz^［41］借助LLM^［42］从IoT手册中挖掘规则，用于生成固件接口 API的输入消息。虽然其领域与本文不同，且LLM主要用于输入生成而非测试驱动合成^［43］，但这种基于手册驱动的方法对本文研究具有借鉴意义。在输入模糊方面，常见的模糊测试器（如libfuzzer和AFL++等）会将输入视作一个整体二进制块，由测试驱动负责显式地切片成参数^［44］，并通过反复执行重新发现不可变片段（例如魔数）。Hopper在此基础上更进一步，利用文法解释器对输入块进行解析，从而更准确地定位魔数。与此不同，本文完全抛弃了整体输入块的方式，而是采用参数隔离变异策略：仅对测试驱动中已经合法的初始参数逐字节地进行变异。该策略既能保留参数结构，又能显著提升变异的有效性。

3 方法

本节介绍Cuda-Gen的详细工作流程与技术细节。如图2所示，该过程可分为3个步骤：1） 初始测试驱动生成；2） 参数解耦与隔离变异与；3） 测试驱动的调度执行。

在测试驱动生成阶段，我们利用大语言模型（LLMs）合成每个测试驱动的初始版本。首先，从目标库中构建函数级知识图谱，为LLMs提供待测API的语义与语法信息。为了最大化API覆盖率，我们引入了一种API覆盖机制，将已探索过的API记录在紧凑的位图中，从而引导生成过程优先覆盖尚未涉及的接口。在编译过程中，出现的语法错误信息会与知识图谱进行比对并迭代修复测试驱动，从而提高语法正确性。一旦测试驱动成功编译，即进入封装流水线。在这一阶段，框架借助LLM的语义理解能力以及一套经验匹配规则，解耦测试驱动中出现的多个参数，将代码改写为可重复执行的形式，并为每个可变参数附加变异操作符。

改写后的测试驱动可以在无需重新初始化GPU上下文的情况下反复执行，从而实现类似AFL fork机制提高效率的功能。最终，这些被包装的测试驱动会被调度运行，用于发现库函数中的漏洞。在测试驱动的生成与执行过程中，位图会被持续更新，并作为反馈信息来引导新测试驱动的生成。该反馈循环推动模糊测试器实现更高的API覆盖率，同时优先探索那些仍然难以测试的API。

3.1 API图引导的测试驱动生成

正如一项近期关于基于LLM的模糊测试综述^［45］所强调的那样，虽然LLM在代码生成方面展现出了强大的能力，但其生成代码的可靠性仍值得怀疑。一个突出的缺陷是模型幻觉现象，即模型会虚构不存在的函数或提供错误的函数签名，从而导致生成的代码无法编译。在CUDA库模糊测试的背景下，我们又发现了另一个缺陷：模型倾向于对某些不透明的结构句柄进行“惰性”初始化。例如，在生成操作nvjpegHandle_t的桩代码时，模型常简单地采用脆弱的初始化方式：nvjpeg Handle_t=NULL；我们推测，这种行为差异主要源于训练数据的不平衡。与通用C 代码相比，公开可用的CUDA代码数量稀缺，导致模型缺乏对CUDA特定编程范式的充分接触。因此，它会退化为最简单（但往往不正确）的初始化策略。为缓解这些问题，我们将API知识图谱与精心设计的提示词（prompts）结合使用，作为主要的修复机制。

知识图谱的构建，如式（1）所形式化表示的，被表达为一个四元组G=〈C，O，S，D〉。其中，C表示函数之间的调用关系，其数据结构是一个有序实体对集合〈head，tail〉；O捕捉函数出现的语义顺序，具体实现为一组有序列表；S和D分别表示各个函数的精确签名和文本描述（两者都建模为以函数名为索引的字典）。由于CUDA库是闭源的，其函数间的语义关系无法直接从源代码中恢复。为此，我们转而从官方CUDA文档^［5］和厂商提供的示例程序^［46］中挖掘相关信息，并利用LLM提取函数间的关系事实，从而构建出图谱G。

\begin{array}{l}G=\left(\underset{C}{\underbrace{\left\{f_i\stackrel{\mathrm{c}\mathrm{a}\mathrm{l}\mathrm{l}}{\to }{f}_j\right\}}},\underset{O}{\underbrace{\left[f_{\mathrm{1}}\prec f_{\mathrm{2}}\prec \cdots \prec f_n\right]}},\right.\\ \left.\underset{S}{\underbrace{\left\{f_k\mapsto {\tau }_k\right\}}},\underset{D}{\underbrace{\left\{f_k\mapsto d_k\right\}}}\right)\end{array}（1）

在使用LLM提取知识图谱的过程中，我们首先对收集到的文档进行切分，在此过程中还会通过正则匹配，区分出代码示例和说明文本。接着将文档切片输入LLM，并通过提示词让它找出API的调用关系和先后语义关系。LLM的返回被严格限制为Json格式，以规避不符合要求的输出。最后Cuda-Gen对Json中的API还会在当前设备的Cuda相关动态以及静态库中再检索一次，保证LLM的返回真实可靠。

随后，我们构建了两个覆盖率位图：一个用于表示API之间的调用依赖关系；另一个用于表示它们的语义顺序。这两个位图的联合目标是引导模糊测试器生成具备更丰富API调用模式的测试驱动。在灰盒模糊测试中，位图是一种常见的数据结构，用于表示覆盖情况。通过用API取代基本块，我们的设计避免了反复遍历完整API序列的开销，并显著减少了原本需要用于存储每个测试驱动跟踪列表的内存消耗。

对于每个位图条目的命中值，其计算方式与AFL 边覆盖机制类似。每个API都会被分配一个随机生成的ID。对于两个API，其有向边ID通过式（2）得出，即源ID与目标ID的二元组哈希（⊕表示异或操作）。这些边标识符用于索引位图，从而使模糊测试器能够优先探索尚未覆盖的API调用模式，并为那些难以调用的API分配额外的执行能量。实证分析表明，CUDA库中不同的API边数量少于1000。因此，分配64 K个位图槽位即可保证碰撞概率在统计上可以忽略不计。

\left(\mathrm{I}\mathrm{D}\_\mathrm{A}\mathrm{P}{\mathrm{I}}_a\gg \mathrm{1}\right)\oplus \mathrm{I}\mathrm{D}\_\mathrm{A}\mathrm{P}{\mathrm{I}}_b（2）

在调用位图和顺序位图的联合引导下（本文采用逻辑或的方式，即只要出现调用位图或顺序位图的新命中，就认为当前测试驱动有效），LLM合成测试驱动的过程如算法1所示。首先，对知识图谱G进行深度优先遍历以生成API调用序列，然后LLM 将该序列转化为代码。同时，G提供每个被调用函数的精确签名、描述以及CUDA特有的注意事项。这些信息被注入到提示词中，并结合我们经验性发现提炼出的约束（如图3）。因此，模型生成的测试驱动既语法正确，又具备语义信息。生成的测试驱动会被送入CUDA编译器（NVCC）。任何产生的错误或警告都会被解析，用于隔离错误的API引用，Cuda-Gen随后将每个可疑标识符与真实的库接口进行验证。接下来，测试驱动、编译器诊断信息以及验证结果会反馈给LLM进行修复，循环迭代最多3轮，从而显著提高编译成功率。需要注意的是，虽然警告信息直观上并不阻止编译，但它们可能在运行时触发段错误，因此也必须修复。其修复提示词中包含，测试驱动编译过程中的具体报错内容，经过匹配得出的具体问题函数（包括warning提示的函数），报错函数的具体签名及使用方式。在整个过程中，API覆盖位图持续引导搜索，每个新生成的测试驱动都会分析其调用了哪些API级别的边。这些边会更新位图，任何未引入至少一条未见边的序列都会被丢弃，从而确保计算资源专注于探索新的调用模式。

算法1 自动化桩测试与生成

输入： \mathrm{知识}\mathrm{图谱}\mathrm{G},\mathrm{大语}\mathrm{言模}\mathrm{型}\mathrm{ℳ},\mathrm{A}\mathrm{P}\mathrm{I}\mathrm{覆盖}\mathrm{位图}\mathrm{ℬ}

输出： \mathrm{有效}\mathrm{测试}\mathrm{桩集}\mathrm{合}\mathit{\mathscr{H}}

1）  \mathit{\mathscr{H}}\leftarrow \mathrm{\varnothing };

2） 

3）    \mathrm{a}\mathrm{p}\mathrm{i}\_\mathrm{s}\mathrm{e}\mathrm{q}\leftarrow从G中随机获取通过DFS方法获得的样本；

4）    \mathrm{i}\mathrm{f}\mathrm{a}\mathrm{p}\mathrm{i}\_\mathrm{s}\mathrm{e}\mathrm{q}\bigcap \mathit{ℬ}\mathrm{未包}\mathrm{含新}\mathrm{边}\mathrm{t}\mathrm{h}\mathrm{e}\mathrm{n}

5）    \mathrm{丢弃}\mathrm{a}\mathrm{p}\mathrm{i}\_\mathrm{s}\mathrm{e}\mathrm{q};

6）    \mathrm{c}\mathrm{o}\mathrm{n}\mathrm{t}\mathrm{i}\mathrm{n}\mathrm{u}\mathrm{e};

7） harness（测试驱动）←\mathit{ℳ}.generate（api_seq， G， Rules）；

8）  \mathrm{是否}\mathrm{编译}\mathrm{成功}\leftarrow \mathrm{F}\mathrm{a}\mathrm{l}\mathrm{s}\mathrm{e};

9）  \mathrm{错误}\mathrm{日志}\leftarrow \mathrm{n}\mathrm{u}\mathrm{l}\mathrm{l};

10）  \mathrm{修复}\mathrm{尝试}\leftarrow \mathrm{0};

11）  \mathrm{w}\mathrm{h}\mathrm{i}\mathrm{l}\mathrm{e}\neg \mathrm{是否}\mathrm{编译}\mathrm{成功}\wedge \mathrm{修复}\mathrm{尝试}\le \mathrm{3}\mathrm{d}\mathrm{o}

12）    \mathrm{状态},\mathrm{错误}\mathrm{日志}\leftarrow \mathrm{c}\mathrm{o}\mathrm{m}\mathrm{p}\mathrm{i}\mathrm{l}\mathrm{e}(\mathrm{h}\mathrm{a}\mathrm{r}\mathrm{n}\mathrm{e}\mathrm{s}\mathrm{s});

13）    \mathrm{i}\mathrm{f}\mathrm{状态}=\mathrm{s}\mathrm{u}\mathrm{c}\mathrm{c}\mathrm{e}\mathrm{s}\mathrm{s}\mathrm{t}\mathrm{h}\mathrm{e}\mathrm{n}

14）     \mathit{\mathscr{H}}\leftarrow \mathit{\mathscr{H}}\bigcup \left\{\mathrm{h}\mathrm{a}\mathrm{r}\mathrm{n}\mathrm{e}\mathrm{s}\mathrm{s}\right\};

15）     \mathrm{通过}\mathrm{h}\mathrm{a}\mathrm{r}\mathrm{n}\mathrm{e}\mathrm{s}\mathrm{s}\mathrm{中的}\mathrm{新}API\mathrm{边更}\mathrm{新}\mathit{ℬ};

16）     \mathrm{是否}\mathrm{编译}\mathrm{成功}\leftarrow \mathrm{T}\mathrm{r}\mathrm{u}\mathrm{e};

17）    \mathrm{e}\mathrm{l}\mathrm{s}\mathrm{e}

18）     \mathrm{报错}\mathrm{a}\mathrm{p}\mathrm{i}\leftarrow \mathrm{e}\mathrm{x}\mathrm{t}\mathrm{r}\mathrm{a}\mathrm{c}\mathrm{t}\_\mathrm{f}\mathrm{a}\mathrm{u}\mathrm{l}\mathrm{t}\mathrm{y}\_\mathrm{a}\mathrm{p}\mathrm{i}(\mathrm{错误}\mathrm{日志});

19）     \mathrm{a}\mathrm{p}\mathrm{i}\mathrm{字典}\leftarrow (\mathrm{G},\mathrm{报错}\mathrm{a}\mathrm{p}\mathrm{i});

20）    harness←\mathit{ℳ}.repair（harness， 错误日志，api字典）；

21）     \mathrm{修复}\mathrm{尝试}\leftarrow \mathrm{修复}\mathrm{尝试}+\mathrm{1};

22）    \mathrm{i}\mathrm{f}\mathrm{c}\mathrm{o}\mathrm{n}\mathrm{t}\mathrm{a}\mathrm{i}\mathrm{n}\mathrm{s}\_\mathrm{c}\mathrm{r}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{c}\mathrm{a}\mathrm{l}\_\mathrm{w}\mathrm{a}\mathrm{r}\mathrm{n}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{s}(\mathrm{错误}\mathrm{日志})\mathrm{t}\mathrm{h}\mathrm{e}\mathrm{n}

23）    harness←\mathit{ℳ}.repair（harness，错误日志，（G，告警api））；

24）  \mathrm{r}\mathrm{e}\mathrm{t}\mathrm{u}\mathrm{r}\mathrm{n}\mathit{\mathscr{H}}

3.2 基于 LLM 的参数解耦与隔离变异

前述生成的测试驱动尚不适合对目标函数进行高效模糊测试，因为它们缺乏有效且可重复的变异机制。为解决这一挑战，我们利用LLM的语义理解能力对测试驱动中出现的每个变量进行分析和解耦，识别出独立变量。即不依赖于其他参数或表达式计算的变量，同时排除固定结构，如CUDA句柄和派生量。这一约束将变异域限定在最小的、语法上安全的子集内。

随后，Cuda-Gen根据我们设计的模板对测试驱动进行改写。在改写过程中，模板会参考LLM推断出的参数类型，并强制执行参数间的语义依赖。例如，被变异的数组长度必须与声明的矩阵维度保持兼容。每个可变参数都被分配独立的缓冲区，以支持后续的参数隔离变异。为了保证通用性，可变参数被规范化为以下3类标准类型：1） 标量数值类型（如int n）；2） 连续数组（如float * array）；3） 不透明结构，用单指针表示（如char*表示图像）。对于每一类，Cuda-Gen都采用不同的缓冲区分配、字节级变异以及参数传递策略，以确保测试驱动保持可执行性。虽然CUDA支持C和C++语法，但C++的灵活性增加了共变异复杂度（例如std：：vector）。经过对大量编译失败的CUDA测试驱动的分析，我们将每个复杂结构统一为上述3种基于C风格指针的模板。这种简化既保留了语义上的准确性，又降低了变异复杂度，使 Cuda-Gen在更广泛的测试目标上保持语法和语义的正确性。

对于每个被判定为可变的参数，Cuda-Gen进行独立的字节级变异。该方法不同于传统灰盒模糊测试器，它们通常将整个输入视为一个整体的字节流，并依赖测试驱动来提取各个参数。传统设计在目标仅暴露少量参数时是可行的，但CUDA库函数通常接受5个或更多参数。如果强制模糊测试器将所有参数视为单一的复合输入，就会使自动生成测试驱动变得复杂，同时模糊每个参数的语义。

图4为一个包含单个整数变量m的完整工作流程的代码片段。在实际测试驱动中，这种模式会扩展到更复杂的变量和API。通过将m指定为可变输入后，测试驱动会分配一个输出缓冲区，对m进行字节级变异，并使用新变异的值反复调用目标CUDA API。该封装中包含一个关键的进程内循环，从而消除了反复启动可执行文件的开销。传统模糊测试器通常通过fork和pipe机制来避免上下文创建成本，但CUDA并不提供类似支持。因此，Cuda-Gen在测试驱动内部嵌入了显式的while循环来模拟fork语义。实验结果表明，这一策略将执行吞吐量从约7 次/s提升至每秒数百次。

3.3 测试驱动的调度执行

在库模糊测试中，要对测试驱动生成与执行进行时间分配。本文采用1∶5的数量比例用于生成和执行。具体来说每生成一个测试驱动，执行一个3 min的初始执行，查看是否存在驱动编写有误的问题。之后会从驱动池中挑选5个驱动，每个进行5 min的测试。有些驱动会被重复挑选多次。

测试驱动的调度由优先级评分控制（如式（3）），该评分综合考虑了API多样性、历史执行次数和历史结果。A_i 表示API多样性，测试驱动中包含的API越多，得分越高；E_i 表示执行次数，历史执行次数越少，得分越高，用来避免冗余测试；R_i 表示历史结果，若发生崩溃或超时则R_i =0，否则R_i =1。因此，能够覆盖更多不同API且运行次数较少的测试驱动会获得更高优先级，更有可能被选中；而任何曾经崩溃或超时的测试驱动会被永久淘汰，不再参与后续测试。测试驱动在池中的采样概率通过对所有测试驱动的得分进行对数归一化计算，如式（4）所示。具体而言，每个测试驱动的得分S_i 先通过自然对数变换，再进行归一化处理，以保证总概率和为1。这种方式确保了高价值的测试驱动（如覆盖API多样性高、运行次数少的）会被优先采样，同时也保持整体采样的均衡性。

S_i=R_i\cdot \left(\mathrm{0.6}\cdot \frac{A_i}{\mathrm{m}\mathrm{a}\mathrm{x}(A)}+\mathrm{0.4}\cdot \left(\mathrm{1}-\frac{E_i}{\mathrm{m}\mathrm{a}\mathrm{x}(E)}\right)\right)（3）

在测试驱动执行过程中，判定器会根据进程退出状态将异常行为划分为3类：1） 程序崩溃；2） 执行超时（阈值设定为2 min）；3） 执行失败。

P_i=\frac{\mathrm{l}\mathrm{o}\mathrm{g}\left(S_i+\mathrm{1}\right)}{{\sum }_{j=\mathrm{1}}^N\mathrm{l}\mathrm{o}\mathrm{g}\left(S_j+\mathrm{1}\right)}（4）

其中，执行失败被定义为：在句柄创建例程或任意API调用返回非成功状态码后，测试驱动显式终止的情况。这些判定结果既用于测试驱动的调度，也为后续的人工分析提供依据，以确认潜在漏洞。如程序崩溃、执行超时和执行失败（比如Cuda中某些结构体创建或执行失败）都会通过python的subprocess模块退出码进行判定。其中崩溃为负数（本质上还是来自于内核Signal），正数为执行失败，超时为Cuda-Gen自身设定的某个数值。本文只对崩溃和超时样例进行手工debug以确定漏洞。而执行失败，即cudaErrorInvalidValue等回显，通常由于畸形的变异数据导致，这很正常，程序还是正常退出，本文的目的是通过变异出的畸形数据触发意料之外的崩溃和超时。因此这种执行失败被视为一次正常安全的执行。

4 实验

本节将对Cuda-Gen进行评估，以展示其在CUDA 库模糊测试中的有效性。我们将围绕以下3个问题展开研究。1） 问题1：Cuda-Gen与基线方法相比表现如何；2） 问题2：不同的关键组件在模糊测试过程中分别起到了怎样的作用；3） 问题3：在案例研究中实际发现了哪些漏洞。

4.1 实验设置

Cuda-Gen从零实现，整体流程大约使用3 500行 Python代码，并额外用500行C代码来完成字节级变异。就我们所知，目前没有任何开源模糊测试工具是专门针对CUDA库定制的。现有面向CUDA生态的公开工具中，CudaSmith^［6］仅能合成自定义内核，不涉及任何CUDA库调用，因此其API覆盖率极低，不适合作为基线工具。相比之下，Fuzz4All^［8］借助大语言模型（LLMs）生成多样化的代码片段，并且能够产出CUDA程序，因此在API覆盖潜力上与我们的方法相当。基于这一点，我们选择Fuzz4All作为基线工具。由于原始的Fuzz4All版本并不原生支持CUDA代码生成，我们对其进行了扩展，使其具备CUDA相关功能。所需的修改量非常小，仅涉及为每个CUDA库提供相应的文档说明。

在基准测试选择方面，本次评估针对6个生产级 CUDA库：CUDA Runtime^［47］（以下简称cuRT）、cuBLAS^［48］、cuFFT^［49］、cuRAND^［50］、cuSPARSE^［51］和nvJPEG^［52］。各库的详细特性汇总于表1中。所有实验均在两台服务器上进行：一台为Intel Xeon E5-2680 v4 56核机器（2.40 GHz，128 GB 内存，NVIDIA GeForce RTX 4090），另一台为AMD Ryzen Threadripper PRO 5995WX （WEPYC）工作站，配备NVIDIA RTX A6000 GPU。我们使用了CUDA 12.4、12.7以及最新的13.0版本。

本文选择这6个CUDA库主要基于以下考虑：首先，它们涵盖了CUDA生态中最核心和最常使用的功能模块，包括运行时管理、线性代数运算、快速傅里叶变换、随机数生成、稀疏矩阵计算以及图像编解码，广泛应用于深度学习框架、高性能计算和图像处理等实际场景。其次，这些库的 API 类型多样，参数结构复杂，涉及多阶段调用、状态管理、结构体操作以及指针交互等多种形式，能够充分验证 Cuda-Gen 在处理不同上下文依赖与参数变异模式时的适应能力。此外，这些库的底层实现复杂、优化程度高，是潜在漏洞的高风险区域，具有较高的安全研究价值。最后，它们也是现有研究（如 Fuzz4all 等）常用的基准库，有助于与前人工作进行公平对比。因此，这6个库能够构成具有代表性的测试集合，全面反映Cuda-Gen在实际 CUDA生态中的表现。

本研究主要使用GPT-4o（business API 模式）作为大语言模型组件，原因在于其在代码生成质量、跨文档推理能力和鲁棒性方面表现稳定，是当前业界广泛采用的代表性模型。尽管如此，Cuda-Gen的设计并不依赖某个特定大模型。其核心流程——API语义提取、知识图谱构建、参数依赖分析与桩代码修复——均基于通用的自然语言理解与代码生成能力，因此可以替换为其他具备相似能力的模型，包括 Llama 系列、Qwen 系列、Claude系列等开源或闭源模型。实际部署时，开发者可根据部署需求、隐私约束或成本因素选择替代模型。需要说明的是，不同模型在代码质量、上下文理解能力和错误修复能力方面存在差异，因此替换模型可能影响测试生成效率或编译成功率。

为了定位每个触发缺陷的特征，我们使用了官方CUDA调试工具CUDA-GDB和Compute-Sanitizer来精确查找故障的大致位置。基于诊断结果，我们准备并提交了详细的bug报告给对应的库维护者。覆盖率以及其他所有量化指标均在5次独立运行中重复测试，并以算术平均值的形式进行报告。

表1总结了每个目标库的主要功能以及测试所用的版本。CUDA版本对Cuda-Gen的影响几乎可以忽略不计。因此，我们随机在12.4或12.7上进行测试，并确认所有生成的代码在13.0上也能正常运行。在表中，“APIs”表示由我们的LLM提取的知识图谱中存在的库函数数量，而“API edges”则统计两个API之间的有向边（可能是调用依赖关系或语义顺序）。尽管 CUDA官方文档列出了更多已定义的API，但其中相当一部分缺乏具体的使用示例。因此，表1仅反映了那些存在可演示用例的API，从而为后续实验中的API 覆盖能力比较提供了一个公平的基准。

4.2 Cuda-Gen 与基线方法比较

由于CUDA的闭源特性，无法使用代码覆盖率指标来评估模糊测试器的探索深度。因此，我们通过API覆盖率来评估测试驱动的丰富度，这一指标已在其他闭源场景（如GLeeFuzz^［11］）中被采用。评估结果同时报告了API覆盖率（如图5）和API级边覆盖率（如图6）。两个图中标注为“Documents”的虚线，分别表示由Cuda-Gen利用LLM构建的知识图谱中的API数量和API边总数。其中，边的统计既包括调用关系边，也包括表示语义顺序的边。

图5表明，Cuda-Gen在所有8个目标库的API覆盖率上始终优于Fuzz4All，平均实现了Fuzz4ALL的2.97倍覆盖率。这种优势源于Cuda-Gen的API覆盖率位图，它能够主动引导模糊测试循环朝向尚未探索的API。相比之下，Fuzz4ALL缺乏任何引导机制，仅依赖LLM的随机生成。即使温度参数设置为1（最大随机性，官方发布版本的默认值），由于缺乏显式的引导，模型仍会偏向于更常用的API（这些API在训练语料中占比更大）。

同样可以明显看出，无论是Cuda-Gen还是 Fuzz4ALL，其覆盖率都不会超过知识图谱中可用API 的总数（图中标记为“Documents”），这一现象在 nvJPEG中尤为显著。原因在于某些API需要复杂的上下文支持，即使是LLM也无法可靠地满足这些条件，从而导致相应测试驱动的编译失败。例如，“cudaExternalMemoryGetMappedBuffer”的设计目的是将外部内存（如来自OpenGL的内存）映射到 CUDA中，而在合成测试驱动时，LLM通常会为外部资源提供一个空指针，而不是定义一个复杂的外部内存结构，这就不可避免地导致编译失败。尽管仍有少量API难以覆盖，但Cuda-Gen的覆盖率渐近逼近“Documents”中的数量。

图6显示，Cuda-Gen在API边覆盖率上显著优于Fuzz4ALL，平均达到Fuzz4ALL的4倍。此外，除nvJPEG外，Cuda-Gen的覆盖率还超过了“Documents”基线。这进一步验证了API覆盖率位图在引导探索方面的有效性。同时，与图5中较低的API级别覆盖率相比，Cuda-Gen和Fuzz4ALL在API边数上的结果更接近甚至超过了“Documents”的总数。这表明，虽然LLM在合成某些难以调用的API的测试驱动时存在困难，但它在将多个API组合成合法调用序列方面表现出了较强的可扩展性。

4.3 不同的关键组件在模糊测试过程中的作用

评估通过消融实验来考察Cuda-Gen两项关键创新的单独贡献：1） 基于知识图谱引导的测试驱动生成；2） 以及基于 LLM 的参数解耦与独立变异。

4.3.1 基于知识图谱引导的测试驱动生成的有效性

实验通过比较启用与禁用该组件的Cuda-Gen，评估知识图谱引导对覆盖率和编译成功率的影响。在表2中，“no-KG”表示禁用API覆盖位图并且不使用知识图谱进行测试驱动修复的Cuda-Gen。其中，括号中的所有数字表示“无知识图谱（no-KG）”相比于Cuda-Gen的百分比下降值； 最后一行的“平均下降率（Average Decrease）”表示该列中所有百分比数值的平均值。在6个目标库中，禁用引导会导致API覆盖率平均下降39.2%，API边覆盖率平均下降45.6%。编译成功率也显著下降，平均降低36.2%。当使用知识图谱进行修复时，除了nvJPEG之外，所有库的编译成功率都能超过60%。这是因为nvJPEG具有更严格的上下文依赖性，导致大部分测试驱动无法成功编译。

没有知识图谱时，LLM的生成过程会显著偏向随机性，从而阻碍覆盖率的提升.虽然跳过测试驱动修复可以节省大量时间，并将所有LLM的API调用都用于测试驱动生成，但生成的测试驱动却表现出低编译成功率和高度同质化的问题.因此，该消融实验表明：在测试驱动生成过程中引入API知识图谱作为引导是有效的.尤其是在像CUDA这样相对小众的领域中，补充性的知识能够提供决定性的指导作用.

此外，对于是否使用LLM进行3轮的测试驱动修复进行了有效性消融实验.实验结果如表3所示，“no-Fix”代表使用API覆盖位图指导但不使用LLM对编译失败的驱动进行修复.其中，表中数值为编译通过率，单位为百分比（%）.括号中的所有数字表示“无修复（no-Fix）”相比于Cuda-Gen的百分比下降值率.从表中数据看出，在6各目标上，不使用多轮修复对驱动进行迭代，编译通过率有着明显的下降，平均下降率达到了26.5%.其中nvJPEG目标上下降较不明显，这是因为nvJPEG中驱动生成难度大，而且本身覆盖到的API数量就不多.在此目标上，即使是最先进的大模型也难以将通过率明显提升.这也说明，大模型虽然对测试驱动生成很有帮助，但也无法解决所有报错问题.

4.3.2 参数隔离变异的有效性

为验证参数隔离变异的有效性，我们从基准测试中选择了10个自动生成的测试驱动，每个测试驱动都调用了至少5个不同的API，并在其中注入一个缺陷，该缺陷仅在某个特定参数落入狭窄范围时才会被触发。每个库中选择两个复杂测试驱动，nvJPEG除外，因为它们的单一图像输入不适合评估参数隔离变异。每个测试驱动都分别接受参数隔离变异和整体参数变异的处理，并测量暴露注入缺陷所需的时间。测试驱动最初由Cuda-Gen生成，并经过人工适配以支持整体变异。该实验设计借鉴了 Magma^［53］定向模糊测试基准，由于缺乏可利用分布的真实漏洞，它依赖于人工插入的触发条件。在我们的评估中，也没有找到足够数量的不同真实漏洞（大多数观测到的失败源于错误的API使用），因此我们采用了相同的受控缺陷注入方法。接受变异的参数分为两类：1） 标量数值类型（如 int、float、double、long）；2） 数组类型（如向量、矩阵）。

对于标量值，默认的触发条件是参数落入区间［64，128］。对于数组，则要求其第4个元素落入区间［512，1024］。之所以为标量选择一个狭窄区间，是因为它们直接影响设备内存分配，取值通过对2048取模来生成。数组本身没有固定界限，因此采用更宽的触发区间［512，1024］。表4报告了在这两类条件下，每个测试驱动在 参数隔离变异与整体参数变异两种策略下的触发时间。

在表4中，API数目表示由测试驱动（harness）调用的CUDA API数量；参数类型表示被变异的参数数量和类型，其中s代表标量（scalar），a代表数组（array）（例如1s+1a表示一个标量和一个数组）；Condition表示触发条件，定义了所需的单个标量值或指定数组元素的取值；TTi 表示参数隔离变异触发默认条件所需的时间，而TTe表示参数整体变异对应的触发时间。

表4中显示，对于标量和数组触发条件，参数隔离变异始终优于整体参数变异。平均而言，隔离变异触发默认条件的速度比整体变异快10.5倍。对于标量条件，隔离变异可以在几秒内触发，而整体变异通常需要几十秒甚至上百秒。这种差异的原因在于：隔离变异每次迭代都会针对标量进行变异，而整体变异则将标量与数组拼接在一起，因此只有一小部分变异会影响标量，从而延长了发现时间。对于数组触发条件，两种策略的延迟都显著增加。原因是它们都没有对数组进行逐字节变异，而是只对选定字节进行采样和变异，使得难以改变满足触发条件的特定元素。此外，整体变异在标量和数组触发条件之间表现出明显差距，其原因有两个：1） 标量通常为4字节；2） 而数组元素通常为8字节。基于AFL风格的havoc变异偏向于变异缓冲区的开头和结尾字节。由于整体变异将标量放在前面，其字节被选中的频率更高，从而加快了标量触发的发现速度，而数组触发则相对较慢。

实验验证了参数隔离变异在具有多个参数的 CUDA 函数中的可行性，并突出了其在变异标量值时的显著优势。

4.3.3 测试驱动调度的有效性

为了验证本文使用的测试驱动调度机制的有效性，我们对表6涉及到的真实漏洞，使用不加调度的方式在cuRT、nvJPEG进行了测试。具体的操作是将测试驱动优先级调度的方式更换成随机执行的方式，即每次生成新的驱动后随机选5个执行过的驱动进行重复执行，重复执行5次观察这3个真实漏洞触发的时间，结果如表5所示。其中，TT 表示首次发现该漏洞所花费的时间。TTr代表随机调度触发的平均时间。由表5可以看出，1号漏洞上随机调度的触发时间有着明显的增加，而在2号和3号漏洞上并不明显。这是因为cuRT库上API数量众多生成的测试驱动数量也多，随机采样，测试驱动被执行的次数平均，某些触发漏洞的关键的驱动分配的算力相较本文的调度方案更少。而2号和3号漏洞行时间增加的不明显，这是由于nvJPEG上测试驱动构造困难，总体的测试驱动数量少，二者差别不明显。因此，本文的调度方案相比随机调度，具有一定优势，尤其在测试驱动多的情况下更能捕获到重要驱动。

4.4 在案例研究中实际发现的漏洞

在评估过程中，Cuda-Gen发现并报告了数个此前未知的漏洞，随后被开发者确认。这些漏洞在表6中进行了总结。其中，TT表示首次发现该漏洞所花费的时间。需要注意的是，对于两个nvJPEG漏洞，提交了多个PoC。虽然不同的PoC都能触发该漏洞，但开发者仅为每个根本原因漏洞分配一个ID。因此，实际上独立触发的漏洞数量超过了3个。评估期间，CUDA从12.x版本升级到了13.0版本。因此，漏洞都已经被修复，不再触发超时或崩溃。以下简要的PoC分析展示了Cuda-Gen在发现这些问题上的有效性。在这3个案例中，触发条件仅以伪代码形式表达其逻辑意图；数值并非真实阈值，具体入口函数也已被模糊化处理。

值得注意的是，Fuzz4All和CudaSmith都未发现这3个漏洞。CudaSmith仅生成自定义内核，从未调用存在缺陷的入口点；而Fuzz4ALL虽然能够生成相关的测试驱动，但缺乏高效的变异策略，因此无法满足触发缺陷所需的严格条件。

如图7a，案例1是一个内存分配漏洞。Cuda-Gen发现该漏洞仅在GPU内存大小参数落入一小段负值区间时才会被触发。在正常情况下，请求负大小会立即触发警告或错误并正常终止。然而，受影响的CUDA进程却进入了无限停滞。该缺陷是通过 Cuda-Gen的参数隔离变异暴露出来的，该方法精确地将一个标量参数引导到关键范围内。这也验证了第3.2 节中描述的变异策略的有效性：它能够在测试驱动中的众多变量中成功识别出值得变异的参数，并将其驱动到触发漏洞的特定边界情况。

图7b案例2展示了一个由畸形图像元数据触发的nvJPEG进程崩溃。Cuda-Gen首先读取一个合法的JPEG文件，然后在保留开头用于编码JPEG结构的字节的同时，进行字节级别的变异。完成必要的nvJPEG句柄构建、图像解析以及逐通道RGB处理后，测试驱动调用了某个特定的nvJPEG函数，结果发生崩溃。CUDA-GDB显示故障源于libnvjpeg.so。该示例表明Cuda-Gen能够正确构造复杂的测试驱动。此外，Cuda-Gen还能有效地对一块连续内存区域进行变异，从而实现触发条件。该结果进一步证明了第2.1节所述API知识图谱引导机制的有效性：即使面对复杂的API调用模式，Cuda-Gen也能成功合成可编译并可执行的测试驱动。

5 结论

本文发现并报告了若干此前未知的漏洞，其中一些仅在极其复杂的条件下才会被触发，从而展示了Cuda-Gen揭示复杂漏洞的能力。然而，目前该框架仍缺乏指令级覆盖率反馈，这方面仍有很大提升空间。NVBit^［36］是NVIDIA官方提供的动态插桩框架，用于捕获用户自定义内核的运行时行为，其方式是直接在内核代码中插入钩子。然而，它并不支持在预编译库函数内部进行插桩。虽然CUDA的架构排除了常规静态或动态插桩的可能性，但官方提供的 CUDA-GDB调试器可以进入GPU内核并获取底层执行轨迹。因此，将CUDA-GDB集成到工具链中，预计能够进一步增强Cuda-Gen的漏洞发现能力。

本文提出了Cuda-Gen，这是专门针对CUDA库函数的端到端模糊测试框架。针对这些库的闭源特性及其特殊语法构造所带来的双重挑战，Cuda-Gen采用了 API覆盖位图指导测试驱动合成，利用LLM识别可变参数及其相互依赖关系，并应用参数隔离变异策略。该方法有效克服了CUDA测试中固有的测试驱动生成与执行难题，使得对广泛库代码的分析成为可能。实验结果表明，Cuda-Gen在API覆盖率上显著优于现有工具，并已发现3个此前未知的漏洞。

参考文献

[1] Raffel C， Shazeer N， Roberts A，et al.Exploring the limits of transfer learning with a unified text-to-text transformer［J］.J Mach Learn Res， 2020， 21（140）： 1-67.

[2] Lozhkov A， Li R， Allal L B， et al.StarCoder 2 and the stack v2： The next generation［EB/OL］.［2025-08-24］.

[3] Sun P， Kretzschmar H， Dotiwalla X，et al.Scalability in perception for autonomous driving： Waymo open dataset［C］//2020 IEEE/CVF Conference on Computer Vision and Pattern Recognition （CVPR）.Seattle：IEEE，2020： 2443-2451.

[4] Kaplan J， McCandlish S， Henighan T， et al.Scaling laws for neural language models［EB/OL］.［2025-08-24］.

[5] NVIDIA Developer.CUDA Toolkit［EB/OL］.［2025-09-30］.

[6] Jiang B， Wang X， Chan W K，et al.CUDAsmith： A fuzzer for CUDA compilers［C］//2020 IEEE 44th Annual Computers，Software，and Applications Conference （COMPSAC）.Madrid，Spain：IEEE，2020： 861-871.

[7] Yang X， Chen Y， Eide E，et al.Finding and understanding bugs in C compilers［J］.SIGPLAN Not，2011， 46（6）： 283-294.

[8] Xia C S， Paltenghi M， Tian J L，et al.Fuzz4ALL： Universal fuzzing with large language models［C］//2024 IEEE/ACM 46th International Conference on Software Engineering （ICSE）.Lisbon，Portugal：IEEE，2024： 1547-1559.

[9] Jung J， Jang J， Jo Y，et al.Moneta： Ex-vivo GPU driver fuzzing by recalling in-vivo execution states ［C］//Proceedings 2025 Network and Distributed System Security Symposium.San Diego： Internet Society， 2025.

[10] Chong N， Donaldson A F， Lidbury C， et al.Many-Core compiler fuzzing［J］.ACM Sigplan Notices， 2015， 50（6）： 65-76.

[11] Peng H， Yao Z， Sani A A，et al.｛GLeeFuzz｝： Fuzzing ｛WebGL｝ through error message guided mutation［C］//32nd USENIX Security Symposium （USENIX Security 23）.Berkeley，CA，USA： USENIX Association， 2023： 1883-1899.

[12] Zalewski M.American fuzzy lop，v2.52b［EB/OL］.［2025-09-30］.

[13] Fioraldi A， Maier D， Eißfeldt H， et al.｛AFL++｝： Combining incremental steps of fuzzing research ［C］//14th USENIX workshop on offensive technologies （WOOT 20）.Berkeley， USA： USENIX Association，2020.

[14] Bellard F.QEMU，a fast and portable dynamic translator［C］//USENIX Annual Technical Conference.FREENIX Track.Berkeley， USA： USENIX Association，2005： 10-55.

[15] LLVM Project.LibFuzzer documentation［EB/OL］.［2025-09-30］.

[16] Lyu C， Ji S， Zhang C，et al.｛MOPT｝： Optimized mutation scheduling for fuzzers［C］//28th USENIX Security Symposium （USENIX Security 19）.Berkeley， USA： USENIX Association，2019： 1949-1966.

[17] Wu M， Jiang L， Xiang J，et al.One fuzzing strategy to rule them all［C］//Proceedings of the 44th International Conference on Software Engineering.Pittsburgh Pennsylvania： ACM，2022： 1634-1645.

[18] Odena A， Goodfellow I.TensorFuzz： Debugging neural networks with coverage-guided fuzzing［EB/OL］.［2025-08-24］.

[19] Yang C， Deng Y， Lu R，et al.WhiteFox：White-box compiler fuzzing empowered by large language models ［J］.Proc ACM Program Lang， 2024， 8： 709-735.

[20] Green H， Avgerinos T.GraphFuzz： Library API fuzzing with lifetime-aware dataflow graphs［C］//Proceedings of the 2022 IEEE/ACM 44th International Conference on Software Engineering （ICSE）.Pittsburgh： IEEE， 2022： 1070-1081.

[21] Deng Y， Xia C S， Peng H，et al.Large language models are zero-shot fuzzers： Fuzzing deep-learning libraries via large language models［C］//Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis.Seattle：ACM， 2023： 423-435.

[22] Chen P， Xie Y， Lyu Y，et al.Hopper： Interpretative fuzzing for libraries［C］//Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security.Copenhagen Denmark： ACM，2023： 1600-1614.

[23] Hua Z， Lin W， Ren L，et al.GDsmith： Detecting bugs in cypher graph database engines［C］//Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis.Seattle：ACM， 2023： 163-174.

[24] Li J， Zhou Y， Wu L.Improving multitasking DBMS fuzzing with more accurate coverage and testcase trimming［J］.IEEE Trans Dependable Secure Comput， 2025， 22（3）： 2756-2770.

[25] Yang Y， Chen Y， Zhong R， et al.Towards generic database management system fuzzing［C］//33rd USENIX Security Symposium （USENIX Security 24）.Berkeley， USA： USENIX Association，2024： 901-918.

[26] Zhong R， Chen Y， Hu H，et al.SQUIRREL： Testing database management systems with language validity and coverage feedback［C］//Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security.Virtual Event：ACM，2020： 955-970.

[27] Sorensen T， Donaldson A F.Exposing errors related to weak memory in GPU applications［J］.SIGPLAN Not，2016，51（6）： 100-113.

[28] Alglave J， Batty M， Donaldson A F，et al.GPU concurrency： Weak behaviours and programming assumptions ［J］.SIGARCH Comput Archit News，2015，43（1）： 577-591.

[29] Google.Syzkaller-kernel fuzzer［EB/OL］.［2025-09-30］.

[30] Gu J， Luo X， Zhou Y，et al.Muffin： Testing deep learning libraries via neural architecture fuzzing［C］//2022 IEEE/ACM 44th International Conference on Software Engineering （ICSE）.Pittsburgh：IEEE，2022： 1418-1430.

[31] Xie X， Ma L， Juefei-Xu F，et al.DeepHunter： A coverage-guided fuzz testing framework for deep neural networks［C］//Proceedings of the 28th ACM SIGSOFT International Symposium on Software Testing and Analysis.Beijing， China：ACM，2019： 146-157.

[32] Yang C， Deng Y， Yao J，et al.Fuzzing automatic differentiation in deep-learning libraries［C］//2023 IEEE/ACM 45th International Conference on Software Engineering （ICSE）.Melbourne，Australia：IEEE，2023： 1174-1186.

[33] Jeong B， Jang J， Yi H， et al.UTopia： Automatic generation of fuzz driver using unit tests［C］//2023 IEEE Symposium on Security and Privacy （SP）.San Francisco：IEEE，2023： 2676-2692.

[34] Li W， Yang H， Luo X，et al.PyRTFuzz： Detecting bugs in Python runtimes via two-level collaborative fuzzing［C］//Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security.Copenhagen Denmark： ACM，2023： 1645-1659.

[35] Lyu Y， Xie Y， Chen P，et al.Prompt fuzzing for fuzz driver generation［C］//Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security.Salt Lake City：ACM，2024： 3793-3807.

[36] Google.OSS-Fuzz［EB/OL］.［2025-09-30］.

[37] Xu H， Ma W， Zhou T，et al.CKGFuzzer： LLM-based fuzz driver generation enhanced by code knowledge graph［C］//2025 IEEE/ACM 47th International Conference on Software Engineering： Companion Proceedings （ICSE-Companion）.Ottawa， Canada： IEEE， 2025： 243-254.

[38] Zhang Y H.Research on Large Language Model-guided fuzzing technology for DBMS［D］.Guangzhou： Guangzhou University， 2025.

[39] 张宇恒.大语言模型指导的DBMS模糊测试技术研究［D］.广州：广州大学，2025.

[40] Peng S， Zhang Y， Dai J，et al.Applying fuzz driver generation to native C/C++ libraries of OEM Android framework： Obstacles and solutions［C］//Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering.Sacramento：ACM，2024： 2035-2040.

[41] Liu H， Hou T D， Zhao B，et al.Survey of fuzzing test case generation techniques［J］.Comput Eng Sci，2025，47（7）： 1244-1261.

[42] 刘慧，侯同定，赵博，等.模糊测试用例生成技术研究综述［J］.计算机工程与科学，2025，47（7）： 1244-1261.

[43] Ma X， Luo L， Zeng Q.From one thousand pages of specification to unveiling hidden bugs： Large language model assisted fuzzing of matter ｛IoT｝ devices ［C］//33rd USENIX Security Symposium （USENIX Security 24）.Berkeley，CA，USA： USENIX Association， 2024： 4783-4800.

[44] Liu R， Yang P， Jia P，et al.LCFuzzer： Large language model assisted fuzzing approach forsmart contract vulnerability detection［J］.J Sichuan Univ Nat Sci Ed，2025，62（3）： 641-650.

[45] 柳蓉， 杨频， 贾鹏， 等.LCFuzzer： 基于大语言模型辅助的智能合约模糊测试方法［J］.四川大学学报（自然科学版）， 2025， 62（3）： 641-650.

[46] Li Y， Yang W Z， Zhang Y，et al.Survey on fuzzing based on large language model［J］.J Softw，2025，36（6）： 2404-2431.

[47] 李岩， 杨文章， 张翼， 等.基于大语言模型的模糊测试研究综述［J］.软件学报，2025， 36（6）： 2404-2431.

[48] Xie M F， Fu J M， Yao R Y.Research on LLM-based fuzzing of native multimedia libraries［J］.Netinfo Secur，2025，25（3）： 403-414.

[49] 解梦飞， 傅建明， 姚人懿.基于LLM的多媒体原生库模糊测试研究［J］.信息网络安全， 2025， 25（3）： 403-414.

[50] Jiang Y， Liang J， Ma F，et al.When fuzzing meets LLMs： Challenges and opportunities［C］//Companion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering.Porto de Galinhas Brazil：ACM，2024： 492-496.

[51] NVIDIA.Cuda-samples［EB/OL］.［2025-09-30］.

[52] NVIDIA Developer.CUDA runtime API［EB/OL］.［2025-09-30］.

[53] NVIDIA Developer.cuBLAS［EB/OL］.［2025-09-30］.

[54] NVIDIA Developer.NVIDIA cuFFT［EB/OL］.［2025-09-30］.

[55] NVIDIA Developer.cuRAND［EB/OL］.［2025-09-30］.

[56] NVIDIA Developer.cuSPARSE［EB/OL］.［2025-09-30］.

[57] NVIDIA Developer.nvJPEG［EB/OL］.［2025-9-30］.

[58] Hazimeh A， Herrera A， Payer M.Magma：A ground-truth fuzzing benchmark［C］//Abstract Proceedings of the 2021 ACM SIGMETRICS /International Conference on Measurement and Modeling of Computer Systems.Virtual Event China： ACM，2021： 81-82.

[59] Villa O， Stephenson M， Nellans D，et al.NVBit： A dynamic binary instrumentation framework for NVIDIA GPUs［C］//Proceedings of the 52nd Annual IEEE/ACM International Symposium on Microarchitecture.Columbus：ACM，2019： 372-383.

基金资助

军委科技委预先研究项目(CA131B0502T-065)