docker runc 文件描述符泄漏导致容器逃逸漏洞（CVE-2024-21626）

这篇博客首先要指出的是正确runc的漏洞修复方式，另外就是说明当你重启docker时遇到了问题时应该如何正确的定位问题。

1. 首先正确的升级runc的方式如下
   runc升级
2. 当你重启docker失败时
   首先应该定位的地方是通过查看 /var/log/messages,定位到具体导致docker启动失败的原因。
   举例

Mar  7 20:29:32 iZvy201jk9svcjndkz0cyzZ dockerd[1071123]: time="2024-03-07T20:29:32.989464320+08:00" level=warning msg="grpc: addrConn.createTransport failed to connect to {unix:///var/run/docker/containerd/containerd.sock  <nil> 0 <nil>}. Err :connection error: desc = \"transport: error while dialing: dial unix:///var/run/docker/containerd/containerd.sock: timeout\". Reconnecting..." module=grpc

定位到具体的docker异常信息，然后再去寻找解决方案，上面这个例子的解决方案是需要启动containerd, 在我的环境中启动脚本是/usr/bin/containerd，执行这个脚本containerd就启动了，docker也重启成功。
如果 docker 重启成功之后再启动容器，遇到以下报错，不用慌，不是docker坏了，你再尝试一下启动容器的命令，容器就成功启动了！

Error response from daemon: failed to create shim: OCI runtime create failed: runc create failed: container with given ID already exists: unknown
Error: failed to start containers: proxysql

切忌随便删除文件，有很多的博客给出了删除某些文件的操作之后docker能够重启成功，但是删除文件的操作可能会导致容器、镜像数据的丢失，如果执行这些操作之前没有进行文件备份，这将给我们带来不可逆的损失。

参考博客

docker启动逻辑
runc升级