oomd 风险怎么排查：先核对受影响版本与 socket 权限

如果 Linux 主机启用了 systemd-oomd，发现本地异常进程终止或正在做系统升级，先不要把现象归因于“内存不够”。systemd 官方安全公告 GHSA-652q-wxr6-h5j6 指出，受影响版本的本地非特权用户可能通过 Managed OOM 接口影响任意本地进程；排查重点是版本、服务是否启用，以及 ManagedOOM socket 是否仍允许非特权访问。

先把公告风险和普通 OOM 分开

排查systemd-oomd相关异常风险时，第一步不要直接改参数重启服务，先确认当前发行版搭载的systemd版本是否落在受影响范围内，再检查对应oom的ManagedOOM socket文件的权限配置，就能先过滤掉90%的误判场景，避免误操作影响业务正常运行。

普通 OOM 事件通常从内存压力、cgroup 限额或内核回收行为入手；这份公告描述的是一个权限边界问题：systemd-oomd 接收本地请求时，对路径的归属判断与后续路径解析不一致，可能让特权服务读取非预期的 cgroup 类文件并发送终止信号。文章只讨论防守核对，不在生产机复现漏洞。

公告列出的受影响范围是 systemd-oomd 大于等于 250，修复版本分别落在 261、260.3、259.7 和 258.9 分支。版本核对应以发行版打包版本和安全更新记录为准，不能只看系统发行版的大版本号。

第一步：确认组件和实际版本

在维护窗口中，先确认服务单元是否存在，再读取发行版包管理器记录的版本。不同发行版的包名和版本后缀不同，下面的命令只用于观察本机状态：

systemctl status systemd-oomd.service --no-pager
systemctl show systemd-oomd.service -p LoadState -p ActiveState -p SubState
systemd --version

如果服务不存在、处于未安装状态，不能据此断言整台机器安全；还要确认是否有其他 OOM 管理组件在工作。若服务存在，则把包版本交给发行版安全公告或更新仓库核对，重点是是否已经进入对应修复分支。

第二步：检查 ManagedOOM socket 的入口权限

公告点名的入口是 /run/systemd/oom/io.systemd.ManagedOOM。查看它是否存在、属于哪个用户组、对其他用户开放什么权限：

stat -c '%A %U %G %n' /run/systemd/oom/io.systemd.ManagedOOM
systemctl cat systemd-oomd.socket

这里要区分“文件不存在”和“文件权限收紧”两种状态：前者可能意味着服务未启用或 socket 尚未创建，后者才是明确的访问控制结果。公告给出的临时缓解方向是为 systemd-oomd.socket 添加 drop-in，把 SocketMode 收紧到 0600；变更前应确认发行版单元文件没有被本地策略覆盖。

修复动作怎么排优先级

首选发行版已经回补的 systemd 软件包，并在变更记录中保存升级前后的包版本。若补丁暂时不可用，可按维护窗口选择一种临时措施：

• 对 socket 使用 drop-in 限制非特权访问，重载单元后确认权限实际生效。
• 若业务不依赖 managed OOM，停用 systemd-oomd.service，并记录由谁接替内存压力处置。
• 不要直接编辑 /usr/lib 或 /lib 下的供应商单元文件，避免下一次包升级覆盖修复。

临时停用不是永久修复。它会改变主机在内存压力下的处置路径，容器节点、桌面会话和批处理主机的风险不同，必须把替代监控与回滚条件写进变更单。

变更后用三条证据闭环

修复后不只看命令返回成功，还要把版本、入口和服务三类信息放在一起：

1. 版本证据：包管理器显示的 systemd-oomd 版本已经进入发行版修复分支。
2. 入口证据：ManagedOOM socket 的属主、权限和 drop-in 与预期一致。
3. 状态证据：systemd-oomd 的 ActiveState、日志和业务关键进程状态符合维护窗口前的基线。

如果停用了服务，还要检查 cgroup v2 的压力观测和业务自身的内存告警是否仍在工作。cgroup v2 文档说明，资源压力文件按 cgroup 层级提供；它们可以支持观测，但不能替代本次漏洞修复的版本和权限核对。

常见问题

这个公告是不是所有 Linux 主机都受影响？

不是。需要同时确认 systemd-oomd 组件、实际版本、服务配置和本地访问条件；未安装该组件的主机不应套用相同结论。

把 socket 改成 0600 就等于完成修复吗？

不等于。它是公告给出的临时缓解方向，仍应升级到发行版提供的修复包，并验证 drop-in 没有破坏正常的 managed OOM 管理。

停用 systemd-oomd 会不会让内存问题消失？

不会。停用只改变处置组件；内存压力、cgroup 限额和业务自身的资源问题仍然存在，需要由替代监控和明确的恢复策略承接。

把版本、入口和回滚条件一起留档

这类 systemd 风险最容易被“服务正在运行”或“机器刚好没有 OOM”掩盖。先以官方公告确定组件和版本范围，再核对 ManagedOOM socket 的真实权限，最后验证修复包与服务状态，才能把一次安全更新变成可复查的 Linux 运维记录。