应通过内核配置、模块加载性、补丁包状态三层面交叉验证：先用uname -a和grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)确认是否启用AF_ALG AEAD；再用modprobe -n -v algif_aead检查模块可加载性；最后结合rpm -qa、/proc/cmdline及modinfo哈希值核验补丁是否真实安装并激活。
麒麟系统怎么检查系统当前是否存在未修复的CVE漏洞——不能只靠“有没有弹窗更新”来判断，必须进入内核配置、已加载模块、补丁包状态三个层面交叉验证，否则会漏掉像CVE-2026-31431这类默认启用但未被自动禁用的高危攻击面。
第一步：确认系统基础信息与漏洞影响范围
执行nkvers和uname -a，获取完整发行版标识与内核版本号。这一步是所有后续判断的前提，因为同一CVE在不同内核分支（如4.19 vs 5.15）的修复方式可能完全不同；若版本低于官方声明的受影响起始版本（例如CVE-2026-31431要求≥4.19），可直接跳过该漏洞检查。
运行grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)，观察输出结果。如果返回CONFIG_CRYPTO_USER_API_AEAD=y或=m，说明AF_ALG AEAD子系统已被编译进内核或作为模块存在，系统处于CVE-2026-31431漏洞影响范围内；若无输出或显示# CONFIG_CRYPTO_USER_API_AEAD is not set，则该漏洞路径不存在，无需进一步操作。
第二步：检查漏洞对应内核模块是否可加载
执行modprobe -n -v algif_aead。这条命令不实际加载模块，仅模拟加载流程并打印将执行的动作。如果输出为insmod /lib/modules/$(uname -r)/kernel/crypto/algif_aead.ko类路径，则证明模块文件存在且系统允许加载——这就是CVE-2026-31431的完整利用链起点。
若此前已配置模块拦截，输出应为install /bin/false。此时需继续验证该规则是否生效：ls /etc/modprobe.d/disable-algif-aead.conf必须存在，且内容为install algif_aead /bin/false。缺少这个文件或内容错误，拦截即失效。
第三步：核验补丁包是否真实安装并激活
方法一：查RPM包记录
运行rpm -qa | grep $(uname -r) | grep kernel，筛选出当前内核版本对应的全部kernel相关包。重点比对输出中是否有带-security-、-cve-或版本号明显高于原始版本（如原为4.19.90-52.22，新包为4.19.90-52.57）的包名。仅存在新包不代表已激活，必须结合下一步验证。
方法二：查启动项与当前运行内核
执行awk -F\' '/menuentry / {print $2}' /boot/grub2/grub.cfg | grep "Kylin"，列出所有GRUB菜单中的麒麟内核条目；再运行cat /proc/cmdline，确认当前运行内核的启动参数是否含initcall_blacklist=af_alg_init。没有该参数，即使装了新内核包，CVE-2026-31431仍可通过af_alg_init入口触发。
方法三：查模块文件指纹
运行modinfo -n algif_aead 2>/dev/null获取模块路径，再执行sha256sum $(modinfo -n algif_aead 2>/dev/null)。将输出哈希值与麒麟官网安全公告中提供的修复后模块哈希值比对。不一致说明模块未被替换，或被降级覆盖——这是内网离线升级时最常见的失败场景。
