AI 漏洞报告洪流令旧版 Linux 驱动面临风险

Linux 因一场尖锐冲突登上 Google News：AI 编程代理发现了更多缺陷，但其报告也在推动旧驱动走向移除。

眼下的事件涉及老化的内核代码：几乎没有可见用户，也没有活跃的硬件测试。自动化工具可以低成本检查这些代码，但每一份可信报告仍需要人工维护者投入精力处理。

这改变了保留沉寂硬件支持的成本结构。过去静静躺在内核中的代码，如今可能持续引发审查、安全讨论、补丁和回归风险。

这场冲突并不只是 Linux 与 AI 的对立。包括 Linus Torvalds 和 Greg Kroah-Hartman 在内的内核领袖，一直支持在明确由人类负责的前提下合理使用 AI 辅助工具。

真正的较量更为广泛：近乎无限规模的自动化发现能力，对上时间严格受限的人类验证能力。旧版驱动正处在这两种力量的交汇点。

Linux 已在 2026 年移除大量过时的网络代码。围绕 staging 驱动的新限制也表明，维护者正在收紧 AI 辅助工作的条件。

其结果影响的不只是老旧硬件。Linux 正在检验：当发现潜在缺陷变得远比证明并修复缺陷容易时，一个大型开源项目应如何应对。

Google News 报道后 Linux 发生了什么变化

当自动化代理能够持续针对旧 Linux 驱动产出新发现时，保留这些驱动已不再廉价。

该报道于 2026 年 8 月 6 日通过 Google News 出现，将读者引向 Linux 内核社区内部的旧版驱动压力。这一最新担忧延续了数月以来围绕 AI 生成报告和修复的争论。

驱动程序将操作系统连接到特定硬件设备。许多 Linux 驱动在内核中运行，错误代码可能导致系统崩溃或暴露特权内存。

staging 树存放尚未达到内核常规质量要求的驱动。它也为新贡献者提供了学习项目开发实践的场所。

官方Linux 内核开发流程将 staging 描述为需要进一步完善、才能进入主线内核的驱动之家。每个驱动都应附带剩余任务清单和相关联系人。

这一用途给自动化贡献带来了问题。编程代理可以完成表面的清理任务，却未必能帮助其操作者理解驱动、硬件或内核子系统。

据报道，维护 staging 区域的 Greg Kroah-Hartman 已对这类提交划出更严格的界限。AI 发现的安全修复仍有可能被接受，但贡献者应在实际硬件上测试，并说明测试情况。

这一要求将责任重新交给提交者。模型给出的看似合理的解释，并不能被视为缺陷确实存在或补丁有效的证明。

这种区别很重要，因为旧驱动可能含有可疑代码，却并不意味着存在可被触达的漏洞。硬件状态、调用上下文、锁机制和内核配置都可能推翻代理的分析。

实体测试也是大多数自动化提交所缺少的证据。任何人都能让模型从任意地点扫描源代码，但对应设备可能已有数十年历史。

当没有人能够测试硬件时，维护者就面临一个棘手选择：无限期调查理论上的发现，或移除那些用户社区无法证明仍有持续需求的代码。

Linux 以前就做过这种选择。在 Linux 7.1 开发周期中，维护者移除了 ISDN 支持、业余无线电网络代码以及大量旧网络驱动。

据内核移除报道，合并后的改动删除了约 138,000 行代码。受影响的代码包括一些尽管活跃使用证据有限、却长期保留在上游的技术。

因此，最新讨论是既有清理工作进入了新阶段。它并非突然禁止旧硬件，也不是全面拒绝 AI。

相反，Linux 维护者要求有证据表明，仍有人在使用、理解并愿意为每个驱动承担责任。没有这些证据，自动化漏洞报告会让移除变得越来越有吸引力。

AI 编程代理为何改变了维护成本方程

AI 并未制造这些旧代码，但它改变了这些代码需要人类关注的频率。

沉寂驱动过去带来的持续成本较低。维护者会在全内核变更期间更新接口，审查偶尔出现的补丁，并处理真实用户报告的缺陷。

AI 编程代理改变了这一模式，因为它们可以持续搜索庞大的代码库。它们能够标记缺失检查、可疑指针使用、整数错误、竞态条件以及不一致的清理路径。

静态分析器和模糊测试工具此前已在做相关工作。模糊测试会向软件输入意外数据以暴露崩溃，而静态分析则在不执行代码的情况下检查代码。

