原论文可见：SyzDirect: Directed Greybox Fuzzing for Linux Kernel。

摘要

对于操作系统内核而言，Bug报告和补丁提交数量急剧增加，这使得内核级别的Bug重现和补丁测试变得极为迫切。定向灰盒模糊测试（DGF）旨在对特定代码部分进行压力测试，是一种颇有前景的Bug重现和补丁测试方法。然而，现有的DGF方法仅针对用户空间应用程序进行，在处理操作系统内核时存在固有局限性，这些方法无法准确确定合适的系统调用以及到达目标位置所需的系统调用参数值，导致效率低下和资源浪费。

本论文提出了SyzDirect，一种针对Linux内核的动态生成式模糊测试（DGF）解决方案。通过对Linux内核进行新颖且可扩展的静态分析，SyzDirect能够识别有价值的信息，例如正确的系统调用及其参数条件，以到达目标位置。在模糊测试过程中，SyzDirect利用静态分析结果来指导测试用例的生成和变异，随后借助基于距离的反馈进行种子优先级排序和功耗调度。我们在上游Linux内核上对SyzDirect进行了漏洞重现和补丁测试评估。结果表明，与通用内核模糊测试工具相比，SyzDirect能够多重现320%的漏洞，多覆盖25.6%的目标补丁。它还分别将漏洞重现和补丁覆盖的速度提高了154.3倍和680.9倍。

CCS CONCEPTS

  • 安全与隐私 软件与应用程序安全；操作系统安全。

关键词

定向灰盒模糊测试；内核模糊测试；操作系统安全；静态分析。

1 引言

内核是最重要的软件组件，它支撑着整个操作系统（OS）和所有用户应用程序。因此，操作系统内核的安全性至关重要，并且近年来受到了广泛关注。大量的静态分析技术[8][13][16][27][29][30][41][46]和模糊测试工具[4][18][24][38][40][42]不断涌现，并在例如Linux内核中发现了大量安全漏洞。这给内核开发者带来了巨大压力，他们需要分析这些漏洞并开发高质量的补丁。在这种情况下，定向灰盒模糊测试（DGF）——旨在将模糊测试重点放在特定代码位置[10][14][15][22][26][47]——是一种很有前景的辅助技术。❶如果漏洞报告没有附带概念验证（PoC）输入，DGF可以自动重现漏洞。❷DGF可以对开发的补丁进行压力测试，以评估其质量，减少人工审查工作量。然而，现有的DGF技术主要集中在用户空间应用程序[10][14][15][22][26][47]，无法轻易适用于操作系统内核。目前针对操作系统内核的最先进的DGF技术是GREBE [28]。然而，GREBE是一种针对特定任务（即探索内核漏洞的更多错误行为）量身定制的方法，而不是一种通用的定向模糊测试解决方案。它需要PoC程序作为输入，而这在典型的DGF场景中并不具备。

一般来说，现有的动态指导模糊测试（DGF）技术采用两种主要策略来快速逼近目标位置：距离引导探索[10][14][15][26]和无效输入修剪[22][47]。第一种策略收集运行时反馈，以计算到达目标位置的距离，并优先处理距离较短的测试用例。第二种策略过滤掉无法到达目标位置或遵循不可行执行路径的测试用例，进一步推动探索。

虽然上述通用策略可应用于操作系统内核，但要实现有效的内核级动态污点生成（DGF），仍面临一系列现有工具未考虑或未克服的障碍。（1）与采用固定入口点的用户空间应用程序不同，操作系统内核实现了数百个系统调用（简称为syscalls），作为与内核交互的主要接口。例如，Linux内核有大约330个原始系统调用，而当前最先进的内核模糊测试工具Syzkaller[18]定义了近4200个系统调用变体用于模糊测试。因此，确定正确的入口系统调用及其变体以到达目标位置，对于内核级DGF至关重要，这样可以避免浪费时间探索不可行的系统调用。然而，由于在 Linux 内核中大量使用间接调用，应用现有的控制流分析技术来识别入口系统调用会引入大量误报。此外，目前还没有研究考虑如何将内核代码与系统调用变体进行匹配。（2）除了系统调用之外，准备所需的系统调用参数以满足目标执行路径上的约束条件也很重要。否则，DGF很容易在探索参数空间时陷入困境。然而，由于内核的复杂性，现有的通用静态分析方法（如Beacon[22]采用的前置条件分析）不太可能很好地发挥作用。一方面，跟踪系统调用的执行需要分析深层代码。另一方面，内核代码涉及大量间接调用、链表操作、嵌套数据结构以及多层指针解引用，这使得对深层代码进行准确的数据流分析具有挑战性。

为应对上述挑战，本文提出了SyzDirect，这是首个针对Linux内核的通用有向灰盒模糊测试解决方案。SyzDirect将目标内核版本中的目标代码位置作为输入，旨在对目标代码进行压力测试。SyzDirect利用了新颖的静态分析，该分析利用了Linux内核和Syzlang [19] 的设计，以识别到达目标位置的重要信息。首先，SyzDirect确定作为进入目标位置入口点的系统调用变体。为实现这一点，SyzDirect通过对内核函数执行的操作及其所操作的资源进行建模，将内核函数与系统调用变体进行匹配，这对传统静态分析来说颇具挑战性。其次，SyzDirect推断依赖于入口系统调用的系统调用变体，这些入口系统调用为触发目标设置了重要上下文（例如，生成合适的资源）。第三，SyzDirect利用一种轻量级方法来确定到达目标的系统调用参数条件，并完善入口系统调用的参数描述。该方法利用Syzlang描述的丰富信息，避免了重量级的数据流分析。然后，SyzDirect将这些信息组装成模板，以指导有向模糊测试。具体而言，SyzDirect采用了一种定制的变异算法，该算法倾向于按照模板生成测试用例，并利用基于距离的反馈进行种子优先级排序和功率调度。

本文基于Syzkaller[18]和LLVM[25]实现了SyzDirect的一个原型。本文在DGF的两种典型应用场景（补丁测试和漏洞复现）中，将SyzDirect与Syzkaller和SyzGo（针对Linux内核的AFLGo[10]的一个变体）进行了评估比较。此外，本文将GREBE[28]作为一种通用的DGF方法进行了适配，并将其漏洞复现能力与SyzDirect进行了比较。结果表明，SyzDirect在效率和效果方面均优于Syzkaller、SyzGo和GREBE。在漏洞复现方面，SyzDirect比Syzkaller、SyzGo和GREBE分别多复现320%、281%和121%的漏洞。对于Syzkaller和SyzGo能够复现的漏洞，SyzDirect的复现速度比Syzkaller快154.3倍，比SyzGo快81.9倍。在补丁测试方面，SyzDirect比Syzkaller和SyzGo分别多覆盖25.6%和36.1%的目标。最重要的是，SyzDirect发现了4个其他模糊测试工具无法发现的已知不安全补丁。此外，实验还单独评估了SyzDirect的每个关键组件对内核级DGF的益处。

总之，本文做出了以下贡献：

  • 本文提出了一种静态分析方法，用于识别内核级动态生成式模糊测试（DGF）的重要信息，包括正确的入口系统调用以及达到目标时参数的条件。
  • 本文介绍了SyzDirect的设计与实现，这是一个针对Linux内核的定向灰盒模糊测试框架，它利用所识别的信息来指导模糊测试。
  • 我们对SyzDirect与通用内核模糊测试器以及现有的DGF技术进行了全面评估。结果表明，SyzDirect在效率和效果上都显著优于它们。

在Apache2.0许可下将SyzDirect开源，地址为https://github.com/seclab-fudan/SyzDirect 。该工具包含SyzDirect的原型以及一个经过修改的Clang编译器，用于定制化插桩。

2 背景与动机

2.1 定向灰盒模糊测试

距离引导探索。定向灰盒模糊测试（DGF）旨在对程序中的目标位置进行密集测试。与通用灰盒模糊测试相比，DGF优先向目标位置进行探索，因此能够更快地接近目标位置。现有的DGF方法[10][14][26]通常利用某种距离来指导模糊测试过程。它们首先测量每个输入到目标位置的距离，然后将更多精力分配给变异更接近目标位置的输入。在设计距离度量时，AFLGo[10]和Hawkeye[14]考虑了控制流信息，而CAFL[26]进一步纳入了数据流信息。

通过输入剪枝进行优化。基于距离的引导很有帮助，但无法准确确定哪些输入能够命中目标位置。因此，它仍然会在无法到达目标的测试用例上花费时间，从而导致资源浪费[22][47]。为了解决这个问题，近期研究[22][47]提出通过剪枝无法到达目标的输入来进一步优化DGF。具体而言，FuzzGuard[47]开发了一种基于深度学习的方法来预测输入的可达性，并在将其发送到模糊测试之前过滤掉不可达的输入。相比之下，Beacon[22]采用静态分析来计算到达目标的前置条件，并不满足前置条件时提前在执行路径终止输入。

2.2 操作系统内核的DGF

