syzkaller 仓库中的 durationcheck：检测 time.Duration 误乘法的 Go 静态检查器

• 测试
• 操作系统
• 网络安全

durationcheck 是 syzkaller 依赖树中收录的一个专门型 Go 静态检查器（linter），用于捕获"两个time.Duration值被相乘"这类语法正确但语义几乎必然错误的代码。本文以 syzkaller 仓库vendor目录下的 durationcheck 说明文档 为主体，结合仓库中实际 vendored 的 检查器源码 与 golangci-lint 的集成代码，完整还原这一检查器的动机、规则边界与实现原理。读完本文，你可以理解为什么time.Duration相乘是危险模式、该 linter 如何基于类型信息精确识别误用，以及它在本仓库的依赖体系中处于什么位置。

一、问题背景：Duration 相乘为什么是错误

Go 语言中time.Duration的底层类型是int64，单位为纳秒，因此它天然支持与int64互操作的算数运算。这一设计带来一个隐蔽陷阱：两个time.Duration值相乘在类型系统里完全合法，但结果通常是荒谬的。

说明文档中给出了如下（刻意构造的）示例：

func waitForSeconds(someDuration time.Duration) { timeToWait := someDuration * time.Second fmt.Printf("Waiting for %s\n", timeToWait) } func main() { waitForSeconds(5) // waits for 5 seconds waitForSeconds(5 * time.Second) // waits for 1388888h 53m 20s }

两次调用在语法上都合法，但第二次调用几乎肯定不是调用者的本意。原因在于数值放大：5 * time.Second表示5 * 1e9纳秒，再乘以time.Second（即再乘1e9纳秒）得到5e18纳秒，折合约1388888h 53m 20s——一个接近 158 年的等待时长。这类错误在简单的演示代码中一眼可辨，但如果错误的waitForSeconds调用嵌套在深层的后台逻辑中，就可能长期无人察觉。说明文档还提到，这一类错误恰好曾在某个知名软件服务的生产后端系统中真实发生过。

这正是 durationcheck 存在的原因：它专门针对"两个 Duration 相乘"这一种病态模式做静态检测，把隐藏在类型系统合法外衣下的量纲错误暴露出来。

二、durationcheck 在 syzkaller 仓库中的位置

在本仓库中，durationcheck 以 vendor 依赖快照的形式存在：

• go.mod 第 75 行声明github.com/charithe/durationcheck v0.0.10 // indirect，标记为间接依赖；
• go.sum 中有对应的两条校验记录（v0.0.10 的模块哈希与其 go.mod 哈希）；
• vendor/modules.txt 第 199 行登记了# github.com/charithe/durationcheck v0.0.10。

它之所以出现在 syzkaller 的依赖树里，是因为 syzkaller 同时 vendor 了 golangci-lint 的源码，而 golangci-lint 内置了 durationcheck 作为其可选 linter 之一。仓库中的 golangci-lint 适配层 展示了集成方式：

func NewDurationCheck() *goanalysis.Linter { a := durationcheck.Analyzer return goanalysis.NewLinter( a.Name, a.Doc, []*analysis.Analyzer{a}, nil, ).WithLoadMode(goanalysis.LoadModeTypesInfo) }

从源码结构看，golangci-lint 直接复用 durationcheck 导出的Analyzer对象，并以LoadModeTypesInfo模式加载包——这解释了后文实现中对pass.TypesInfo的依赖：该 linter 必须运行在具备完整类型信息的分析模式下。

需要说明的是：syzkaller 项目自身的 golangci-lint 配置 在linters.enable列表中启用了lll、vet、revive、staticcheck以及自研的syz-linter等检查器，但并未列入durationcheck。也就是说，在本仓库当前的 lint 流程中，durationcheck 作为 golangci-lint 提供的可选检查器被随依赖树 vendor 进来，但并未被项目自身的配置显式启用。项目的自定义检查逻辑（注释规范、flag 命名、日志格式等）单独实现在 tools/syz-linter/linter.go 中，以bin/syz-linter.so插件形式挂载到 golangci-lint。

三、安装与使用方式

说明文档给出的官方使用方式如下（要求 Go 1.11 或更高版本）：

go get -u github.com/charithe/durationcheck/cmd/durationcheck

安装后，用包路径（或 import 路径）作为参数直接调用：

durationcheck ./... # or durationcheck github.com/you/yourproject/...

即对当前模块的全部包或指定的远程包路径执行检查，命中规则时在对应表达式位置报告Multiplication of durations: ...诊断信息。

vendor 快照中附带了上游项目的 Makefile，其中build/install目标分别执行go build -ldflags '-s -w' -o durationcheck ./cmd/durationcheck与go install ./cmd/durationcheck（GO111MODULE=on）。需要注意：本仓库的 vendor 快照仅包含核心包 durationcheck.go 单文件，未包含上游的cmd/目录与 testdata 测试用例，说明文档中引用的测试用例文件在本仓库中不存在，阅读实现细节时请以 vendored 源码为准。

四、实现原理剖析（基于 vendored 源码）

以下分析全部基于 vendor/github.com/charithe/durationcheck/durationcheck.go，文件共 191 行，结构清晰完整。

4.1 分析器注册与快速跳过

检查器以标准go/analysis框架注册：

var Analyzer = &analysis.Analyzer{ Name: "durationcheck", Doc: "check for two durations multiplied together", Run: run, Requires: []*analysis.Analyzer{inspect.Analyzer}, }

它依赖inspect.Analyzer（基于ast.Inspector的 AST 遍历基础设施）。run函数首先做一个廉价的快速过滤：

if !hasImport(pass.Pkg, "time") { return nil, nil }

hasImport遍历pass.Pkg.Imports()检查是否存在time包导入。由于time.Duration只可能来自标准库time，未导入time的包必然不可能命中规则，这一步避免了大量包的无谓遍历，是该 linter 保持轻量的关键设计。

4.2 命中条件：乘法 + 双 Duration 操作数

核心检测逻辑在check返回的闭包中，遍历所有*ast.BinaryExpr节点，判定链条为：

1. 运算符必须是token.MUL，加减等其他运算符直接跳过；
2. 通过pass.TypesInfo.Types[expr.X]/[expr.Y]取两侧操作数的静态类型（取不到类型信息则跳过）；
3. isDuration判定类型是否为 Duration：

func isDuration(x types.Type) bool { return x.String() == "time.Duration" || x.String() == "*time.Duration" }

注意这里同时接受time.Duration与*time.Duration两种类型——指针 Duration（例如取函数返回的时间差指针）参与相乘同样是误用；

4. 仅当两侧都是 Duration 且两侧都是"不可接受表达式"时才报告，报告信息为Multiplication of durations: `%s`，其中%s由formatNode经format.Node将原表达式格式化为源码文本回填，方便开发者直接定位。

4.3 "不可接受表达式"的规则边界

仅凭"两边类型都是 Duration"还不够：someCount * time.Second这类"计数值乘以单位常量"是 idiomatic Go，绝不能误报。区分二者的关键在isUnacceptableExpr——它要求乘法两侧都不含任何可辨识的"合理操作数"：

func isUnacceptableExpr(pass *analysis.Pass, expr ast.Expr) bool { switch e := expr.(type) { case *ast.BasicLit: return false // 字面量（如 5、time.Second 这类标识符解析出的常量）视为可接受 ... } }

可接受（acceptable）的表达式由isAcceptableNestedExpr递归判定，归纳起来允许以下形式：

用第一节示例对照：someDuration * time.Second中左侧标识符someDuration的声明类型是time.Duration（不可接受），右侧time.Second是包选择器且底层为纳秒常量标识符（可接受），两侧一可一不可，不报告；而5 * time.Second作为实参传入后被外层逻辑再做someDuration * time.Second的场景，真正被报告的是函数体内那个"Duration 变量 × Duration 常量"的乘法节点。规则的本质是：只有当乘法至少两侧都疑似是"携带量纲的 Duration 值"（而非纯计数或纯单位）时，才判定为量纲错误。

4.4 为什么必须依赖类型信息

整个判定链中isDuration、isAcceptableIdent、isAcceptableCast都依赖pass.TypesInfo提供的声明类型与对象信息。这意味着 durationcheck 无法退化成纯文本匹配（例如简单的duration * time.Second正则就会把合法代码全部误杀），也解释了 4.1 节 golangci-lint 集成时指定LoadModeTypesInfo的原因。这是理解该 linter 精度边界的关键：它能识别变量声明类型与函数返回类型，但判定依据是静态类型而非值的实际量纲，因此"变量名叫 count 但类型标成了time.Duration"这类命名错误不在其检测范围内。

五、小结

durationcheck 是一个"小而准"的 Go 静态检查器：以标准库time导入做快速剪枝，以token.MUL+ 双time.Duration类型做命中判定，再以"可接受表达式"递归规则排除计数 × 单位这一合法模式，最终只报告两侧都疑似携带量纲的乘法。在 syzkaller 仓库中，它作为 golangci-lint（v0.0.10）依赖链的一环被 vendor 进 vendor/github.com/charithe/durationcheck，虽未出现在项目自身 .golangci.yml 的启用列表里，但其源码完整可读，是学习"如何用go/analysis框架 + 类型信息编写高精度单规则 linter"的绝佳范本。

• 测试
• 操作系统
• 网络安全