LLM 增加了自然语言说明和拟议补丁。这些能力降低了将可疑模式转化为一封看似完整邮件所需的工作量。

即使底层分析薄弱，输出也可能显得完整。一份报告可能包含详细的故障叙述、安全标签和看似合理的补丁，却没有证明漏洞是否可被触达。

这种呈现方式造成了不对称的工作量。生成报告只需几分钟，而验证它则可能需要硬件、专业的子系统知识以及多轮审查。

重复发现又增加了一层问题。多名用户可以用相似模型扫描同一份公开代码，并在彼此不知情的情况下提交几乎相同的发现。

Linus Torvalds 在 Linux 7.1 发布周期中描述了这一影响。他表示，持续涌入的 AI 报告已令私有安全邮件列表几乎完全难以管理。

核心问题并不是每一份报告都是错误的。Torvalds 强调，不同的人使用相似工具发现相同问题，造成了大量重复。

安全报告尤其敏感，因为维护者不能轻率地忽视一个看似合理的内核缺陷。即使是薄弱的主张，也可能需要保密协调，才能判断它是否可被利用。

内核现已发布面向贡献者的官方AI 助手指南。该指南规定，无论使用何种辅助工具，提交变更的人类都应承担责任。

这个原则听起来简单，但执行取决于证据。无法解释补丁或复现其效果的贡献者，无法提供有意义的责任归属。

旧驱动加剧了这个问题。当前的网络、图形和存储驱动通常拥有厂商、测试者、持续集成以及清晰可见的安装用户基础。

而面向冷门 ISA、PCMCIA 或已停产嵌入式设备的驱动，可能完全没有这些保障。即便硬件已从普通开发实验室中消失，源代码仍对代理可见。

维护者 Andrew Lunn 在此前的网络驱动清理期间解释了这一转变。他表示，在 AI 用户和模糊测试工具开始发现更多问题之前，旧驱动并未带来多少维护负担。

拟议的网络代码清理涵盖来自 3Com、AMD、SMSC、Fujitsu、Cirrus Logic、Xircom 以及多个基于 8390 的产品线的硬件。当时估算的首批移除代码约为 27,646 行。

代码本身并没有突然变差。改变的是外部人士能够针对它提出问题主张的速度。

这正是本文的核心反转。更好的缺陷发现本应改善软件，但没有验证的发现可能令不受支持的软件维护成本过高。

这个问题类似于一个过载的搜索系统。提高召回率会找出更多可能匹配项，而过滤不足则让专家不得不亲手筛选每个质量不高的结果。

使用 AI 进行技术调查的团队面临同样的挑战。他们需要让可搜索的证据、硬件记录、测试结果和先前决策与每一项生成的主张并列呈现。

一个可搜索的知识库可以保留这些上下文。它无法取代验证，但可以避免重复调查在缺乏机构记忆的情况下重新开始。

对 Linux 而言，邮件列表档案提供了丰富的历史记录。但它们仍无法变出一张可用的网卡、复现设备特定故障，或自愿成为长期维护者。

这种缺口让实体访问和人类问责成为稀缺资源。AI 让代码审查变得充足，但不会自动让可信的维护能力变得充足。

AI 发现与人类证明如今成为对立力量

这场 Linux 争议关乎证据与责任，而不是维护者是否应允许使用 AI 工具。

Torvalds 已明确否定 Linux 应成为反 AI 项目的观点。今年 7 月，他将 AI 描述为另一种工具，并告诉反对者，开源允许他们自行 fork 项目。

他的支持附带一个同样重要的条件：LLM 工具应当帮助维护者，而不是给他们增添额外痛苦。

这一立场使讨论不会坍缩为两个简单阵营。Linux 既不会接受每一项由代理生成的贡献，也不会拒绝模型的所有使用方式。

Kroah-Hartman 展示了中间路线。他使用本地 AI 系统检查内核代码，同时亲自审查发现结果，并为提交的修复承担责任。

据报道，他在本地运行的“clanker”工作流截至 4 月下旬已产出近两打合并补丁，涉及 ALSA、HID、SMB、Nouveau 和 IO_uring 代码。

这些补丁包含明确的 AI 辅助归属说明和谨慎的测试声明。Kroah-Hartman 要求审阅者验证改动，而不是把代理输出当作权威结论。