现有的动态生成测试用例（DGF）技术主要集中在用户空间应用程序上。然而，操作系统内核也是一类重要的目标，在这方面对DGF的需求极为迫切。以Linux内核为例。Bugzilla[5]收到大量没有漏洞证明（PoC）的错误报告，这使得重现和分析工作变得极其困难。DGF可以帮助生成缺失的PoC，从而减轻事后分析的负担。此外，错误的补丁经常被提交到Linux内核中[1][2][43]，而这些问题也可以通过DGF识别并避免。

虽然动态图融合（DGF）的一般概念可以应用于操作系统内核，但要实现有效的内核级动态图融合（DGF），还面临着一系列现有方法无法克服的障碍。

图1：Linux内核中一个有缺陷的示例补丁。

挑战一：入口点。与用户空间应用程序不同，操作系统内核有许多以系统调用表示的入口点（或系统调用）。一个目标位置通常只能从一小部分系统调用中到达。例如，Linux内核大约有330个系统调用，而图1中的错误补丁只能通过和到达。更糟糕的是，每个原生系统调用通常是许多独立变体的包装器，只有某些变体才能到达目标。例如，Syzkaller根据所使用的协议/子协议为定义了468个变体[6]。图1中的错误补丁只有在使用可靠数据报套接字（RDS）协议时才能到达。总体而言，根据Syzkaller的定义，Linux内核有近4200个系统调用变体。

内核级动态污点分析（DGF）的首要挑战是识别正确的系统调用及其变体。否则，我们将浪费大量时间去探寻正确的入口点。然而，现有的动态污点分析方法既未考虑这一挑战，也未提供解决方案。直觉上，我们可能认为可以通过控制流分析找到入口点。但事实并非如此。图1中的错误补丁只能通过的调用链到达，其中是通过间接调用触发的，且指向的指针是在另一个系统调用（socket）中设置的。解决这种间接调用的唯一可扩展方法是基于类型的指针分析，遗憾的是，这种方法会产生误报。例如，最先进的基于类型的指针分析[31]报告称，有235种不同的系统调用可以到达错误补丁。此外，即使给定了主系统调用，控制流分析也无法区分不同的变体，因为所有变体都共享相同的入口点（即主系统调用）。

挑战二：参数准备。找到正确的切入点会有所帮助，但对于内核级动态图形生成（DGF）而言仍不充分。为了到达目标位置，我们还必须为系统调用准备所需的参数。否则，动态生成式模糊测试（DGF）很容易在探索参数空间时陷入困境。

确定所需的参数需要理解对这些参数所施加的条件。像Beacon[22]采用的前置条件分析这类通用方法不太可能奏效。这些条件往往深藏于底层代码中。为了将这些条件与参数关联起来，前置条件分析必须准确地梳理从底层代码到系统调用入口的冗长、复杂的路径。以图1所示的示例为例。为了到达错误补丁处，第二个参数中深度嵌套的一个字段，必须在调用函数之前满足某个条件（图1第6行）。从系统调用入口到条件所处位置，该参数字段的传递涉及间接调用、链表操作、嵌套数据结构以及多层指针解引用，这使得准确的前置条件分析极具挑战性。

图2 SyzDirect概述。

3 方法概述

在本文中，我们提出了SyzDirect，这是一种针对Linux内核的通用动态污点生成（DGF）解决方案。SyzDirect以目标内核版本中的指定代码位置作为输入，并按照图2所示的工作流程对该位置进行压力测试。

入口点识别。我们不依赖通用的控制流分析，而是利用Linux内核的设计来识别入口点。本质上，Linux内核是一个资源管理器，这些资源被抽象为文件、套接字、设备等。系统调用是对资源进行操作（创建、更新、回收等）的接口，而内核函数则为这些操作提供实际的实现。这给我们带来了以下关键见解：我们可以根据内核函数在哪些资源上作以及它们如何对资源进行作，将内核函数与系统调用进行匹配。

