北京
一个从0.5.0版本就存在的缺陷，直到1.2.6才被正式编号。musl libc 的 regcomp 函数被披露存在多处整数溢出问题，CVE 编号为 CVE-2026-107891。
按披露信息，溢出条件由传给 regcomp 的正则表达式本身的规模和复杂度触发，与待匹配的数据无关。也就是说，攻击面不在输入文本，而在那条正则表达式本身。
要构成实际风险，应用必须使用 libc 的 regcomp 函数处理来自不可信来源的正则表达式。这一前提把受影响范围收窄到一类特定用法：把正则当数据收进来的程序。
后果分两档
最低限度是可预期的崩溃，构成拒绝服务。披露方同时指出，取决于应用本身以及它对堆上对象的使用方式和并发执行情况，任意代码执行也可能成立。
这里的关键词是"可能"。整数溢出导致分配尺寸计算错误，进而可能造成堆上的越界写——从错误的分配尺寸到可利用的越界写之间，还隔着具体应用的内存布局。
时间线与修复
- 受影响代码自 0.5.0 起就存在
- 此后直至 1.2.6 的所有版本均受影响
- 建议所有用户应用随附补丁，或在 1.2.7 发布后升级
- 无法打补丁的场景，应阻止处理来自不可信来源的正则表达式
随披露附带的补丁文件名为 0001-regex-avoid-int-overflow-in-regcomp.patch，大小 5943 字节。
谁发现的
这批问题中的第一个由 Julien Voisin 私下报告。后续分析由 Szabolcs Nagy 与 Rich Felker 完成，两人在其中发现了一组模式相似的溢出。
从"第一个问题"到"一组相似问题"，这个转折值得注意：单个整数溢出容易当成孤立笔误，成模式的溢出则指向 regcomp 内部尺寸计算逻辑的系统性缺陷。
对使用 musl 的发行版和嵌入式项目来说，判断自己是否在风险区内的方法很直接——看有没有把外部传入的正则表达式直接喂给 regcomp。有，就属于需要处理的那一类。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