这种工作流与将未经验证的模型对话发送到邮件列表截然不同。它让一名经验丰富的维护者处于自动化发现与项目审查队列之间。

AI 辅助维护也有助于保留旧代码。6 月，开发者在清理早期世代 Radeon 硬件的 R600 图形驱动时使用了 GitHub Copilot。

据报道，这项工作涉及着色器编译器代码的 59 次提交。每次提交都披露了 Copilot 的参与，由人类贡献者对最终改动负责。

这些例子表明，AI 既可能延长驱动寿命，也可能缩短其寿命。决定因素是硬件访问条件、贡献者知识、测试和持续的责任承担。

一份有价值的报告应包含可复现的故障、受影响的配置、对可触达性的说明，以及补丁能够解决问题的证据。单独一条生成的警告无法提供这些保证。

这一区别也解释了为何 staging 树受到特别对待。staging 在一定程度上是一个教育环境，贡献者通过直接工作培养判断力。

如果模型完成每一项清理工作，贡献者可能错失其中的教育意义。补丁或许改善了格式，却没有让任何人更有能力维护该驱动程序。

安全修复仍是合理的例外，因为忽视已验证的漏洞会带来危险。然而，对硬件测试的要求将这一例外限定在有具体证据支持的发现上。

这项政策设定的是证据门槛，而不是意识形态禁令。贡献者可以使用工具，但不能把自己的责任转移给这些工具。

同样的标准也体现在内核更广泛的贡献模式中。官方的开发者原产地证书要求贡献者证明自己有权提交变更。

AI 带来了关于作者身份和披露的新问题，但它并不会抹去人类的署名。发送补丁的人仍需对其内容负责。

随着智能体自主性不断增强，这种责任变得更加重要。一个能够搜索、编辑、测试并提交代码的工具，可能比传统自动补全系统带来多得多的审查工作。

Linux 没有能够为这一队列无限配置人手的集中式工程经理。维护者经常需要在雇主支持的工作与跨专业子系统的志愿审查之间取得平衡。

因此，开源模式依赖贡献者保持克制。具备生成报告的技术能力，并不意味着发送报告就一定有益于项目。

这正是 Google News 的报道可能简化问题的地方。一则关于 AI 导致驱动程序被移除的标题，听起来像是维护者因为不喜欢自动化而惩罚旧硬件。

但有记录的冲突指向了别处。随着自动化发现的增长速度超过经验证的责任归属，缺乏支持的代码变得代价高昂。

驱动程序移除正是这种失衡的最终体现。它降低了攻击面、审查队列和未来迁移工作量，但也终止了对仍在使用这些硬件的用户的上游支持。

任何一方都得不到完美结果。维护者重新获得了注意力空间，但部分仍可正常运行的硬件将失去与未来主线内核的兼容性。

驱动程序移除带来真实代价

删除无人维护的代码是理性的，但看不到活跃用户并不能证明已无人依赖它。

Linux 支持异常广泛的硬件。这样的覆盖范围帮助研究人员、维修社群、工业运营者和爱好者让旧系统继续发挥作用。

这些系统中的许多不会向内核开发者上报遥测数据。它们的用户可能安装长期支持版发行版内核，却从不参与上游讨论。

因此，沉寂的邮件列表只能提供不完整的证据。硬件可能仍部署在实验室、工厂、电信设备或专用控制系统中，却不会产生新的补丁。

从主线内核中移除并不会立即禁用每一套此类安装。现有内核版本、发行版软件包和私有分支都可能保留这些代码。

然而，继续使用旧内核会带来不断累积的代价。安全支持会结束，工具链会变化，周边软件最终也会假定存在更新的内核接口。

树外驱动程序还会带来另一重负担。每次相关内核变更后，都必须有人适配、测试并单独分发它。

对于厂商或有组织的社区而言，这项工作是现实可行的。但对于依赖上游支持的孤立用户来说难度大得多——他们依赖上游支持，恰恰是因为没有其他人维护该设备。

这里还存在安全层面的模糊性。旧代码可能确实包含漏洞，即便 AI 报告夸大了其可利用性。

移除驱动程序能够防止其未来暴露在主线内核中，但现有部署并不会自动获得保护。固定在旧内核上的系统可能同时保留硬件支持和底层缺陷。

因此，维护者必须避免将删除描述成万能的安全修复。它缩小了未来责任范围，却推动现有用户迁移或自行维护。