以图1所示的情况为例。基于健全调用图中的信息（通过过近似指针分析构建以解析间接调用），目标函数只能通过内核函数到达，该函数是数据结构的成员函数。利用我们构建的用于描述Linux内核中资源创建和操作的模型（见§4.1），我们可以推断出由用于注册AF_RDS族中SOCK_SEQPACKET类型的套接字。通过这种方式，我们了解到操作的是AF_RDS SOCK_SEQPACKET套接字。进一步参考Syzkaller的描述（即Syzlang）[6]，我们可以看到只有来自家族 (，，等等）的系统调用变量，为相同的资源提供接口，使我们能够将目标函数与这些系统调用变体进行匹配。最后，将匹配结果应用于精简健全调用图，我们可以确定目标函数只能通过到达。

系统调用依赖推断。内核级动态污点生成（DGF）通常需要一系列相关的系统调用才能到达目标。例如，要到达图1中的错误补丁，就必须在同一套接字上顺序执行和。

我们基于系统调用所操作的资源来推断它们之间的依赖关系，采用Healer[40]提出的静态学习方法。具体来说，如果系统调用可能使用系统调用创建的资源，我们就认为依赖于。在图1所示的示例中，为创造所需的套接字，这使得我们能够确定它们的依赖关系。剩下的问题是弄清楚哪些系统调用创建/使用哪些资源。这是一项简单的任务，因为Syzlang已经在系统调用变体层面提供了此类信息。

系统调用参数细化。弄清楚系统调用变体通常会自动对参数施加一些条件。在图1中，知道是所需的变体，这使我们能够将的第一个参数限制为AF_RDS SOCK_SEQPACKET套接字描述符。但这还不够，因为许多条件与变体无关（例如，图1第6行的条件检查消息类型，这不受系统调用变体的约束）。

为了识别与变体无关的参数条件，我们利用Syzlang中可用的信息。Syzlang根据资源（例如，套接字）或子资源（例如，特定协议的套接字）描述了系统调用参数的条件。例如，支持七种消息类型（RDS_CMSG_RDMA_ARGS、RDS_CMSG_RDMA_DEST、RDS_CMSG_RDMA_MAP等），并且Syzlang为每种类型指定了的参数（及其递归嵌套字段）的条件。在我们的方法中，我们识别所有主导目标位置或影响间接调用的条件，然后尝试将每个识别出的条件与Syzlang中包含的参数条件进行匹配。匹配基于轻量级方法，如基于文字/值的比较，一旦成功，我们就可以将代码条件转换为参数条件，而无需任何数据流或前置条件分析。 例如，图1第6行的条件涉及一个名为“RDS_CMSG_RDMA_ARGS”的联合值，它与Syzlang中“RDS_CMSG_RDMA_ARGS”消息类型的参数条件相匹配。因此，我们在DGF期间从Syzlang借用的相应参数条件。

定向内核模糊测试。我们对Syzkaller[18] 进行了改进，以执行定向模糊测试。❶我们上述的分析确定了到达目标位置所需的系统调用序列及其参数条件，并将其组装成模板来指导Syzkaller。具体而言，我们定制了种子变异过程，以较高概率按照模板生成测试用例。通过这种方式，我们减少了远离目标位置的测试。❷我们迫使Syzkaller优先对更接近目标位置的种子进行变异，并为这些种子分配更高的能量。这样做使我们能够更快地接近目标位置。❸我们扩展了该方案以保留测试用例。除了覆盖新代码路径的测试用例外，我们还保留那些与目标位置距离更短的测试用例，因为我们认为它们代表着更接近目标的一步。

总结。为了便于有向内核模糊测试，SyzDirect采用了两种新技术，即入口点识别（§4.1）和系统调用参数优化（§4.3）。通过利用Linux内核的独特设计并借助用Syzlang编写的系统调用描述，这两种技术克服了现有静态分析的局限性，即如§2.2中所述，识别用于触发目标位置的正确系统调用并准备所需的系统调用参数。此外，SyzDirect通过调整Healer[40]中的静态学习算法来推断系统调用依赖关系（§4.2）。据我们所知，借助所有这些静态分析技术，SyzDirect是首个能够自动识别深入内核代码中到达特定目标位置所需的系统调用变体（不仅是原始系统调用）和参数的解决方案。

此外，SyzDirect从两个方面对Syzkaller进行扩展以支持定向模糊测试。一方面，SyzDirect引入了定制的种子变异和生成策略（§4.5），与静态分析生成的模板协同工作。另一方面，SyzDirect通过调整和优化AFLGo[10]的算法，实现了距离计算（§4.4）和距离引导调度。结合模板辅助变异和距离引导，SyzDirect能够有效地逼近内核中给定的目标位置。

4 设计

4.1 入口点识别

我们的目标是识别可用作目标站点入口点的系统调用变体（我们将其称为入口系统调用）。为了克服2.2节中提到的入口点识别障碍，我们提出了一种新方法，该方法通过对内核函数操作的资源以及操作方式进行建模，将内核函数与系统调用变体进行匹配。我们的新方法源于对Linux内核的两点观察。❶每个系统调用变体都用Syzlang语言描述了对特定资源的特定操作，与粗粒度的原始系统调用相比，它对内核功能的表示更为精细。❷进入系统调用入口后，内核会执行函数调度，以确定需要执行哪个函数。调度该过程会解析系统调用参数，以确定正在处理哪些资源以及应执行何种操作，进而确定随后要执行哪个函数。基于这些观察结果，我们建议通过以统一的方式对所执行的操作和所操作的资源进行建模，将系统调用变体与内核函数进行匹配。借助匹配结果，SyzDirect可以在系统调用变体级别定位入口点，并减少因间接调用分析不准确而产生的误报。

锚点函数。考虑到并非所有内核函数都能明确反映它们所操作的资源以及执行的操作，我们无法以一种直接的方式对所有函数进行建模。由于函数分发过程自然涉及资源的处理和操作的确定，我们主要分析分发过程，以了解后续代码操作了哪些资源以及执行了哪些操作。我们将分发过程之后执行的首个函数称为锚点函数。我们首先对锚点函数进行建模，并将其与系统调用变体进行匹配。对于其他函数，我们确定可从哪些锚点函数到达该函数，并将其映射到与这些锚点函数对应的系统调用变体。

操作建模。一般来说，原始系统调用入口对应一组相关操作，内核会根据传入的命令参数值来确定要执行的具体操作。因此，我们采用系统调用名称以及命令参数值，分别对内核函数和Syzlang变体如何对资源进行操作进行建模。对于系统调用变体分析，我们直接从Syzlang描述中提取系统调用名称。然后解析其所有参数，并将其中的数值常量用作命令值。对于内核函数分析，我们结合控制流和数据流分析来提取命令值。具体来说，给定一个系统调用名称，我们从其代码入口进行正向分析，并从控制流图（CFG）中定位所有的switch语句。然后进行数据流分析，以确定switch语句的变量是否与系统调用参数相关。对于包含参数的switch语句，我们将每个case分支中的函数作为锚点函数，并将该case的常量值作为它们的命令值。

图3 操作建模示例

图3展示了一个操作建模的示例。系统调用变体将作为其命令值，以表明该变体执行更新密钥的操作。因此，我们将其操作建模为。从的代码来看，switch语句将系统调用的第一个参数作为条件，并引出几个case分支。因此，我们为每个case分支定位锚点函数，并从case语句中提取常量值，以对每个锚点函数的操作进行建模。例如，我们从第6行提取出，并将第8行的锚点函数建模为。

资源建模。由于同一资源在内核代码和Syzlang描述中的命名和定义可能不同，我们不能使用资源名称对它们进行建模。为了在Syzlang描述和内核代码之间构建一个资源模型，我们建议使用资源创建中的不变量对它们进行建模。具体来说，为了指定一种资源类型，创建一个资源需要相应的字符串或数字常量。例如，创建设备和文件系统资源需要一个表示文件系统/设备路径的常量字符串，而创建套接字则需要族和套接字类型。因此，我们使用与创建该资源相关的所有字符串和数字常量来对资源进行建模。

图4 系统调用变体的资源建模示例。

对于系统调用变体，我们可以通过解析其参数来获取它所需的资源。为了对获取的资源进行建模，我们首先定位创建该资源的系统调用变体，然后解析创建系统调用变体的参数，从中提取所有常量字符串和常量值。在图4所示的Syzlang描述中，在第2行中将名为的资源作为输入，而在第1行中由常数列表作为输入而产生。第6行同样如此，由一些字符串常量（例如）来构造。特别地，我们从字符串中删除路径前缀，只保留设备名称。

对于内核函数，我们通过分析间接调用的目标来确定所需的资源。我们观察到，在内核中，不同类型的资源通常会被分配一个独特的类似虚表的数据结构。进入系统调用入口后，内核通过间接调用执行函数调度。这种间接调用会查询与该资源对应的虚表，从而将控制流导向执行相应功能的代码。因此，我们将虚表中的所有函数视为锚函数，并且它们都属于该虚表所属的资源。然而，在资源的虚表与创建此资源时的不变量之间仍存在差距。

为了解决这一差距，我们研究了资源创建过程，并观察到内核中的大多数资源创建过程都遵循这样一种方式。❶在模块加载或内核初始化期间，内核会调用一些通用的注册函数，这些函数将关键信息（例如关于资源的常量信息和资源创建函数）作为参数。❷创建资源时，内核会调用相应的创建函数。❸资源创建函数会将其他常量和虚表分配给表示资源对象的内核结构。基于这些观察结果，我们开发了一种定制的静态分析方法，将虚表与资源的不变量（即常量字符串和数值）关联起来。我们的方法包括三个步骤。首先，我们手动收集一份常用注册函数列表，并定位它们所有的调用点。对于每个调用点，我们利用领域知识，根据变量名提取关键常量值和创建函数。其次，我们深入研究创建函数。我们分析所有的赋值语句，并根据变量名和变量类型确定与资源相关的常量赋值以及资源虚表的赋值。第三，对于注册函数的每个调用点，我们使用所有提取到的与资源相关的常量对与虚表对应的资源进行建模。我们的方法需要一些领域知识，例如注册函数以及与资源创建相关的关键变量和关键结构的名称。总体而言，我们手动收集了大约20个涉及套接字、设备和文件系统等通用资源的注册函数和关键变量，涵盖了大多数系统调用变体。

以图1中的激励案例为例。触发涉及一个间接调用，它将控制流导向。因此，我们将表示为一个锚函数，并检查了它的所有引用。结果发现，属于，它是RDS套接字的一个类似虚表的结构。接下来，我们分析资源创建，以确定对应哪些与资源相关的常量。RDS套接字的创建如图5所示。首先，RDS模块的初始化在第4行调用一个套接字注册函数。通过分析其参数及其递归嵌套的字段，我们得到了族类型和创建函数。然后，我们进一步追踪到，并在第22行得到的赋值。此外，我们可以在第16行找到对套接字类型的检查，并得知套接字类型的值为SOCK_SEQPACKET，这类似于一个赋值语句。因此，我们弄清楚了，锚函数需要一个AF_RDS SOCK_SEQPACKET资源。

基于锚点函数的匹配。给定一个内核函数作为目标，我们根据其在控制流中关联的锚点函数，将其与系统调用变体进行匹配。具体来说，我们从目标内核函数执行反向控制流分析并记录所有路径。对于每条路径，我们在路径上定位所有锚点函数，并将它们的模型合并为该路径的模型。然后，我们通过检查路径与系统调用变体是否共享相同的操作和资源模型，来将路径与系统调用变体进行匹配。最后，我们将所有路径的匹配系统调用合并，作为目标函数的匹配结果。请注意，如果反向控制由于不正确的间接调用分析导致控制流引入了一条错误路径，该路径将不会与任何系统调用变体匹配，因为开发人员不会为不存在的补丁编写Syzlang描述。因此，我们的匹配不会因控制流分析不准确而引入误报。

识别入口系统调用。给定目标代码位置，我们结合传统的控制流分析和我们的匹配方法来识别其入口系统调用。我们首先使用基于类型的间接调用分析[31]进行控制流分析，以构建控制流图（CFG）并识别可以到达目标的原始系统调用。然后，我们使用构建的CFG对内核函数进行建模，并将目标函数与系统调用变体进行匹配。最后，我们将可达的原始系统调用和匹配的系统调用变体的交集作为目标位置的入口系统调用，从而剔除不可行的分析结果。

4.2 系统调用依赖推断

除了作为入口点的入口系统调用外，触发目标位点还需要其他系统调用为入口系统调用提供资源或设置内核状态。我们将这些系统调用称为相关系统调用。一般来说，我们通过分析资源的创建和使用来推断入口系统调用所依赖的系统调用，从而确定相关系统调用。由于静态推断的结果并不完备，SyzDirect在模糊测试过程中，会平衡使用推断出的相关系统调用与探索其他系统调用（见§4.5）。

具体来说，我们采用Healer[40]提出的静态学习算法来识别与入口系统调用有明确关系的系统调用。该算法首先分析入口系统调用的输入参数，并提取参数的资源类型。然后，通过分析所有系统调用的返回值类型，识别出能够生成这些资源类型的系统调用作为相关系统调用。由于Syzlang支持资源类型之间的继承，我们在分析返回值类型时，也需要考虑继承关系。在某些情况下，目标系统调用所需的资源参数类型非常通用，导致上述步骤会识别出数百个相关的系统调用。因此，当识别出过多相关系统调用（例如超过10个）时，我们只保留与入口系统调用在同一模块中的相关系统调用。

4.3 系统调用参数优化

在确定入口系统调用后，我们进一步确定在系统调用参数上到达目标位置所需的与变体无关的条件，并细化入口系统调用的参数描述。由于在内核中对系统调用参数进行字段敏感的条件分析较为复杂，我们提出一种轻量级方法来识别参数上的条件，而非执行前置条件分析[9][12][33]或符号执行[11][36]。

我们的轻量级条件识别包括两个步骤。首先，给定一个目标位置及其一个入口系统调用，我们识别主导目标位置的两种条件。与现有的数据条件敏感模糊测试[7][17]类似，我们关注与常量（例如，幻数）比较的条件，并提取常量值以及常量的文字表述。此外，我们还考虑影响间接调用的资源条件。也就是说，一个系统调用变体可能将某些子资源（例如，要发送的控制消息）作为其参数，并且子资源的类型以与§2.2中描述的动机案例类似的方式确定间接调用的目标。为了对资源条件进行建模，我们分析子资源注册，并使用与其相关联的常量来表示一个子资源，就像我们在§4.1中对资源建模所做的那样。

在从内核代码中提取出参数的条件后，我们将每个提取出的条件与入口系统调用的Syzlang描述中包含的参数条件进行匹配。我们通过检查提取出的条件的字面量是否出现在任何参数（及其递归嵌套的字段）的定义中，以及内核代码中字面量的值是否与Syzlang描述中的值相同，来进行条件匹配。我们基于字面量/值的匹配利用了这样一个事实，即编写良好的Syzlang描述清晰地定义了系统调用参数（包括对象参数）以及参数定义中的常量，并且常量的命名参考了Linux头文件。一旦某个条件匹配成功，我们就会得到关于为触发目标位置，参数的哪个字段应设置为何种值/类型的约束。也就是说，对于受约束字段的其他值/类型对于DGF来说是无用的，应该从描述中剔除。因此，我们通过从描述中删除这些无用值/类型的定义来细化系统调用参数描述。

图6 参数细化示例。

例如，如图6所示，的第二个参数是一个对象，其结构在第3行到第7行定义。其嵌套结构之一在第9行到第13行定义。是一个联合体，可以是任何合法的控制消息对象。Syzlang在第10行到第12行进一步定义了七种合法的控制消息类型，并为每一种消息类型指定了类型字段的值（RDS_CMSG_RDMA_ARGS,RDS_CMSG_RDMA_DEST等等）。从图1第6行的条件中，我们提取出一个名为“RDS_CMSG_RDMA_ARGS”的潜在参数条件，它与图6第10行的参数描述相匹配。因此我们知道，要达到，需要采用一个“RDS_CMSG_RDMA_ARGS”消息，而其他类型的消息对象则无用。最后，我们通过从的定义中删除其他消息对象的定义（即第11行和第12行）来完善参数定义。

4.4 距离计算与检测

SyzDirect主要沿用AFLGo的方法来计算静态基本块级别的距离，并针对Linux内核做了一些适应性调整。首先，SyzDirect使用MLTA算法[31]构建Linux内核的调用图（CG），该算法基于类型分析来处理间接调用。基于构建好的调用图，SyzDirect对目标位置进行可达性分析，以找出可达函数和不可达函数。对于不可达函数中的基本块，它们到目标位置的距离被记录为无穷大。然后，SyzDirect进行过程内分析，为每个可达函数构建控制流图（CFG）。基于CFG和CG，SyzDirect按照AFLGo中提出的公式，为可达函数中的每个基本块计算基本块级别的距离。与AFLGo的原始实现相比，我们引入了可达性分析，以减少距离计算过程中由无关代码带来的开销。

此外，我们计算了几个实用工具，这些工具用于基于块级距离在内核模糊测试中促进定向性：

  1. 系统调用级别距离描述了系统调用的执行路径到目标位置的距离。系统调用距离通过取系统调用执行的所有基本块的最短距离来计算。
  2. 种子层级距离描述了输入种子执行到目标代码的距离。我们将输入种子中包含的所有系统调用的最小系统调用距离作为种子层级距离。
  3. 模板级距离描述了模板生成的所有种子到目标位点的距离。我们取模板生成的前5个最短种子距离的平均值来计算模板级距离。

我们修改了KCOV模块[23]，以对内核进行检测，从而跟踪基本块级别的距离。由于KCOV模块监控整个系统调用的执行过程，我们还修改了KCOV模块以动态计算系统调用距离。在从KCOV接收到距离反馈后，模糊测试器会计算种子级别距离和模板级别距离。

4.5 基于模板引导的定向内核模糊测试

SyzDirect根据静态分析结果生成模板。具体而言，SyzDirect为每对入口系统调用及其相关系统调用生成带有细化参数描述的模板。在定向模糊测试过程中，SyzDirect利用生成的模板和运行时距离反馈来指导模糊测试器。一般来说，定向模糊测试器的变异和调度策略遵循两个原则以提高其有效性：

  1. 模板引导变异。模板提供了触发目标位点所需的系统调用序列和重要参数条件，这些是静态分析所识别出来的。因此，SyzDirect在模板的引导下进行种子变异。也就是说，它倾向于生成这样的种子输入：不仅包含模板所指示的系统调用序列，而且满足模板所指示的参数约束。
  2. 距离引导调度。与现有的定向模糊测试工具[10][14]类似，SyzDirect根据距离反馈来安排种子优先级。距离目标位点更近的种子被变异的概率更大。此外，由于静态分析可能会提供多个模板，模糊测试工具还需要根据距离信息对模板进行优先级排序。

基于这些原则，我们开发了新的种子选择策略和种子变异策略，并引入了模板选择机制。接下来，我们详细介绍这些策略。

初始语料库过滤与生成。模糊测试器将初始语料库作为初始种子。由于初始语料库对模糊测试器的性能影响很大[34][37]，SyzDirect会过滤掉对到达目标位置无用的初始种子。具体来说，SyzDirect会分析初始语料库中的种子，并将它们与静态分析提供的模板进行匹配。如果某个种子的系统调用序列包含某个模板提供的序列，SyzDirect就保留该种子。否则，SyzDirect就舍弃该种子。

此外，如果没有有价值的初始种子，SyzDirect会执行初始种子生成。给定一个模板，SyzDirect会生成几个程序，这些程序由模板提供的系统调用组成，并利用sSyzkaller的参数生成功能来填充其参数。此外，SyzDirect确保在生成种子时，将相关系统调用生成的资源作为入口系统调用的参数提供。

种子保存与调度。如4.4节所述，我们将测试种子的距离定义为该种子中包含的所有系统调用的最短距离。作为一个定向模糊测试器，SyzDirect认为，如果一个测试用例具有新的边缘覆盖或者实现了更短的距离，那么这个测试用例就是有趣的，并将其保存为种子。SyzDirect从两个方面对种子进行调度。首先，在种子选择过程中，SyzDirect优先选择距离较短的种子，因为较短的距离表明该种子对触发目标位点更有利。其次，SyzDirect将功率调度引入模糊测试器，为测试用例分配不同的变异机会。距离目标位点非常近的测试用例有更多机会触发目标，应分配更多能量。具体来说，SyzDirect迁移了AFLGo[10]使用的基于退火的功率调度算法。

种子变异与生成。SyzDirect利用模板从两个维度指导种子变异过程：系统调用变异和参数变异。从系统调用的角度来看，对于给定的模板，SyzDirect确保变异生成的测试用例既包含入口系统调用，也包含模板提供的相关系统调用。具体来说，SyzDirect检查变异后的测试用例的系统调用序列是否与某个模板匹配。如果没有匹配的模板，SyzDirect会选择一个模板，并将所选模板的系统调用序列插入到测试用例的末尾。从参数的角度来看，SyzDirect确保变异过程符合模板中的参数约束。此外，由于变异目标系统调用的参数对触发目标更有价值，SyzDirect会增加入口系统调用的参数变异概率。

当种子队列为空时，Syzkaller可能会直接生成一个新种子。与对变异策略所做的调整类似，我们也修改了种子生成策略。具体来说，SyzDirect同样会选择一个模板，生成一个新程序，然后将模板中的系统调用插入到该程序的末尾。在生成过程中，SyzDirect确保生成的种子符合模板的参数约束。

模板选择。当静态分析提供多个模板时，模糊测试器在种子变异过程中需要从中选择一个模板。由于距离越短表明该模板相对于其他模板质量越高，SyzDirect还会根据模板距离对模板进行优先级排序。具体来说，SyzDirect根据距离为每个模板分配权重值，然后根据权重计算模板 被选中的概率：

5 评估

在本节中，我们从多个方面对SyzDirect进行了全面评估。首先，我们评估SyzDirect在定向模糊测试的两个重要应用场景——漏洞重现和补丁测试中的性能，这是衡量(DGFs)能力的重要标准。我们还将SyzDIRECT与Syzkaller、SyzGo（AFLGo的内核端口）和GREBE[28]进行了比较。其次，我们评估了SyzDirect每个关键组件的贡献，包括系统调用识别（即入口点识别和系统调用依赖推断的结合）、系统调用参数优化和距离引导。第三，考虑到静态分析对定向模糊测试工具性能的重大影响，我们评估了静态分析的准确性。

综上所述，我们旨在回答以下问题：

  • 研究问题1：SyzDirect在复现目标漏洞方面表现如何？
  • 研究问题2：SyzDirect在补丁测试中的性能如何？
  • 研究问题3：每个组件分别对SyzDirect的性能有何贡献？
  • 研究问题4：SyzDirect的静态分析在提取入口系统调用/参数约束方面的效果如何？

5.1 评估设置

评估数据集。我们构建了两个数据集，以评估SyzDirect在漏洞重现和补丁测试应用场景中的性能。

  • 已知漏洞。我们从Syzbot平台收集影响稳定Linux内核版本（即v5.10-v6.2）的已披露漏洞，作为漏洞数据集。为了减轻漏洞触发稳定性对我们评估的影响，我们过滤掉那些无法使用Syzbot提供的复现程序稳定复现的漏洞。 为确保漏洞数据集的多样性，我们采用两种不同的策略从剩余漏洞中选择漏洞。❶第一种策略是纯粹的随机选择。我们随机挑选50个涉及不同漏洞类型的漏洞，包括警告、通用保护故障（GPF）、系统崩溃（panic）等。❷第二种策略是选择与安全相关的漏洞。具体来说，我们随机挑选50个与内核地址消毒剂（Kernel Address Sanitizer，KASAN）相关的漏洞，因为内存损坏错误是内核中最常见的安全漏洞。通过这些选择策略，该数据集涵盖了不同类型的内核漏洞，并包含了许多与安全相关的缺陷。最终，该数据集由100个漏洞组成，我们将在这些漏洞上评估SyzDirect的漏洞重现能力。
  • 补丁。为确保补丁的多样性，我们分别采用两种不同的方法来收集良性补丁和错误补丁。❶我们从Syzbot平台随机收集了33个补丁修复。我们手动确认这33个补丁都已正确修复了漏洞，并将它们作为良性补丁。❷由于没有公开可用的Linux内核错误补丁数据集，我们通过查看提交信息在Linux内核代码库中手动定位错误补丁。具体来说，我们检查了一次提交的“修复”字段，该字段指向引入漏洞的提交，并检查引入漏洞的提交是否也是一个漏洞修复提交。如果是，那么引入漏洞的提交就是一个错误补丁。最后，我们检查了从Linux内核v5.10到v5.18的提交，并从手动收集的错误补丁中随机选择了29个样本，补丁数据集总共包含62个（33 + 29）补丁。

由于论文篇幅有限，这两个数据集的详细信息在我们的github仓库中展示。

评估指标。对于补丁测试和漏洞复现，我们主要关注每个模糊测试器在时间限制内能够覆盖的用例数量。也就是说，模糊测试器能够成功触及的补丁数量以及它能够成功复现的漏洞数量。对于每个用例，我们使用命中轮数（hitting-round）和首次发现时间（Timeto-Exposure，TTE）作为评估指标，这些指标在定向模糊测试相关论文[10][14]中被广泛使用。具体而言，命中轮数表示在多次重复实验中，模糊测试器触发目标漏洞或到达目标位置的次数。TTE是指模糊测试器首次完成目标任务（触发目标漏洞等）的时间。 我们在多次重复实验中计算触发时间（TTE）的算术平均值，记为。具体来说，如果模糊测试工具在模糊测试超时时间（例如24小时）内未触发目标，那么这种情况下的TTE视为超时时间。

基线模糊测试工具。我们将SyzDirect与三个模糊测试工具进行比较：Syzkaller[18]、SyzGo和GREBE[28]：

  • Syzkaller是应用最为广泛的基于代码覆盖率引导的内核模糊测试工具。我们选择Syzkaller作为无导向模糊测试工具的基线。
  • SyzGo是一款模糊测试工具，我们将AFLGo[10]（最先进的动态引导模糊测试工具之一）的方法应用于Syzkaller，并将其作为定向模糊测试工具的基线。具体而言，SyzGo通过§4.4中介绍的方法收集种子距离，并利用AFLGo基于退火的功率调度来对种子进行优先级排序。
  • GREBE是与SyzDirect最为相关的工作。它采用有向模糊测试方法来探索内核漏洞的更多错误行为。具体而言，我们进行了两项调整，以便将GREBE应用于我们的评估任务。首先，GREBE需要将漏洞证明（PoC）程序作为其初始语料库，而在漏洞重现和补丁测试中无法获取该语料库。因此，在我们的评估中，GREBE将Syzkaller提供的默认语料库作为其初始种子。其次，由于原始GREBE的分析与KASAN的最新版本不兼容，在我们的数据集中的某些情况下会失败。因此，我们扩展了GREBE的漏洞报告解析功能，并修复了这些问题。

我们使用Syzkaller、SyzGo和GREBE作为基线，以表明SyzDirect比现有的定向和非定向模糊测试工具高效得多。

环境与配置。在所有实验中，我们利用LLVM，使用Syzbot提供的配置文件来编译内核。由于初始种子语料库对模糊测试器的有效性有很大影响[34][37]，我们对这三个模糊测试器使用相同的初始种子，这些种子由Syzkaller的默认设置提供。所有实验均在一台服务器上进行，该服务器配备144个144 Intel(R) Xeon(R) Gold 6254 CPUs (3.10GHz)和384GB运行内存，运行64位Ubuntu 18.04 LTS系统。

5.2 研究问题1：漏洞重现

在本实验中，我们应用SyzDirect以及三个基准模糊测试工具，借助其崩溃报告在已知漏洞数据集中重现漏洞。对于每个漏洞，我们分析崩溃报告的堆栈跟踪，然后手动确定SyzDirect和SyzGo的目标代码位置。GREBE将崩溃报告作为输入，并自动识别关键对象。对于每个目标，我们为SyzDirect和SyzGo设置24小时的模糊测试时间限制。由于Syzkaller不是定向模糊测试工具，为了进行公平比较，我们给它48小时。每个实验重复10次以减少统计误差。此外，正如GREBE的作者在论文中所建议的，我们针对每个案例运行GREBE达7天。由于通过匹配崩溃标题来确认目标漏洞是否被重现并不准确[32]，因此我们手动检查模糊测试期间生成的所有崩溃情况，以确定模糊测试工具是否成功重现了目标漏洞。

与Syzkaller的对比。在实验过程中，Syzkaller和SyzDirect复现了43个漏洞。我们在表1中展示详细结果，并在图7的维恩图中总结24小时的结果。具体而言，SyzDirect和 分别复现了42个和10个已知漏洞。SyzDirect覆盖了由生成的所有漏洞。尽管我们运行了Syzkaller 48小时，但 只发现了另外两个SyzDirect无法发现的漏洞。此外，在两者都覆盖的10个漏洞上，SyzDirect相比Syzkaller速度提升了154.3倍。这一结果表明，SyzDirect的性能显著优于现有的通用内核模糊测试工具。

图7 24小时漏洞复现结果的维恩图。

表1 SyzDirect、SyzGo和Syzkaller在漏洞重现方面的性能。

与SyzGo的比较。SyzGo的性能也列于表1和图7中。具体而言，SyzGo复现了11个已知漏洞，这些漏洞SyzDirect均能复现。此外，在这10个漏洞上，SyzDirect相较于SyzGo实现了81.9倍的速度提升。令人惊讶的是，尽管SyzGo是一个定向模糊测试工具，但它的表现并不比Syzkaller好多少。这表明仅靠距离引导不足以有效缩小内核模糊测试的探索空间。相比之下，SyzDirect引入了新的方法和技术，并且性能显著优于SyzGo。

表2 SyzDirect与GREBE在重现漏洞方面的比较。

与GREBE的比较。我们在表2中展示了SyzDirect与GREBE之间的比较。具体而言，GREBE复现了19个漏洞，其中9个漏洞SyzDirect在24小时内无法复现。有趣的是，这9个漏洞中有5个与KASAN相关。我们认为这是因为GREBE提出的新颖的对象驱动模糊测试非常适合复现内存损坏漏洞。同时，SyzDirect覆盖了32个漏洞，即使GREBE进行7天的模糊测试也无法复现。这表明在更多情况下，SyzDirect的方案比GREBE能更有效地减少探索空间。简而言之，SyzDirect可以覆盖更多数量的漏洞，而GREBE擅长处理一些SyzDirect难以应对的KASAN漏洞。GREBE和SyzDirect可以相互补充。

5.3 研究问题2：补丁测试

在本实验中，我们应用SyzDirect来测试补丁数据集中的补丁，并将我们的方法与SyzGo和Syzkaller进行比较。

补丁测试的目标是在不同上下文环境下测试补丁代码，以发现潜在的与补丁相关的漏洞。因此，我们将补丁覆盖率作为主要指标，即模糊测试工具是否能够触达打补丁后的代码。我们将补丁提交所修改的代码设为DGF的目标。对于修改了多个位置的补丁提交，我们手动定位与漏洞成因最相关的代码作为目标位置。

图8 24小时补丁测试结果的维恩图。

表3 SyzDirect、SyzGo和Syzkaller在补丁测试中的性能。

对于这62个补丁，49个补丁能在24小时内被至少一个模糊测试器触达。如图8所示，SyzDirect覆盖了其他模糊测试器所涉及的所有补丁。具体而言，SyzDIRECT、SyzGo和分别覆盖了49个、36个和39个补丁。与这些模糊测试器相比，仅能多触达一个补丁。表3展示了模糊测试器触达每个补丁的确切时间。在大多数补丁上，SyzDirect比所有基线更快地到达补丁位置，与和SyzGo相比，平均加速比分别达到680.9和620.2。

此外，在补丁测试期间，SyzDirect、SyzGo和Syzkaller分别发现了15个、11个和12个由已知错误补丁引入的漏洞。特别是，SyzDirect发现了4个其他两个基线方法无法检测到的由错误补丁引入的漏洞。这一结果表明，SyzDirect带来的增强的定向模糊测试能力或许能帮助开发者发现更多由补丁引入的漏洞。

5.4 研究问题1与研究问题2的失败分析

在§5.2和§5.3中SyzDirect未能复现或触及的所有漏洞和补丁中，我们手动分析了来自Syzbot的漏洞证明（PoC）、静态分析结果以及模糊测试日志，以探究SyzDirect失败的原因。我们总共总结出这些失败的三个原因：

  • 不完整的依赖系统调用推断（R1）。SyzDirect 将与入口系统调用存在显式依赖关系的系统调用推断为相关系统调用，这会遗漏对入口系统调用存在隐式依赖关系的系统调用。由于依赖系统调用推断不完整，SyzDirect 未能生成到达目标位置所需的系统调用序列。
  • 生成合适的参数存在困难（R2）。在某些情况下，SyzDirect生成了正确的系统调用序列，但未能生成能够触发漏洞或目标代码的参数。尽管SyzDirect利用提取的参数条件来指导参数变异，但生成合适的参数仍面临两个挑战。首先，SyzDirect的静态分析主要关注到达代码的条件，而非触发漏洞的条件。因此，尽管能够到达漏洞处，但SyzDirect无法生成满足触发漏洞严格约束条件的参数。其次，对于Syzkaller而言，生成诸如文件系统镜像之类的对象参数仍然极具挑战性。SyzDirect在这方面继承了Syzkaller的局限性。
  • 对相关系统调用（R3）缺乏深度分析。触发目标漏洞/站点不仅需要入口系统调用的正确参数，还需要相关系统调用的特定上下文和参数。SyzDirect的静态分析不会对相关系统调用进行深度分析，例如到达目标所需的相关系统调用的参数条件。因此，当相关系统调用需要特定参数或复杂上下文才能到达目标时，SyzDirect可能会失败。

如表4所示的详细案例分类，超过一半的故障是由于对相关系统调用缺乏深入分析造成的。在本文中，我们主要的技术贡献是识别入口点和细化入口系统调用的参数。我们将对相关系统调用的深入分析留作未来的工作。在第6节中，我们将讨论如何改进SyzDirect。

表4 故障案例的原因细分。

5.5 研究问题3：不同组件的贡献

如 §4 所述，SyzDirect在定向模糊测试方面的指导来自三个组件：距离反馈、系统调用识别和系统调用参数优化。为评估每个关键组件的贡献，我们设计并实现了SyzDirect的两个变体。❶我们设计了，这是SyzDirect的一个变体版本，它禁用了系统调用参数优化组件。此外，的系统调用参数变异保留了Syzkaller的默认实现。❷我们设计了，这是SyzDirect的一个变体版本，它禁用了运行时距离反馈。

也就是说，按照Syzkaller的默认先进先出顺序调度种子队列。然后，我们使用和，在24小时的时间限制内重新运行了漏洞重现实验，并将其与SyzDirect进行了比较。此外，我们对每种情况重复实验10次。请注意，由于系统调用参数优化是基于系统调用识别的，因此我们不能只关闭系统调用识别组件。幸运的是，我们可以通过比较和Syzgo来评估系统调用识别的效果。它们之间的主要区别在于，利用了系统调用识别。

实验结果如图9所示。SyzDirect、和分别在24小时内成功复现了42个、22个和23个漏洞。一方面，完整版本的SyzDirect比和多覆盖了近100%的漏洞，证明系统调用参数细化和距离引导非常有效。另一方面，比SyzGo多覆盖了近100%的漏洞。结果表明，仅距离引导对DGF效果甚微，但通过利用本文提出的静态分析技术识别出的入口系统调用和依赖系统调用，可显著提升效果。总之，这三个关键设计组件对SyzDirect贡献巨大。

图9 三者的漏洞重现对比。

5.6 研究问题4：静态分析的有效性

为了更好地理解SyzDirect静态分析的性能，我们在漏洞重现数据集中评估入口点识别、相关系统调用推断和参数优化的有效性。

图10 每个目标漏洞上识别出的入口系统调用数量分布。

入口点识别的有效性。图10展示了100个漏洞中入口点识别的结果。结果表明，SyzDirect从每个漏洞的4000多个系统调用中平均识别出3.61个入口系统调用。特别地，SyzDirect为61%的漏洞确定的入口系统调用不超过3个。

很难证明某个系统调用无法到达目标位置。因此，我们采用了一种评估方法来衡量入口系统调用识别的有效性。具体来说，我们提取了PoC使用的入口系统调用作为正确的入口系统调用，并将其与SyzDirect识别出的系统调用进行比较，这展示了我们方法的下限。结果表明，SyzDirect为所有100个漏洞都正确定位了PoC使用的入口系统调用，并且平均多识别出2.61个其他系统调用。这些结果表明，SyzDirect的静态分析能够定位正确的入口系统调用，并大大减少了DGF的系统调用入口探索空间。

图11 每个目标漏洞上提取的入口系统调用与相关系统调用对的数量分布。

依赖系统调用推断的有效性。SyzDirect为每个识别出的入口系统调用推断其依赖的系统调用，并将入口系统调用所依赖的系统调用视为相关系统调用。我们统计每个漏洞的入口系统调用与相关系统调用的对数。如图11所示，60% 的漏洞的入口系统调用与相关系统调用的对数不超过10对。有6个漏洞的对数超过40对。这是因为它们的入口系统调用需要一个通用资源对象（如TTY对象）作为参数，导致Syzdirect将大量的生产者定位为相关系统调用。我们还将来自漏洞证明（PoC）的系统调用与SyzDirect的结果进行了比较。结果表明，SyzDirect为87个漏洞正确定位了相关系统调用。对于其余13个案例，SyzDirect未能推断出正确的相关系统调用，因为SyzDirect仅考虑系统调用之间的显式依赖关系。更有趣的是，在这13个失败的案例中，SyzDirect仍然复现了6个漏洞，因为模糊测试器通过种子变异生成了正确的相关系统调用。

参数细化的有效性。为了评估系统调用参数细化，我们研究SyzDirect是否能为漏洞证明（PoC）中使用的正确入口系统调用提取有效的参数条件。总体而言，SyzDirect为100个目标漏洞中的59个正确入口系统调用提取了参数条件。在手动分析这些漏洞的触发过程后，我们发现所提取的条件对于54个漏洞到达漏洞点是必要的。在另外5个漏洞中，静态分析定位到的条件与触发漏洞无关，因为所提取的条件位于其他内核上而非系统调用参数。对于41个(100-59)错误，SyzDirect由于两个原因未提取参数条件。首先，一些与参数相关的检查非常复杂，SyzDirect的静态分析无法对这类检查进行建模，因此未能收集到相关条件。其次，SyzDirect的参数细化在很大程度上依赖于Syzlang描述。对于几个系统调用，Syzlang描述未提供详细的参数定义，因此提取的条件无法与任何参数匹配，并被我们的分析丢弃。

6 局限性与未来工作

6.1 静态分析的不确定性

SyzDirect通过执行静态分析来识别各种信息以到达目标站点。尽管SyzDirect利用内核设计和Syzlang描述来减少入口点识别的误报和参数细化的漏报，但静态分析仍然存在误报和漏报情况。由于我们赋予了动态模糊测试灵活性，使其能够探索静态分析结果之外的系统调用，因此如 §5.6 所讨论的，模糊测试可以帮助纠正部分错误。完全消除静态分析的不准确性极具挑战性。一方面，这需要更有效的基础工具，以便对内核进行完善的控制流和数据流分析。另一方面，这需要全面理解内核语义，从而将内核函数与Syzlang描述进行匹配。

6.2 对依赖系统调用的进一步分析

依赖的系统调用及其参数也会影响目标站点是否可以被间接触发。作为针对Linux内核的首个动态生成框架（DGF），我们专注于应对现有研究的主要挑战，即入口点识别和入口系统调用的参数优化。我们计划在未来探索如何更准确地识别依赖的系统调用，以及如何对依赖的系统调用进行参数优化。

6.3 对Syzlang的依赖

如 §3 和 §4 所述，SyzDirect的静态分析确实依赖于手动定义的Syzlang。幸运的是，一些技术（例如SyzDescribe[20]）已经被用来自动生成系统调用描述。在这些技术下，当Syzlang不同步时，SyzDirect仍然可以正常工作。

7 相关工作

7.1 定向灰盒模糊测试

关于定向灰盒模糊测试已经有大量的研究工作。我们在 §2.1 总结了通用的定向灰盒模糊测试解决方案，并在 §2.2 阐述了它们在处理操作系统内核时的局限性。我们提出SyzDirect作为针对Linux内核的通用定向灰盒模糊测试解决方案，它可以用于多种任务，包括崩溃重现、补丁测试等。

此外，有一些研究[28][44]针对特定任务提出了一些定制化的动态定向模糊测试（DGF）技术。KLAUS[44]旨在通过定向模糊测试评估内核补丁的正确性。为了触发与错误补丁相关的漏洞，KLAUS的定向模糊测试机制不仅专注于到达特定的程序位置，还考虑了补丁修改的读写操作的顺序和类型。GREBE[28]提出了一种巧妙的方法来探索内核漏洞的更多错误行为。GREBE提出了一个静态分析框架，以识别某个漏洞的关键内核对象，然后引入一种定向模糊测试机制，将关键对象的命中情况作为反馈。与这些研究相比，SyzDirect是一种通用的动态定向模糊测试（DGF），并将代码可达性作为主要目标。因此，SyzDirect提出了几种新技术，以识别到达特定程序位置所需的系统调用和参数约束。

7.2 内核模糊测试

Linux内核是模糊测试中的一个重要目标。与以主函数作为入口点的用户空间应用程序不同，Linux内核有几个不同的入口点，包括系统调用、I/O控制处理函数和中断请求处理函数。由于系统调用接口使用最为广泛，因此许多研究致力于通过系统调用接口对内核进行测试[4][18][24][34][38][40][42]。除了将代码覆盖率作为反馈外，许多研究还利用不同的技术，如静态分析[34]、符号执行[24]、动态分析[40]和强化学习[42]来提高测试效率。除了测试系统调用接口，研究人员还提出了一些新颖的技术来测试其他通道，如直接内存访问（DMA）[39]、USB接口[35]和驱动中断[21]。这些研究旨在覆盖更多的内核代码并发现更多漏洞，而SyzDirect则专注于测试特定的代码位置。

7.3 用于模糊测试的系统调用识别

除了探索所有系统调用的通用内核模糊测试之外，还有一些研究致力于探索如何根据不同的模糊测试场景识别关键系统调用。SemFuzz[45] 旨在基于编写良好的错误报告生成概念验证。它应用自然语言处理从错误报告和Linux代码库日志中提取所需的系统调用，以指导模糊测试。GREBE[28] 提出了一种自动化方法，用于识别有价值的系统调用，以便在模糊测试期间从种子语料库中探索更多错误行为。然而，它需要概念验证程序作为其初始语料库来确定系统调用的初始范围。总之，现有工作依赖于辅助材料，如编写良好的错误报告和用于辅助系统调用识别的PoC程序。相比之下，作为一种通用的动态生成模糊测试（DGF）工具，SyzDirect可在缺少此类材料的情况下，为给定目标站点定位有价值的系统调用。

8 结论

在本文中，我们提出了SyzDirect，这是一种针对Linux内核的动态生成式模糊测试（DGF）解决方案。为应对Linux内核特性带来的独特挑战，SyzDirect采用了新颖的静态分析方法，以识别入口系统调用及其参数条件，这极大地缩小了DGF的探索空间。结合基于距离的反馈和静态提取的信息，SyzDirect调整其种子调度和种子变异，以引导模糊测试器对目标位置进行压力测试。我们对上游Linux内核进行的广泛评估表明，在崩溃重现和补丁测试方面，SyzDirect比通用内核模糊测试器和现有的DGF技术更有效且高效。

参考文献

  1. 1.2017. Patch of Dirty COW Vulnerability Incomplete, Researchers Claim. https://www.securityweek.com/patch-dirty-cow-vulnerability-incomplete-researchers-claim/. ↩
  2. 2.2022. K01311152: Linux kernel vulnerabilities CVE-2020-36322 and CVE-202128950. https://my.f5.com/manage/s/article/K01311152. ↩
  3. 3.2022. net/rds: fix warn in rds_message_alloc_sgs. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea010070d0a7497253d5a6f919f6dd107450b31a. ↩
  4. 4.2022. Trinity: Linux system call fuzzer. https://github.com/kernelslacker/trinity.. ↩
  5. 5.2023. Kernel.org Bugzilla. https://bugzilla.kernel.org. ↩
  6. 6.2023. Syzkaller System Call Description. https://github.com/google/syzkaller/tree/master/sys/linux. ↩
  7. 7.Cornelius Aschermann, Sergej Schumilo, Tim Blazytko, Robert Gawlik, and Thorsten Holz. 2019. REDQUEEN: Fuzzing with Input-to-State Correspondence. In 26th Annual Network and Distributed System Security Symposium, NDSS 2019, San Diego, California, USA, February 24-27, 2019. The Internet Society. ↩
  8. 8.Jia-Ju Bai, Tuo Li, Kangjie Lu, and Shi-Min Hu. 2021. Static Detection of Unsafe DMA Accesses in Device Drivers. In 30th USENIX Security Symposium, USENIX Security 2021, August 11-13, 2021, Michael Bailey and Rachel Greenstadt (Eds.). USENIX Association, 1629–1645. ↩
  9. 9.Sam Blackshear, Bor-Yuh Evan Chang, and Manu Sridharan. 2013. Thresher: Precise Refutations for Heap Reachability. In Proceedings of the 34th ACM SIGPLAN Conference on Programming Language Design and Implementation (Seattle, Washington, USA) (PLDI ’13). Association for Computing Machinery, New York, NY, USA, 275–286. https://doi.org/10.1145/2491956.2462186 ↩
  10. 10.Marcel Böhme, Van-Thuan Pham, Manh-Dung Nguyen, and Abhik Roychoudhury. 2017. Directed Greybox Fuzzing. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (Dallas, Texas, USA) (CCS ’17). Association for Computing Machinery, New York, NY, USA, 2329–2344. https://doi.org/10.1145/3133956.3134020 ↩
  11. 11.Cristian Cadar, Daniel Dunbar, and Dawson Engler. 2008. KLEE: Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs. In Proceedings of the 8th USENIX Conference on Operating Systems Design and Implementation (San Diego, California) (OSDI’08). USENIX Association, USA, 209–224. ↩
  12. 12.Satish Chandra, Stephen J. Fink, and Manu Sridharan. 2009. Snugglebug: A Powerful Approach to Weakest Preconditions. In Proceedings of the 30th ACM SIGPLAN Conference on Programming Language Design and Implementation (Dublin, Ireland) (PLDI ’09). Association for Computing Machinery, New York, NY, USA, 363–374. https://doi.org/10.1145/1542476.1542517 ↩
  13. 13.Bo Chen, Zhenkun Yang, Li Lei, Kai Cong, and Fei Xie. 2020. Automated Bug Detection and Replay for COTS Linux Kernel Modules with Concolic Execution. In 2020 IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER). 172–183. https://doi.org/10.1109/SANER48275.2020.9054797 ↩
  14. 14.Hongxu Chen, Yinxing Xue, Yuekang Li, Bihuan Chen, Xiaofei Xie, Xiuheng Wu, and Yang Liu. 2018. Hawkeye: Towards a Desired Directed Grey-Box Fuzzer. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (Toronto, Canada) (CCS ’18). Association for Computing Machinery, New York, NY, USA, 2095–2108. https://doi.org/10.1145/3243734.3243849 ↩
  15. 15.Zhengjie Du, Yuekang Li, Yang Liu, and Bing Mao. 2022. WindRanger: a directed greybox fuzzer driven by deviation basic blocks. In Proceedings of the 44th International Conference on Software Engineering. 2440–2451. ↩
  16. 16.Navid Emamdoost, Qiushi Wu, Kangjie Lu, and Stephen McCamant. 2021. Detecting Kernel Memory Leaks in Specialized Modules with Ownership Reasoning. In 28th Annual Network and Distributed System Security Symposium, NDSS 2021, virtually, February 21-25, 2021. The Internet Society. ↩
  17. 17.Shuitao Gan, Chao Zhang, Peng Chen, Bodong Zhao, Xiaojun Qin, Dong Wu, and Zuoning Chen. 2020. GREYONE: Data Flow Sensitive Fuzzing. In Proceedings of the 29th USENIX Conference on Security Symposium (SEC’20). USENIX Association, USA, Article 145, 18 pages. ↩
  18. 18.Google. 2022. Syzkaller. https://github.com/google/syzkaller. ↩
  19. 19.Google. 2022. syzlang. https://github.com/google/syzkaller/blob/master/docs/syscall_descriptions_syntax.md. ↩
  20. 20.Yu Hao, Guoren Li, Xiaochen Zou, Weiteng Chen, Shitong Zhu, Zhiyun Qian, and Ardalan Amiri Sani. 2023. SyzDescribe: Principled, Automated, Static Generation of Syscall Descriptions for Kernel Drivers. In 44rd IEEE Symposium on Security and Privacy, SP 2023, San Francisco, CA, USA, May 22-25, 2023. IEEE. ↩
  21. 21.Felicitas Hetzelt, Martin Radev, Robert Buhren, Mathias Morbitzer, and JeanPierre Seifert. 2021. VIA: Analyzing Device Interfaces of Protected Virtual Machines. In Annual Computer Security Applications Conference (Virtual Event, USA) (ACSAC ’21). Association for Computing Machinery, New York, NY, USA, 273–284. https://doi.org/10.1145/3485832.3488011 ↩
  22. 22.Heqing Huang, Yiyuan Guo, Qingkai Shi, Peisen Yao, Rongxin Wu, and Charles Zhang. 2022. BEACON: Directed Grey-Box Fuzzing with Provable Path Pruning. In 2022 IEEE Symposium on Security and Privacy (SP). 36–50. https://doi.org/10.1109/SP46214.2022.9833751 ↩
  23. 23.kernel.org. 2022. kcov: code coverage for fuzzing. https://www.kernel.org/doc/html/v5.9/dev-tools/kcov.html. ↩
  24. 24.Kyungtae Kim, Dae R. Jeong, Chung Hwan Kim, Yeongjin Jang, Insik Shin, and Byoungyoung Lee. 2020. HFL: Hybrid Fuzzing on the Linux Kernel. In 27th Annual Network and Distributed System Security Symposium, NDSS 2020, San Diego, California, USA, February 23-26, 2020. The Internet Society. https://www.ndsssymposium.org/ndss-paper/hfl-hybrid-fuzzing-on-the-linux-kernel/ ↩
  25. 25.Chris Lattner and Vikram Adve. 2004. LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation. In Proceedings of the International Symposium on Code Generation and Optimization: Feedback-Directed and Runtime Optimization (Palo Alto, California) (CGO ’04). IEEE Computer Society, USA, 75. ↩
  26. 26.Gwangmu Lee, Woochul Shim, and Byoungyoung Lee. 2021. Constraint-guided Directed Greybox Fuzzing.. In USENIX Security Symposium. 3559–3576. ↩
  27. 27.Tuo Li, Jia-Ju Bai, Yulei Sui, and Shi-Min Hu. 2022. Path-sensitive and alias-aware typestate analysis for detecting OS bugs. In ASPLOS ’22: 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Lausanne, Switzerland, 28 February 2022 - 4 March 2022, Babak Falsafi, Michael Ferdman, Shan Lu, and Thomas F. Wenisch (Eds.). ACM, 859–872. ↩
  28. 28.Zhenpeng Lin, Yueqi Chen, Yuhang Wu, Dongliang Mu, Chensheng Yu, Xinyu Xing, and Kang Li. 2022. GREBE: Unveiling Exploitation Potential for Linux Kernel Bugs. In 2022 IEEE Symposium on Security and Privacy (SP). 2078–2095. https://doi.org/10.1109/SP46214.2022.9833683 ↩
  29. 29.Dinghao Liu, Qiushi Wu, Shouling Ji, Kangjie Lu, Zhenguang Liu, Jianhai Chen, and Qinming He. 2021. Detecting Missed Security Operations Through Differential Checking of Object-Based Similar Paths. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security (Virtual Event, Republic of Korea) (CCS ’21). Association for Computing Machinery, New York, NY, USA, 1627–1644. https://doi.org/10.1145/3460120.3485373 ↩
  30. 30.Jian Liu, Lin Yi, Weiteng Chen, Chengyu Song, Zhiyun Qian, and Qiuping Yi. 2022. LinKRID: Vetting Imbalance Reference Counting in Linux kernel with Symbolic Execution. In 31st USENIX Security Symposium, USENIX Security 2022, Boston, MA, USA, August 10-12, 2022, Kevin R. B. Butler and Kurt Thomas (Eds.). USENIX Association, 125–142. ↩
  31. 31.Kangjie Lu and Hong Hu. 2019. Where Does It Go? Refining Indirect-Call Targets with Multi-Layer Type Analysis. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (London, United Kingdom) (CCS ’19). Association for Computing Machinery, New York, NY, USA, 1867–1881. https://doi.org/10.1145/3319535.3354244 ↩
  32. 32.Dongliang Mu, Yuhang Wu, Yueqi Chen, Zhenpeng Lin, Chensheng Yu, Xinyu Xing, and Gang Wang. 2022. An In-depth Analysis of Duplicated Linux Kernel Bug Reports. In Network and Distributed Systems Security (NDSS) Symposium 2022. ↩
  33. 33.Saswat Padhi, Rahul Sharma, and Todd Millstein. 2016. Data-Driven Precondition Inference with Learned Features. In Proceedings of the 37th ACM SIGPLAN Conference on Programming Language Design and Implementation (Santa Barbara, CA, USA) (PLDI ’16). Association for Computing Machinery, New York, NY, USA, 42–56. https://doi.org/10.1145/2908080.2908099 ↩
  34. 34.Shankara Pailoor, Andrew Aday, and Suman Jana. 2018. Moonshine: Optimizing OS Fuzzer Seed Selection with Trace Distillation. In Proceedings of the 27th USENIX Conference on Security Symposium (Baltimore, MD, USA). USENIX Association, USA, 729–743. ↩
  35. 35.Hui Peng and Mathias Payer. 2020. USBFuzz: A Framework for Fuzzing USB Drivers by Device Emulation. In Proceedings of the 29th USENIX Conference on Security Symposium (SEC’20). USENIX Association, USA, Article 144, 17 pages. ↩
  36. 36.David A. Ramos and Dawson Engler. 2015. Under-Constrained Symbolic Execution: Correctness Checking for Real Code. In 24th USENIX Security Symposium (USENIX Security 15). USENIX Association, Washington, D.C., 49– 64. https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/ramos ↩
  37. 37.Alexandre Rebert, Sang Kil Cha, Thanassis Avgerinos, Jonathan Foote, David Warren, Gustavo Grieco, and David Brumley. 2014. Optimizing Seed Selection for Fuzzing. In Proceedings of the 23rd USENIX Conference on Security Symposium (San Diego, CA). USENIX Association, USA, 861–875. ↩
  38. 38.Sergej Schumilo, Cornelius Aschermann, Robert Gawlik, Sebastian Schinzel, and Thorsten Holz. 2017. KAFL: Hardware-Assisted Feedback Fuzzing for OS Kernels. In Proceedings of the 26th USENIX Conference on Security Symposium (Vancouver, BC, Canada) (SEC’17). USENIX Association, USA, 167–182. ↩
  39. 39.Dokyung Song, Felicitas Hetzelt, Dipanjan Das, Chad Spensky, Yeoul Na, Stijn Volckaert, Giovanni Vigna, Christopher Kruegel, Jean-Pierre Seifert, and Michael Franz. 2019. PeriScope: An Effective Probing and Fuzzing Framework for the Hardware-OS Boundary. In Network and Distributed System Security Symposium (NDSS). ↩
  40. 40.Hao Sun, Yuheng Shen, Cong Wang, Jianzhong Liu, Yu Jiang, Ting Chen, and Aiguo Cui. 2021. HEALER: Relation Learning Guided Kernel Fuzzing. In Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles (Virtual Event, Germany) (SOSP ’21). Association for Computing Machinery, New York, NY, USA, 344–358. https://doi.org/10.1145/3477132.3483547 ↩
  41. 41.Xin Tan, Yuan Zhang, Xiyu Yang, Kangjie Lu, and Min Yang. 2021. Detecting kernel refcount bugs with two-dimensional consistency checking. In the 30th USENIX Security Symposium (Security’21). ↩
  42. 42.Daimeng Wang, Zheng Zhang, Hang Zhang, Zhiyun Qian, Srikanth V. Krishnamurthy, and Nael B. Abu-Ghazaleh. 2021. SyzVegas: Beating Kernel Fuzzing Odds with Reinforcement Learning. In 30th USENIX Security Symposium, USENIX Security 2021, August 11-13, 2021, Michael Bailey and Rachel Greenstadt (Eds.). USENIX Association, 2741–2758. https://www.usenix.org/conference/us ↩
  43. 43.Qiushi Wu, Yang He, Stephen McCamant, and Kangjie Lu. 2020. Precisely Characterizing Security Impact in a Flood of Patches via Symbolic Rule Comparison. In 27th Annual Network and Distributed System Security Symposium, NDSS 2020, San Diego, California, USA, February 23-26, 2020. The Internet Society. ↩
  44. 44.Yuhang Wu, Zhenpeng Lin, Yueqi Chen, Dang K Le, Dongliang Mu, and Xinyu Xing. 2023. Mitigating Security Risks in Linux with KLAUS: A Method for Evaluating Patch Correctness. In 32st USENIX Security Symposium, USENIX Security 2023. USENIX Association. ↩
  45. 45.Wei You, Peiyuan Zong, Kai Chen, XiaoFeng Wang, Xiaojing Liao, Pan Bian, and Bin Liang. 2017. SemFuzz: Semantics-Based Automatic Generation of Proof-ofConcept Exploits. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (Dallas, Texas, USA) (CCS ’17). Association for Computing Machinery, New York, NY, USA, 2139–2154. https://doi.org/10.1145/3133956.3134085 ↩
  46. 46.Yizhuo Zhai, Yu Hao, Zheng Zhang, Weiteng Chen, Guoren Li, Zhiyun Qian, Chengyu Song, Manu Sridharan, Srikanth V. Krishnamurthy, Trent Jaeger, and Paul L. Yu. 2022. Progressive Scrutiny: Incremental Detection of UBI bugs in the Linux Kernel. In 29th Annual Network and Distributed System Security Symposium, NDSS 2022, San Diego, California, USA, April 24-28, 2022. The Internet Society. ↩
  47. 47.Peiyuan Zong, Tao Lv, Dawei Wang, Zizhuang Deng, Ruigang Liang, and Kai Chen. 2020. FuzzGuard: Filtering out Unreachable Inputs in Directed Grey-box Fuzzing through Deep Learning. In 29th USENIX Security Symposium (USENIX Security 20). USENIX Association, 2255-2269. https://www.usenix.org/conference/usenixsecurity20/presentation/zong ↩