[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"news-slug-linux-kernel-ai-cve-overflow":3,"topics-all":38,"news-related-70ea74fc-77ed-49a2-8498-f24edd822970":57},{"id":4,"title":5,"summary":6,"content":7,"original_url":8,"source_id":9,"tags":10,"translations":24,"news_slug":31,"published_at":32,"created_at":33,"modified_at":34,"is_published":35,"publish_type":36,"image_url":14,"view_count":37},"70ea74fc-77ed-49a2-8498-f24edd822970","AI 工具把 Linux 内核挖出 2000 个 CVE,维护者快扛不住了","Linux 7.x 系列每个版本修复的 CVE 数从 7.1 的逾千跳到 7.2 的逾 1500,7.3 预计破 2000——罪魁是 AI 安全扫描工具对内核源码的自动挖掘。维护者 Greg Kroah-Hartman 公开喊话,Jakub Kicinski 直接说\"不堪重负\",7.3 已开始移除历史驱动以止血。","## 数字在涨,但不是内核变烂了\n\n稳定版内核维护者 Greg Kroah-Hartman 在公开幻灯片里抛出数据: Linux 7.x 系列每版修复的 CVE 数量从 7.1 的逾千跳到 7.2 的逾 1500,7.3 极可能突破 2000。Tom's Hardware 与 Solidot 几乎同步引用,两个独立来源相互印证。\n\nKroah-Hartman 的因果解释更值得追问: Linux 内核并未变得更不安全,而是 AI 辅助安全检测工具大规模涌入,对着 4000 万行源码做自动扫描,把能翻出来的「低危」缺陷一股脑扔进 CVE 库和邮件列表。\n\n## 维护者的真实困境:报告太多,人手不够\n\n自动工具揪出更多 bug 听起来像好事。现实却是 Linux 内核的维护团队规模并未同步扩张,大量报告涌进 Bugzilla、邮件列表和 patchwork 后,真正需要维护者人工甄别、复现、修复的工作量跟着指数级放大。\n\n内核网络子系统维护者 Jakub Kicinski 在相关讨论中直接用了「不堪重负」(completely overwhelmed)这样的措辞,Tom's Hardware 在标题里把这句话原样搬了出来。一个维护者要被大量机器生成的报告淹没,本身就是 AI 时代软件工程的新问题:检测能力增长的速度,远快过人类消化与决策能力的增长。\n\n绝大多数新发现的 bug 属于低危级别,不是真正的安全炸弹。维护者却不得不挨个调查——这是 GPL 协作体系下维护者的法律责任,也是上游厂商与下游发行版的合规要求。每个报告都必须有人看过、给出反馈,否则会演变成对外披露口径上的麻烦。\n\n## 7.3 已经在「砍代码」止血\n\nKroah-Hartman 的幻灯片与 Solidot 援引的材料显示,Linus Torvalds 与各子系统维护者已在 7.3 周期采取激进策略:直接移除「几乎无人使用」的旧驱动代码,以减少 AI 工具能扫描到的攻击面。\n\n7.3 已经移除了一批旧的 SGI 和 IBM 驱动。理由很直白:这些历史悠久、贡献者稀少的代码,正被 AI 工具以超高效率翻出 bug,而维护者对这些老硬件并没有多少维护意愿,留着只会让「报告洪水」雪上加霜。\n\n这是带有强烈工具理性色彩的选择: 与其投入人力去验证机器给出的成千上万条可疑报告,不如直接砍掉可能产出报告的代码。这种「减法维护」在 Linux 内核历史上相当罕见,某种程度上也是 AI 工具对开源协作模式的一次逆向倒逼。\n\n## 反思:AI 检测真让世界更安全了吗\n\nAI 辅助安全扫描工具的爆发,正在重塑所有大型开源项目的维护成本结构。一个原本可能十年没人翻出来的边界条件 bug,现在被 GPT 系或专用静态分析工具秒级扫出,自动生成 CVE、自动写邮件、自动追踪 patch 状态。短期看是「安全研究的民主化」,中长期看把维护成本推到了一个只有头部商业项目才能承受的水平。Linux 内核靠 LWN、SFC、Intel、Red Hat、华为等公司养着几十位全职维护者,才勉强接住 AI 工具的报告洪流。普通开源项目大概率会直接停摆。\n\nKroah-Hartman 把这组数据摆在公开幻灯片上,与其说是在示警,不如说是在提醒整个开源社区: 当 AI 把「找 bug」的成本压到几乎为零,「验证和修复 bug」反而成了新的瓶颈。我们需要的不仅是更强的检测模型,还有更强的 triage 工具、自动复现验证,以及愿意为开源基础设施持续买单的资金机制。否则 7.x 之后是 8.x,数字只会越来越大。\n\n> 参考:\n> - https:\u002F\u002Fwww.solidot.org\u002Fstory?sid=85265\n> - https:\u002F\u002Fwww.tomshardware.com\u002Fsoftware\u002Flinux\u002Flinux-kernel-nears-2-000-cves-per-release-as-ai-bug-hunters-scour-40-million-lines-of-code-maintainers-say-they-are-completely-overwhelmed","https:\u002F\u002Fwww.solidot.org\u002Fstory?sid=85265","d59894d3-308e-4fd8-8865-86dc1eeac4a2",[11,15,18,21],{"id":12,"name":13,"slug":13,"description":14,"color":14},"1fcfaaf2-67de-43d3-9e35-5784852fec60","ai-safety",null,{"id":16,"name":17,"slug":17,"description":14,"color":14},"40269b40-7942-4650-9672-ed2e6524d37a","ai-technology",{"id":19,"name":20,"slug":20,"description":14,"color":14},"0ef8513a-0a26-42f0-b6f9-5b6dadded45c","efficiency",{"id":22,"name":23,"slug":23,"description":14,"color":14},"b9bd9039-fcdb-41a8-b85b-fc1587def2b9","open-source",[25],{"id":26,"lang":27,"title":28,"summary":29,"content":30},"a7b3e1a2-173e-4493-bd60-53a2e25b4230","en","AI tools dig 2,000 CVEs from the Linux kernel, maintainers buckle","Linux 7.x CVE counts have jumped from \"over 1,000\" in 7.1 to \"over 1,500\" in 7.2, with 7.3 expected to break 2,000 — driven by AI security scanners sweeping ~40M lines of kernel source. Maintainer Greg Kroah-Hartman raised the alarm publicly, and Linux 7.3 has already started removing legacy drivers to stem the report flood.","## Numbers are climbing, but the kernel isn’t getting worse\n\nStable kernel maintainer Greg Kroah-Hartman surfaced a striking data point in a public slide deck: the number of CVEs fixed per Linux 7.x release has jumped from “over 1,000” in 7.1 to “over 1,500” in 7.2, with 7.3 on track to break 2,000. Tom’s Hardware and Solidot picked up the numbers almost simultaneously, with two independent outlets cross-confirming the figures.\n\nThe more interesting question is the causal explanation Kroah-Hartman attaches: the Linux kernel has not become less secure. What changed is that AI-assisted security scanning tools have flooded in, sweeping across roughly 40 million lines of source code and dumping every “low-severity” defect they can find into CVE databases and mailing lists.\n\n## The real cost: too many reports, not enough hands\n\nOn paper, automated tools surfacing more bugs sounds like progress. In practice, the Linux kernel’s maintainer headcount has not scaled with the report volume. Floods of reports pour into Bugzilla, mailing lists, and patchwork, and the actual triage, reproduction, and fix work multiplies faster than the maintainers can absorb.\n\nJakub Kicinski, who maintains the kernel’s networking subsystem, used the phrase “completely overwhelmed” in the related discussion, and Tom’s Hardware lifted that phrase straight into its headline. A handful of humans being drowned by machine-generated reports is, in itself, a new shape of AI-era software engineering: detection capability grows exponentially, while human digestion and decision capacity barely moves.\n\nThe awkward part is that most of the newly surfaced bugs are low-severity, not real security grenades. Yet maintainers are legally and ethically obligated to investigate each one — that is the deal under GPL-style coordinated disclosure, and it is also what downstream vendors and distributions require. Every report must be seen, acknowledged, and dispositioned, or it becomes a public-relations problem of its own.\n\n## 7.3 is already “deleting code” to stop the bleeding\n\nAccording to Kroah-Hartman’s slides and the Solidot write-up, Linus Torvalds and the subsystem maintainers have adopted a strikingly aggressive tactic for the 7.3 cycle: directly removing “barely used” legacy driver code to shrink the surface AI tools can scan.\n\n7.3 has already dropped a batch of old SGI and IBM drivers. The reasoning is blunt: those long-frozen, sparsely-maintained code paths are exactly where AI tools are most efficient at finding bugs, and the maintainers have no appetite to keep fixing hardware nobody runs. Leaving the code in only deepens the “report flood.”\n\nIt is a deeply instrumental choice: rather than spend human cycles validating thousands of machine-generated suspicious reports, simply delete the code that produces them. “Subtractive maintenance” of this kind is rare in Linux kernel history, and in some sense it represents AI tools pushing back, in reverse, against the open-source collaboration model.\n\n## Reflection: has AI detection actually made the world safer?\n\nThe explosion of AI-assisted security scanning tools is reshaping the maintenance cost structure of every large open-source project. A corner-case bug that might have lain dormant for a decade can now be surfaced in seconds by GPT-style or specialized static-analysis models, which then auto-generate CVE entries, auto-write emails, and auto-track patch status. In the short term that looks like the “democratization of security research.” In the medium to long term, it pushes maintenance costs up to a level only the biggest commercial-backed projects can afford. The Linux kernel gets by because LWN, the Software Freedom Conservancy, Intel, Red Hat, Huawei, and others collectively fund dozens of full-time maintainers — and even then they are barely keeping up with the report flood. An ordinary open-source project would simply grind to a halt.\n\nKroah-Hartman putting these numbers on a public slide deck is, in that light, less a warning than a nudge to the whole open-source community: when AI drives the cost of “finding a bug” to near zero, “verifying and fixing a bug” becomes the new bottleneck. What the ecosystem now needs is not just better detection models, but stronger triage tooling, automated reproduction and verification, and durable funding mechanisms for the infrastructure underneath. Otherwise 7.x will be followed by 8.x, and the CVE numbers will only keep climbing.\n\n> References:\n> - https:\u002F\u002Fwww.solidot.org\u002Fstory?sid=85265\n> - https:\u002F\u002Fwww.tomshardware.com\u002Fsoftware\u002Flinux\u002Flinux-kernel-nears-2-000-cves-per-release-as-ai-bug-hunters-scour-40-million-lines-of-code-maintainers-say-they-are-completely-overwhelmed","linux-kernel-ai-cve-overflow","2026-09-09T05:00:00Z","2026-09-09T05:08:45.118633Z","2026-09-09T05:08:45.118655Z",true,"agent",85,[39,48],{"slug":40,"tag_slug":40,"title_zh":41,"title_en":42,"intro_zh":43,"intro_en":44,"id":45,"is_active":35,"created_at":46,"modified_at":47},"ai-for-science","AI for Science 2026：从 UniPert 到 GPT-Rosalind 的硬核进化","AI for Science 2026: from UniPert to GPT-Rosalind","生命科学、化学材料、物理世界模型——AI 正在从\"语言工具\"变成\"实验伙伴\"。本专题收录 AI 在三大科学方向的关键节点：UniPert 统一基因与化学扰动空间、GPT-Rosalind 端到端生命科学推理、达摩院 AI 智能体 28 小时找到 4 种超导新材料、Anthropic Claude Science 把工作台做成标准品。","From language tool to lab partner — AI is reshaping life sciences, chemistry\u002Fmaterials, and physical world models. This topic covers the key milestones: UniPert unifying genetic-chemical perturbation spaces, GPT-Rosalind's end-to-end life-sciences reasoning, DAMO's AI agent discovering 4 superconducting materials in 28 hours, and Anthropic's Claude Science workbench going mainstream.","988a4300-5fab-41c4-b5d8-63711a2dc757","2026-09-10T01:34:15.296649Z","2026-09-10T01:34:15.296663Z",{"slug":49,"tag_slug":49,"title_zh":50,"title_en":51,"intro_zh":52,"intro_en":53,"id":54,"is_active":35,"created_at":55,"modified_at":56},"h3-series","MiniMax H3 系列：从开源权重到 35 倍吞吐","MiniMax H3 Series: from open weights to 35x throughput","MiniMax H3 自 2026 年 8 月开源以来节奏密集：官方把生成、参考与编辑收回一个模型；ComfyUI 当天压进 RTX 3060；摩尔线程 3 小时完成国产 GPU 适配；fal 后训练版把吞吐拉到 35 倍；FastH3 蒸馏再砍推理成本。本专题持续追踪 H3 的发布—开源—蒸馏—部署全链路。","Since MiniMax open-sourced H3 in August 2026 the pace has been relentless: one unified omni-modal model, same-day ComfyUI support down to an RTX 3060, a 3-hour Day-0 port to Moore Threads GPUs, fal's post-trained H3 Max at 35x throughput, and FastH3 distillation cutting inference cost further. This topic tracks the full H3 chain — release, open weights, distillation, deployment.","83ef0daa-3c31-4cb3-86ed-e5ee58654d5f","2026-09-08T07:33:19.942193Z","2026-09-08T07:33:19.942209Z",{"items":58},[59,64,69,74,79,84],{"id":60,"title":61,"news_slug":62,"published_at":63},"58ed753e-ad6d-4aac-95f4-36bf217e169c","把 10 万条人类视频变成机器人教材:RoboTok 检索 mAP 提升约 50 倍,hard 任务 79.3% 对 19.5%","robotok-retrieval-benchmark-reread","2026-09-06T21:11:25+00:00",{"id":65,"title":66,"news_slug":67,"published_at":68},"005557c5-8a3c-4d34-89bc-35d5351c4570","蒸馏只需要一条训练样本?清华实测:单条query覆盖71.5%训练状态,16条追平17k全量","one-shot-opd-single-query-distillation","2026-09-05T21:07:11+00:00",{"id":70,"title":71,"news_slug":72,"published_at":73},"7623f190-7071-4811-a6f1-32462a99b8d3","经验会过期:阿里云论文让自主后训练的有害授权率从 62.5% 降到 25%","bcit-conditional-experience-transfer-post-training","2026-09-05T17:11:11+00:00",{"id":75,"title":76,"news_slug":77,"published_at":78},"4a89fe5a-8703-49e5-b083-079cbda0fa2a","蒸馏也有副作用:中间训练期上KD,推理上涨、事实记忆反而变慢","switch-distillation-midtraining-kd","2026-09-02T17:10:00+00:00",{"id":80,"title":81,"news_slug":82,"published_at":83},"265ac7bc-a2a2-4b46-9434-c11a242099d1","OpenShot 4.0 把 YOLO、EfficientSAM 塞进桌面编辑器:本地模型终于不用订阅了","openshot-40-local-ai-object-mask","2026-09-02T03:00:00+00:00",{"id":85,"title":86,"news_slug":87,"published_at":88},"454286bd-cb8e-462e-8b33-1b4c77b27262","470M 语音模型 1 秒转写 3.5 小时:IBM 把 ASR 里的语言模型砍掉了","granite-speech-5-turbo-ctc-470m","2026-08-31T15:10:00+00:00"]