10月26日上午，360漏洞研究院挂出一份通告：CVE-2026-98260，CVSS 7.8，Linux内核本地提权，根因在POSIX CPU timer与exec()清理路径的释放后使用（UAF）。这个洞从5.7内核（2020年）引入，潜伏了约6年6个月才被翻出来——复现它的，是360的图龙锋漏洞挖掘智能体。知乎
先说今天最有用的一句结论：这是"本地提权"，不是"远程执行"，它的前置条件是攻击者已经能在你的机器上跑代码。所以要不要连夜动手，不取决于CVE分数，取决于你的暴露面。
一、这个洞是怎么炸的
机制很内核，但能讲明白：
进程里一个不是线程组组长的线程B调用exec()。de_thread()会用exchange_tids()把B和组长线程的TID交换，然后释放原组长。此时B的CLOCK_THREAD_CPUTIME_ID计时器里还攥着旧PID——这个句柄已经查不到任何task了。
连锁反应（据360通告的复现描述）：退出清理时posix_cpu_timer_del()按旧PID找task失败，于是没把timerqueue节点摘除，却照样释放了k_itimer——队列里留下一个指向已释放内存的悬空节点。之后父进程回收这个僵尸task，cleanup_timerqueue()调用timerqueue_del()，再用container_of()去访问那块已经没了的内存并回写——经典UAF，内核内存破坏，进一步回收重用slab就能完成本地提权拿到root。官方修复commit `acb03d3881818581052924a9bbbe92b8741ed448`，标题是《exec: Cleanup POSIX timers right after de_thread()》：新增posixtimer_exec()，把计时器清理从"de_thread()之后一长串失败分支的末尾"提前到de_thread()成功的那一刻，在siglock保护下先把timerqueue摘干净，再释放对象。旧代码的坑就在bprm->point_of_no_return已置位后，exec_mmap()/exec_task_namespaces()任一fatal失败都会把线程直接送进退出路径，绕过原本posix_cpu_timers_exit()+exit_itimers()的组合清理。知乎
已验证受影响的发行版：Ubuntu；已验证受影响的Android设备：Samsung Galaxy S26 Ultra。5.7之后的中间版本均在射程内。知乎
二、这已经是2026年的第4个内核提权洞了
把镜头拉远看时间线，今年Linux内核的安全日历忙得不正常：
披露时间 | 漏洞 | 评分 | 潜伏时长 | 机制一句话 |
|---|---|---|---|---|
4月30日 | CVE-2026-31431（CopyFail） | 7.8 | 约9年 | copy_page_to_iter()边界算错，可向任意可读文件的page cache注入4字节 |
5月8日 | DirtyFrag | 高危 | 2017年起 | 影响几乎所有主流发行版，极空间等NAS厂商专门发过用户通告 |
6月27日 | CVE-2026-43503（DirtyClone） | 8.8 | — | JFrog披露的DirtyFrag家族变体，__pskb_copy_fclone()克隆套接字缓冲区缺陷，可静默拿root |
10月21-22日 | ksmbd两枚（ZDI-CAN-33774/33549） | 9.0×2 | — | 内核内置SMB3服务器：SMB1/SMB2分派竞态（免认证）+SMB Direct整数下溢（约8KB堆溢出） |
10月26日 | CVE-2026-98260 | 7.8 | 6年6个月 | POSIX CPU timer的exec清理路径UAF |
时间线每一行背后都有披露方在盯着：CopyFail潜伏约9年、评分7.8，节前的全球运维几乎被它拖进加班。DirtyClone则是JFrog挖出的DirtyFrag家族全新变种，评分8.8、本地攻击者可静默拿root。波及面大到什么程度？消费级NAS厂商极空间在5月直接给用户发安全提示。微博微博微博
半年4个提权洞、两枚9.0分，对应的是披露侧的集体暴涨：2026年的CVE编号在9月25日首次突破10万，此前最高纪录是2025年全年的70,729个。Epoch AI 7月的报告追踪了21家科技巨头，6月单月高危或严重级CVE约1300-1500个，是此前月均的3.5倍以上。知乎知乎
但这里要纠正一个流行的错误推论：CVE暴涨≠内核在变坏。CopyFail潜伏9年、98260潜伏6年半，这些洞从一开始就趴在代码里，只是以前没人有能力挖。AI把挖洞从"几周一洞的手艺"压成"几小时一批的产能"，披露曲线就是铲子变便宜的直接投影。证据只到披露统计为止——所以下面的判断也止步于此：不是代码更烂了，是发现变多了。
三、更有意思的是另一件事：补丁还没写，列表先公开了
10月21、22日，趋势科技旗下ZDI把6份内核漏洞报告投到了公开的LKML等邮件列表，所有报告都没带补丁，其中几份还附了KASAN调用栈和完整PoC源码。哔哩哔哩
稳定维护者Greg Kroah-Hartman在同几分钟内直接回列表质问：“又一次，没有补丁，还发到了公开列表？请修正你们的提交方式”。哔哩哔哩
B站上OS视界搬运这条新闻的视频，热评第一（38赞）：“都不知道该说什么……运维兄弟，走好。”
这不是纯粹的失误，是流程跟不上发现速度。内核安全文档在2026年5月更新了规则：由AI工具发现的漏洞，按定义已经公开，应直接发送给子系统开发者列表——而ZDI这次的发现，功劳就记在自家AI扫描器TrendAI头上，公开投递正是这条规则的产物。ZDI的正式公告排在2027年2月；截至发稿，没有任何来源报告这两个洞已被在野利用。哔哩哔哩
最反常识的一点是：内核项目只在补丁进入稳定分支之后才分配CVE编号。也就是说，ksmbd这两枚9.0目前一个CVE号都没有——按CVE号匹配的漏洞扫描器，现在一条都扫不出来。“没有编号"不再等于"没有漏洞”，这大概是2026年内核安全最该被记住的规则变化。哔哩哔哩
四、对号入座
个人桌面/Samba用户：98260需要本地代码执行权限，对你的现实威胁很低；KSMBD不是Samba，上游默认不开，只跑Samba的机器不受影响。等发行版内核更新就行。
NAS/ARM板（Armbian这类，开了ksmbd）：先自查`lsmod | grep ksmbd`。用不上就stop+disable；必须用就防火墙收紧445、关掉SMB Direct、禁止SMB1协商——分别掐掉两枚9.0的触发前提。
VPS/容器宿主机/多租户环境：本地提权的前提是"能跑不可信代码"，这恰好是你的场景。宿主机内核升级请排到最近窗口，不要等CVE编号。
Android用户：Galaxy S26 Ultra已被360验证受影响，等厂商OTA和安全公告。
企业补丁团队：排序依据用暴露面，别用分数——7.8"带本地前提"的优先级，应低于9.0"免认证远程可达"；情报源盯stable邮件列表和发行版CVE tracker，扫描器报表此刻会漏。
五、接下来盯什么
CVE-2026-98260的修复commit何时进入stable并出现在发行版更新里（Ubuntu的CVE页面会最先给信）。
ksmbd修复状态：ZDI-CAN-33774的维护者树commit（68f410faedaf）是否合入主线，ZDI-CAN-33549是否如报道落在面向Linux 7.5的分支。
2027年2月ZDI正式公告落地时，公开投递争议会不会有定论。
"AI发现=已公开"这条规则，会不会在这次GKH开炮之后被再改一轮。
铲子便宜了，洞就藏不住了。2026年内核安全的这个秋天，稀缺的从来不是"找到洞"，而是"排对洞"。今晚要不要爬起来打补丁，答案不写在CVSS里，写在你自己的暴露面上。