4 月的网络驱动移除提供了一个有价值的先例。维护者将工作拆分为单独的补丁，使用户能够识别并反对具体的删除项。

当有人能够证明仍在活跃使用并愿意承担维护职责时，这种方式使恢复成为可能。它将移除视为对证据的请求，而非不可逆的抹除。

这一方法也揭示了一项重要标准：希望代码继续保留，并不等同于维护它。

有说服力的异议应当指明硬件、提供测试、审查未来变更，并在新报告出现时作出响应。没有这项承诺，原有工作量就不会改变。

另一个不确定因素是 AI 发现的质量。一些报告是重复项或误报，另一些则揭示了传统审查遗漏的真实缺陷。

针对内核误报的研究已将驱动程序和文件系统认定为困难领域。外部依赖和语义误解可能让可疑代码看似存在缺陷，实际上却是有效的。

智能体可能识别出熟悉的不安全模式，却遗漏了其他位置的锁、不变量或验证步骤。内核执行路径往往跨越多个文件和特定架构层。

反过来，若一概否定所有生成的发现，也会浪费一个有用的检测来源。智能体工具能够检查几乎没有获得常规审查的冷门代码。

正确的应对取决于分诊质量。项目需要在联系维护者之前，建立用于归并重复项、测试可达性、评估严重程度并附上可复现证据的机制。

Linux 目前在最终边界上仍高度依赖人工判断。这依然是必要的，但随着提交量上升，其可持续性正在下降。

智能体开发者也应承担责任。系统不应自动将每一种可疑模式转换为公开或私下的安全报告。

它应搜索既有讨论、尝试复现、说明不确定性，并指出缺少的硬件证据。速率限制也能防止一次实验压垮一个子系统。

维护者可以像暂存政策如今所做的那样，明确规定提交要求。这些要求让拒绝变得可预测，也为负责任的贡献者提供可衡量的标准。

风险在于过度纠正。如果证据门槛要求在任何讨论前都必须具备罕见的实体硬件，那么被遗弃设备中的真实漏洞可能始终得不到审查。

这并不意味着维护者必须修复一切。它意味着移除决策应在现有证据允许的范围内，尽可能清楚地区分报告噪音、已验证风险和实际用户需求。

Google News 正在揭示更广泛的开源能力危机

Linux 正在暴露一个问题：当自动化贡献几乎零成本时，每一个大型开源项目都会面对它。

AI 编程工具降低了生成补丁、安全报告、文档变更和问题提交的成本，但并未降低所有相应的审查成本。

当软件具有高权限、硬件针对性强，或由小型团队维护时，审查尤其昂贵。Linux 内核同时具备这三种条件。

其规模使该项目成为自动化研究的理想目标。公开源码、公开历史、成熟的审查渠道和高安全价值，为智能体提供了丰富素材。

成功也会鼓励重复。一旦某位研究人员因 AI 辅助发现获得认可，其他人便可以针对同一代码库运行类似工作流。

这种激励不需要恶意意图。贡献者可能真诚地认为每一份生成的报告都有帮助，即便维护者已收到多个变体。

这种影响类似垃圾信息，因为生产成本低廉，筛选成本却很高。然而，普通垃圾邮件过滤器无法安全地丢弃一条可能描述内核漏洞的消息。

其他开源项目很可能会根据自身风险采用定制的证据要求。一个 Web 库可能要求提供最小复现示例，而硬件项目可能要求设备日志。

项目也可能将自动化发现与公开报告分开。可信的分诊系统可以在发现送达个人维护者之前对其进行整合。

AI 可以协助这一防御层。智能体能够比较报告、识别重复项、运行测试，并在人工打开队列之前检索过往决定。

这比发送原始发现更具建设性。模型帮助压缩注意力需求，而不是将其成倍放大。

Linux 已经展现出两种结果。Sashiko 和其他智能体审查系统试图大规模发现缺陷，而经验丰富的维护者则在受控工作流中使用本地模型。

与此同时，未经验证的提交已使安全讨论承压。由于其责任归属本已薄弱，遗留代码成为减轻这种压力最容易的地方。

因此，驱动程序移除发挥着治理信号的作用。代码能否持续被纳入，取决于其可维护性，而非其年代、怀旧价值或仅仅理论上的有用性。

这一原则早于 LLM 出现。新工具只是更快地暴露了缺乏支持的区域，并让隐藏的维护债务显现出来。

