NetBSD 11.0 正式发布了,距离上一个版本 10.1(2024年12月)已经过去一年八个月。但这篇发布公告里最不寻常的,不是版本号,而是作者 Martin Husemann 主动列出的三个还没修好的安全问题——问题编号、影响模块、临时规避方法,一样不落地写在正式发布通告里。
大多数操作系统发新版的默认动作是先把已知漏洞清零。NetBSD这次反过来:先发布,再补。
三个没堵上的口子
公告里点名的三个开放问题都挂着 gnats 问题单号,状态是"待并入下一个稳定分支":
- hdaudio(4).音频驱动的 ioctl 命令缺少访问权限检查(PR 60492),本地用户可能借此绕权限。这是默认内核就包含的组件,影响面最大,规避方法是手动删除
/dev/hdaudio*设备节点,代价是音频功能受限。 - ipfilter.分片重组过程中存在远程可触发的空指针解引用(PR 60484)。好消息是 IPF 不在任何发行版内核里默认启用。
- pf.同样在分片重组环节有 use-after-free(PR 60485)。pf 已经被标注为弃用状态,同样不进默认内核——NetBSD 自己默认用的防火墙是 NPF,ipfilter 和 pf 更像是历史遗留的可选项。
三个问题都计划在约两个月内发布的 11.1 里修复。借用一句老话,这叫亡羊补牢,未为晚也——羊已经跑了,栏杆现在开始修。
- 结论.三个问题里,hdaudio 影响面最广——它是默认开启的组件;ipfilter 和 pf 因为不在默认内核里,实际暴露面反而有限。
时隔一年八个月,拖延不是因为漏洞
容易被误读的一点是:11.0 拖到现在,并不是因为在等这三个安全问题修完。公告里说得很直白——真正拖时间的是等第三方组件出稳定版,以及发布流程本身的瓶颈。
NetBSD 的发布工程已经自动化到相当程度,但每个架构的哈希签名仍需要安全负责人手工签署,而整个流程的实际耗时,卡在给每个架构、每个文件做网络传输这种最笨的环节上——这是一个多架构操作系统躲不掉的代价。
PR编号不是CVE,严重性还没定论
公告开头那句"AI工具的出现让全网发现或疑似的安全问题数量暴增",听起来像是给"带病发布"找了个时代背景。这个判断本身没有独立数据支撑,只能算 NetBSD 团队自己的观察。
更需要留意的是另一件事:hdaudio、ipfilter、pf 这三个问题目前都只是 gnats 问题单,还不等于正式编号的 CVE。是否会被 CVE.org、NVD 收录,影响评级是高是低,眼下都看不清。hdaudio 那类问题也常常介于"驱动稳定性缺陷"和"安全漏洞"之间,不是每一条都够得上外界想象中"漏洞=CVE"的量级。
- 风险.三个问题的真实可利用性和影响范围没有第三方确认,想准确评估,得自己去问题跟踪系统和 CVE 数据库交叉核实,不能只看公告的文字描述。
三种BSD活法,以及普通用户该怎么办
三大自由 BSD 走的是三条不同的路。FreeBSD 偏向生产性能和 ZFS,OpenBSD 信奉"默认安全",支持周期短、逼着用户勤更新;NetBSD 的强项从来不是跑分,而是跨架构可移植性和对稀有硬件、嵌入式场景的覆盖。
在这个坐标系里,"带着已知问题公开发布"这件事,更像是 NetBSD 把发布哲学从"零缺陷才能出门"改成了"透明优先"。这不完全等同于 OpenBSD 式的安全至上,也不是 FreeBSD 式的性能优先,是一种以覆盖面和治理透明度为核心的第三条路。
好的治理不是没有窟窿,是把窟窿画在地图上。
对普通用户来说,选择其实很简明。用嵌入式设备、跑冷门架构、图的是 NetBSD 独有的可移植性,现在升级到 11.0、顺手做完 hdaudio 的手动规避就够用。真拿 ipfilter 或 pf 当防火墙用的人本就是少数,该做的是评估切到默认的 NPF。求稳、或者对这三个问题的实际风险还没底的,等两个月后的 11.1 也不吃亏——前提是这个"两个月"能兑现,这本身就是接下来最该盯的一个变量。