CVE-2026-98118— Linux netfs 预读同步漏洞
一分钟漏洞结论
影响对象
Linux Linux
利用判断
尚无明确在野利用证据，仍需结合暴露面评估
建议动作
优先检查厂商安全公告和参考链接中的修复版本；无法立即升级时，限制受影响服务暴露并加强监测。
在 Linux 内核中，已修复以下漏洞： netfs：通过预先加载所有 folio 来修复预读同步问题 存在某些同步问题，源于应用线程在收集器线程正在查看或尝试清除它们时，向循环缓冲区添加更多 folio。例如，在下一个 folio 尚未添加时，确定 的设置就可能出现同步问题。 采用循环缓冲区方法的理由是：预先加载缓冲区然后释放所有刚获取的引用（refs）是一个相当缓慢的操作；而逐步加载可以将部分成本推迟到至少部分 I/O 开始之后。 然而，更好的方式是预先将所有 folio 加载到循环缓冲区中——然后在 I/O
可能的 ATT&CK 技术 1 AI
T1610 · Deploy Container
获取后续新漏洞提醒
登录后订阅
一、 漏洞 CVE-2026-98118 基础信息
漏洞信息
对漏洞内容有疑问？看看神龙的深度分析是否有帮助！
查看神龙十问 ↗
尽管我们使用了先进的大模型技术，但其输出仍可能包含不准确或过时的信息。神龙努力确保数据的准确性，但请您根据实际情况进行核实和判断。
Vulnerability Title
netfs: Fix readahead synchronisation issues by loading all folios upfront
来源: CVE Program / CVE List V5
Vulnerability Description
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix readahead synchronisation issues by loading all folios upfront
There are some synchronisation issues that derive from the app thread
adding more folios to the rolling buffer whilst the collector thread is
looking at them or trying to clear them, such as determining the setting of
front_folio_order when the next folio hasn't been added yet,
The reason for the rolling buffer approach is that loading the buffer
upfront and then dropping all the refs just acquired is quite a slow
operation, and loading progressively allows some of the cost to be deferred
until after at least some of the I/O is started.
Instead, a better way is to load all the folios into the rolling buffer
upfront - and then drop the refs later, once the I/O is in progress. (Even
better would be for the refs not to be there at all.)
Fix this by changing the rolling buffer loader to load all the folios
selected by the VM for readahead upfront into the folio queue. The folio
queue is allocated a batch worth at a time as we don't know how many folios
are involved (the readahead_control struct, alas, has a page count, not a
folio count).
The folio refs acquired from readahead are then dropped in bulk once the
first subrequest is dispatched as it's quite a slow operation. The
collector waits for NETFS_RREQ_NEED_PUT_RA_REFS to be cleared so that it
doesn't unlock folios before the xarray has been scanned for them.
This simplifies the buffer handling later and isn't noticeably slower as
the xarray doesn't need to be modified and the folios are all already
pre-locked.
来源: CVE Program / CVE List V5
CVSS Information
N/A
来源: CVE Program / CVE List V5
Vulnerability Type
N/A
来源: CVE Program / CVE List V5
受影响产品
二、漏洞 CVE-2026-98118 的公开POC
| # | POC 描述 | 源链接 | 神龙链接 |
|---|
AI 生成 POC
高级
未找到公开 POC。
登录以生成 AI POC三、漏洞 CVE-2026-98118 的情报信息
请登录查看更多情报信息。
CVE-2026-98118 补丁与修复 (2)
同批安全公告 · Linux · 2026-09-25 · 共 372 条
| CVE-2026-100075 | 9.8 CRITICAL | RDMA/srpt：srpt_alloc_rw_ctxs() 未释放计数器修复 |
| CVE-2026-97555 | 8.8 HIGH | smb客户端：修复DACL所有者/组重写中的堆溢出漏洞 |
| CVE-2026-97957 | 8.8 HIGH | hinic 邮箱段缓冲区溢出漏洞 |
| CVE-2026-97527 | 8.8 HIGH | qla2xxx SCSI驱动程序 NVMe未解决上下文列表竞争条件漏洞 |
| CVE-2026-97528 | 8.8 HIGH | QLogic qla2xxx驱动LS拒绝错误NVMe内存泄漏漏洞 |
| CVE-2026-98115 | 8.8 HIGH | ksmbd 注销期间会话安全排空漏洞 |
| CVE-2026-97525 | 8.2 HIGH | x86/mm/pat：内核页表分裂页表分配漏洞 |
| CVE-2026-98069 | 8.1 HIGH | Net/RDS rds_conn_shutdown() 快速路径锁获取漏洞 |
| CVE-2026-97573 | 8.1 HIGH | bnxt_en 驱动 bnxt_rx_ring_reset 缓冲区分配失败漏洞 |
| CVE-2026-97570 | 8.1 HIGH | bnxt_en: 修复因SW TPA ID绑定问题导致的崩溃漏洞 |
| CVE-2026-98130 | 8.1 HIGH | SCTP定时器启动竞争条件漏洞 |
| CVE-2026-98070 | 8.1 HIGH | Linux RDS 模块远程代码执行漏洞 |
| CVE-2026-98002 | 7.8 HIGH | AMD IOMMU 嵌套域分配中错误检查失效漏洞 |
| CVE-2026-97575 | 7.8 HIGH | v4l2-ctrls AV1瓦片计数验证漏洞 |
| CVE-2026-97576 | 7.8 HIGH | V4L2-ctrls HEVC 瓦片计数验证漏洞 |
| CVE-2026-97941 | 7.8 HIGH | Linux 内核 slab 内存分配器竞态条件漏洞 |
| CVE-2026-98112 | 7.8 HIGH | ksmbd 网络接口事件中监听器任务生命周期修复漏洞 |
| CVE-2026-98116 | 7.8 HIGH | ALSA: PCM内存映射与缓冲区重新分配序列化以修复页面UAF漏洞 |
| CVE-2026-97580 | 7.8 HIGH | rkvdec HEVC解析数组越界漏洞 |
| CVE-2026-97940 | 7.8 HIGH | IPv6 修复 fib6 遍历器在 seq 停止时存在 UAF 漏洞 |
显示前 20 条，共 372 条。 查看全部 → →
IV. Related Vulnerabilities
V. Comments for CVE-2026-98118
暂无评论