“维护债务”指的是仍在活跃却缺乏充分责任归属的代码所产生的未来工作。它包括安全审查、接口更新、测试和用户支持。

一款旧驱动程序可能多年都能编译通过，且没有明显问题。一旦智能体持续产生相关发现，其维护债务就会对每个审查报告的人显现出来。

同样的模式也会影响企业软件。公司可能发现，AI 辅助审计会在归档系统和内部工具中制造数千个看似可信的问题。

平等对待每一项发现将压垮安全和工程团队。忽视所有机器生成的结果又会遗漏真实缺陷。

组织需要来源追溯、去重、可复现性、责任归属和基于风险的路由。这些控制措施比由哪个具体模型完成初步分析更重要。

文档也会成为运营证据。团队应保留哪些硬件经过测试、哪些配置仍受支持，以及为何此前的发现被拒绝。

个人知识系统可以帮助个人工程师跨项目保留这些历史记录。正式决策仍需要共享的问题跟踪和测试基础设施。

Linux 案例也挑战了对 AI 生产力的常见衡量方式。统计生成的补丁或发现的警告数量，几乎无法说明净价值。

有用的指标应扣除审查时间、重复项处理、回归问题和未解决的后续工作。它应奖励经验证的修复，而非原始产出。

这种核算方式可能让较慢的工作流显得更好。一个经过充分复现的漏洞，可能比数百份推测性报告带来更多价值。

Google News 的曝光会让这些移除获得更多关注，但关注本身无法解决人手短缺。该项目需要愿意测试并维护被忽视代码的合格人员。

对于受影响硬件的用户而言，实际信息很明确：在移除前发声，记录设备信息，测试当前内核，并自愿承担持续工作。

如今，沉默的分量更重，因为维护者无法再假定沉寂的驱动程序仍然无害。自动化审查已让被动保留成为一项日益昂贵的政策。

Linux 用户和 AI 开发者接下来应关注什么

三个信号将显示 Linux 是找到了可行的平衡，还是仅仅将负担转移到了别处。

第一个信号将来自下一批移除驱动程序的提案。关键在于，活跃用户是否会带着硬件测试结果和维护承诺出现。

成功挽救这些驱动将支持内核以证据为基础的做法。这将表明，移除讨论能够发现隐藏用户并重建责任归属。

如果出现一长串无人反对的移除事项，则说明许多被针对的代码确实已被弃用。这也会鼓励其他子系统的维护者开展类似审查。

第二个信号是对 staging tree 硬件测试要求的遵守情况。贡献者必须证明，他们能否从模型生成的怀疑转向可复现的技术证据。

高质量提交将进一步证明受控使用 AI 的合理性。反复出现未经测试的报告，则会为更严格的筛选和更广泛的拒绝政策提供依据。

第三个信号是 AI 辅助安全报告的数量和重复率。Torvalds 指出，重复提交是安全邮件列表不堪重负的核心原因。

更好的代理端分流应当能减少重复提交，同时不压制真实发现。如果报告量持续上升，Linux 可能需要更强的接收自动化机制或可信的中介团队。

该项目对 AI 的立场不太可能变成简单的是或否。Torvalds 一直支持使用工具，而维护者仍在拒绝那些将成本转移给审阅者的工作流程。

这种组合是连贯的。Linux 可以接受 AI 辅助，同时要求人类理解、测试并负责每一项贡献。

更棘手的问题在于没有所有者的代码。AI 可以揭示其缺陷，但发现工具无法保证维护它所需的硬件、时间或判断力。

因此，用户应将上游支持视为一种关系，而非永久档案。一个驱动能够存续，取决于是否有人对其进行测试、报告真实故障、审查变更并回应维护者。

开发编码代理的开发者也应重新考虑其成功标准。提交一个 issue 并不自动意味着产生了有用的结果。

更好的目标是经过验证、非重复，并且拥有足够证据供维护者采取行动的发现。当无法达到这一标准时，代理应将分析结果私下保留。

对组织而言，这一教训远不止适用于 Linux。自动化发现必须伴随自动化整合、人类问责和明确的升级阈值。

最新的 Google News 报道展现了缺少这些保障措施的一个明显后果：旧驱动面临移除，因为机器制造关注的速度快于人类提供维护的速度。

代理开发者会重新设计工具以保护审阅者的时间，还是会有更多开源项目缩减其支持范围？下一轮 Linux 驱动移除周期应会给出最清晰的答案。