Valkey on Quanye's Blog

RESP3 push frame torn apart when a pubsub message >= 16384 bytes is delivered to the publishing connection (9.0 regression)

quanyemostima@gmail.com (杨全烨) — Wed, 22 Jul 2026 11:55:36 +0800

binbin第一次直接assign给我的issue,我来尝试处理一下并且学习一下这里的代码。

原issue界面:https://github.com/valkey-io/valkey/issues/4231

1. 这个 bug 发生在什么业务场景
#

一条 TCP 连接同时干两件事：

防止同步重入解UAF类问题

quanyemostima@gmail.com (杨全烨) — Tue, 21 Jul 2026 15:43:38 +0800

迄今为止我们看到好几个这样的段错误问题了。

这个PR,为单线程释放造成的UAF https://github.com/valkey-io/valkey/pull/4212 同时还有多线程下RDMA的崩溃问题 以及 Valkey Over RDMA测试中server UAF崩溃的问题 中我们都遇到类似的问题，于是尝试从架构上来解决一下这个问题.

举一隅不以三隅反，则不复也。

Broader direction (non-blocking): Part of the root cause is that many flows free clients synchronously (CLIENT KILL, evictClients(), COB-limit handling, …), and we keep tripping over iterators/cached pointers that outlive those frees. This snapshot fix is a good local solution, but it may be worth a broader discussion on whether these paths should prefer freeClientAsync() so client teardown always happens at a safe point (beforeSleep) rather than mid-iteration. Raising it here since it’s a recurring class of bug, not to block this PR.

UAF类-多BLPOP场景

quanyemostima@gmail.com (杨全烨) — Tue, 21 Jul 2026 11:15:35 +0800

1. BLPOP 是干什么的？
#

普通 LPOP mylist：list 空就立刻回 (nil)。

RDB_OPCODE_SLOT_IMPORT short job_name causes server-side heap out-of-bounds read during startup RDB loading

quanyemostima@gmail.com (杨全烨) — Sun, 19 Jul 2026 12:33:27 +0800

https://github.com/valkey-io/valkey/issues/4207 一类安全性问题，上面是issue界面，可以尝试解决一下。

典型的 trust-boundary 长度契约不一致——命令路径强制 job_name 必须是 40 字节， RDB 加载路径却没校验，导致 memcpy(..., 40) 从短 SDS 上越界读。

漏洞本质（从内存布局看）
#

子系统约定
#

CLUSTER_NAMELEN == 40，job name 是固定长度 hex（类似 node id）：

Client Side Caching-服务端反向索引在客户端断开之后没有做及时清理导致无限膨胀的问题

quanyemostima@gmail.com (杨全烨) — Wed, 15 Jul 2026 22:08:11 +0800

Issue #4143 的核心是：Client Side Caching（CSC）的服务端反向索引在客户端断开后故意不做即时清理，导致内层表可无限膨胀。下面按机制 → 内存布局 → 生命周期 → 缺口 来拆。

这个非常像Thesis-ZooKeeper中的客户端和server的watch机制。

问题背景
#

功能背景：Client Side Caching
#

CLIENT TRACKING on 让客户端在本地缓存 key。服务端不维护「客户端有哪些 key」的完整正向索引，而是维护反向索引：

Valkey Over RDMA测试中server UAF崩溃的问题

quanyemostima@gmail.com (杨全烨) — Tue, 14 Jul 2026 21:46:50 +0800

https://github.com/valkey-io/valkey/issues/3345

我们遇到的主要现象就是ctrl + C的时候会出现段错误，应该如何解决？

这是我们的PR:

https://github.com/valkey-io/valkey/pull/3448

为了面试的时候讲清楚这个UAF导致的Server Crash问题，我们需要仔细复盘一下，这个还是valkey Over RDMA的系列问题之一:

背景:RDMA为什么需要pending list
#

RDMA 连接没有 TCP 那种 POLLOUT 事件来驱动 write handler，所以 server 用一张待处理链表手动"叫醒"连接, 因为在真正开始传输数据的时候，我们使用的是RDMA的单边建立连接的方法， WRITE_WITH_IMM,来产生通知，就是我知道什么时候可读，但是不知道什么时候可以写：

多线程下的RDMA的崩溃问题(无锁队列IO模型)

quanyemostima@gmail.com (杨全烨) — Tue, 14 Jul 2026 21:27:29 +0800

If it’s broken, I’ll fix it!

现在重新引入了一个有意思的问题（背景阐述）
#

描述: 本次问题解决的是RDMA的多线程导致的崩溃问题. 在我们解决这个问题的同时,实际上主分支正在重构I/O的模型,我们不知道新的I/O模型是否还会出现这样的问题. (之后再进行验证)

valkey Over RDMA技术原理

quanyemostima@gmail.com (杨全烨) — Mon, 13 Jul 2026 15:03:13 +0800

2.RDMA基本概念

究竟是如何进行通信的?

TCP是流式协议(就是字节流),但是RDMA是面向消息(就是element)通信的.

放弃用双边操作（SEND/RECV）来传输业务数据，而是用双边操作来“交换信令”，用单边操作（WRITE）来“传输数据”。

[Valkey Client]                                               [Valkey Server (Listen RDMA Port)]
      |                                                                       |
      | ======================== 1. 建立 RDMA 连接 =========================>  |
      | <=======================    (RC QP 初始化)   ========================  |
      |                                                                       |
      | ================== 2. 交换 Feature 支持 [@IBV_WR_SEND] =============>  |
      | <================= 3. 交换 Feature 支持 [@IBV_WR_SEND] ==============  |
      |                                                                       |
      |                     [阶段 A：初始化远端内存写入权限] 这里都是双边操作        |
      | <---- 4. Server 发送其 RX Buffer 的地址/长度/R_Key [@IBV_WR_SEND] ---   | (Server 执行 ibv_post_recv 准备接收命令)
      | ---- 5. Client 发送其 RX Buffer 的地址/长度/R_Key [@IBV_WR_SEND] --->   | (Client 执行 ibv_post_recv 准备接收响应) 两边都通过send来发送R_key和内存地址,两边收到之后都可以绕过CPU直接进行读写的操作.
      |                                                                       |
      |                     [阶段 B：使用 WRITE 进行命令与数据交互]           |
      | --- 6. Valkey Command (如 PING) [@IBV_WR_RDMA_WRITE_WITH_IMM] ------> | (直接写入 Server 内存，触发 IMM 通知 Server CPU)
      | <--- 7. Valkey Response (如 PONG) [@IBV_WR_RDMA_WRITE_WITH_IMM] ----- | (直接写入 Client 内存，触发 IMM 通知 Client CPU)
      | --- 8. Valkey Command (如 SET) [@IBV_WR_RDMA_WRITE_WITH_IMM] -------> |
      | <--- 9. Valkey Response (如 OK) [@IBV_WR_RDMA_WRITE_WITH_IMM] ------- |
      |                                                                       |
      |                     [阶段 C：处理缓冲区写满 (RX is full)]             |
      | (假设 Client 发现 Server 之前给的 RX Buffer 空间不足了)               |
      |                                                                       |
      | <--- 10. Server 重新注册内存并发送新 RX Buffer 信息 [@IBV_WR_SEND] -- | (Server 发现自己消费完了，主动发新 Buffer，并 ibv_post_recv)
      | --- 11. Valkey Command (恢复发送) [@IBV_WR_RDMA_WRITE_WITH_IMM] ----> |
      |                                                                       |
      | (假设 Server 发现 Client 的 RX Buffer 不足了)                         |
      | ---- 12. Client 重新注册内存并发送新 RX Buffer 信息 [@IBV_WR_SEND]-> | (Client 主动发新 Buffer，并 ibv_post_recv)
      | <--- 13. Valkey Response (恢复发送) [@IBV_WR_RDMA_WRITE_WITH_IMM] --- |
      |                                                                       |
      | ======================== 14. 断开 RDMA 连接 ========================> |

1.什么是IMM消息通知?

Raft Cluster valkey-cli Tooling Compatibility

quanyemostima@gmail.com (杨全烨) — Mon, 13 Jul 2026 14:53:53 +0800

也是非常有趣的话题，最近valkey引入了Raft算法。

这个 PR 解决的是：Raft 集群里，服务端对拓扑变更命令的执行模型变了，但 valkey-cli --cluster fix 还在用旧的 gossip 事务模型发命令，两者不兼容。

https://github.com/valkey-io/valkey/issues/3856 可以来学习一下。

start
#

首先切换的最新的上游分支：

Raft Cluster Support For Non-Voting Memebers

quanyemostima@gmail.com (杨全烨) — Sun, 12 Jul 2026 23:44:47 +0800

也是Raft中一个很有意思的话题，我们来实现一个新的角色：Learner. 那这个实现的排期还挺紧迫的,这个毫无疑问也是比预选举协议更具有挑战性。

原issue

关于Raft的架构可以在Raft Cluster Pre-Vote Protocol中复习，这是我们做的第一个Raft相关的PR.

刚好同时了解集群的原理:特性：Redis Cluster 集群

需求是这么写的：

Implement support for “Learner” or “Observer” non-voting roles in the Raft consensus group. 实现learner 或者 observer.（实际上就是learner）.

Raft Cluster Pre-Vote Protocol

quanyemostima@gmail.com (杨全烨) — Sun, 12 Jul 2026 23:06:26 +0800

本文章写于cluster bus 可插拔raft协议改造的早期，此时还未成形，只是笔者学习的一个记录而已,因为笔者在尝试在 redis 的 cluster V2中实现Raft的预选举协议。已经merge,我们还可以进行一些复盘。

原issue界面这是valkey尝试实现可插拔的Raft协议中的预选举问题，这也算是一个有趣的工程实现。这里我们还是需要首先研究：Diego Ongaro博士毕业论文原文中的9.6节摘录： Preventing disruptions when a server rejoins the cluster One downside of Raft’s leader election algorithm is that a server that has been partitioned from the cluster is likely to cause a disruption when it regains connectivity. When a server is partitioned, it will not receive heartbeats. It will soon increment its term to start an election, although it won’t be able to collect enough votes to become leader. When the server regains connectivity sometime later, its larger term number will propagate to the rest of the cluster (either through the server’s RequestVote requests or through its AppendEntries response). This will force the cluster leader to step down, and a new election will have to take place to select a new leader. Fortunately, such events are likely to be rare, and each will only cause one leader to step down. If desired, Raft’s basic leader election algorithm can be extended with an additional phase to prevent such disruptions, forming the Pre-Vote algorithm. In the Pre-Vote algorithm, a candidate only increments its term if it first learns from a majority of the cluster that they would be willing to grant the candidate their votes (if the candidate’s log is sufficiently up-to-date, and the voters have not received heartbeats from a valid leader for at least a baseline election timeout). This was inspired by ZooKeeper’s algorithm, in which a server must receive a majority of votes before it calculates a new epoch and sends NewEpoch messages (however, in ZooKeeper servers do not solicit votes, other servers offer them). The Pre-Vote algorithm solves the issue of a partitioned server disrupting the cluster when it rejoins. While a server is partitioned, it won’t be able to increment its term, since it can’t receive permission from a majority of the cluster. Then, when it rejoins the cluster, it still won’t be able to increment its term, since the other servers will have been receiving regular heartbeats from the leader. Once the server receives a heartbeat from the leader itself, it will return to the follower state (in the same term). We recommend the Pre-Vote extension in deployments that would benefit from additional robustness. We also tested it in various leader election scenarios in AvailSim, and it does not appear to significantly harm election performance. 以下是翻译：

事件通知是怎么产生的？

quanyemostima@gmail.com (杨全烨) — Thu, 09 Jul 2026 15:50:02 +0800

看看一个RDMA的上下文：

typedef struct RdmaContext {

    connection * conn; // 上层连接结构体
    char * ip;
    int port;
    long long keepalive_te; /* RDMA has no transport layer keepalive */
    struct ibv_pd * pd; // 保护域
    struct rdma_event_channel * cm_channel;
    struct ibv_comp_channel * comp_channel; // CQ的通知事件，用来触发POLLIN事件
    struct ibv_cq * cq;

    /* TX */
    RdmaXfer tx;
    char * tx_addr; /* remote transfer buffer address */
    uint32_t tx_key; /* remote transfer buffer key */
    uint32_t tx_length; /* remote transfer buffer length */
    uint32_t tx_offset; /* remote transfer buffer offset */
    uint32_t tx_ops; /* operations on remote transfer */

    /* RX */
    RdmaXfer rx;

    /* CMD 0 ~ VALKEY_RDMA_MAX_WQE for recv buffer
     * VALKEY_RDMA_MAX_WQE ~ 2 * VALKEY_RDMA_MAX_WQE -1 for send buffer */
    ValkeyRdmaCmd * cmd_buf;
    struct ibv_mr * cmd_mr;

}
RdmaContext;

实现RDMA库的运行时动态加载(对于client和benchmark)

quanyemostima@gmail.com (杨全烨) — Mon, 06 Jul 2026 16:56:17 +0800

两个PR： valkey主库修改 libvalkey上游我们主要讲述这个在client和benchmark上做RDMA的两个库的动态加载这两个问题,两个库librdmacm libibverbs

之后最好再阅读一下CSAPP关于动态链接的部分，之后还预计出一篇文章好好讲解一下程序的链接，也是一门大学问。这个真的值得深挖。

背景
#

最早是字节跳动在进行valkey Over RDMA的开发, 但是只做了对于server的解耦, 但是没有对于client和benchmark的解耦, 这就导致了Opensuse,linux的发行版引来了这样的问题:

valkey32bit构建下头文件顺序问题

quanyemostima@gmail.com (杨全烨) — Sun, 05 Jul 2026 19:28:49 +0800

这个PR非常有纪念意义，这是我们给Valkey提出的第一个PR。

同时关于静态链接的内容，都可以在CSAPPLinkLab中进行学习。

PR页面

代码层面就是加了很多../fmacros.h并且server之前加上了一个验证。

/*
 * Sanity check: we require large-file support. If include order caused
 * _FILE_OFFSET_BITS to be ignored, off_t may end up 32-bit on 32-bit builds,
 * which will lead to ODR/LTO type mismatches. Fail fast at compile time.
 */
#include <sys/types.h>
static_assert(sizeof(off_t) >= 8, "off_t must be 64-bit; ensure _FILE_OFFSET_BITS=64 is in effect before system headers");
// 到这里为止所有的off_t偏移的定义都应该是8

第一部分：核心概念深度解析
#

1. 什么是 ABI (Application Binary Interface)？
#

CSAPP 对应章节：第 3 章（机器级代码），但概念贯穿全书。

valkey-benchmark端RDMA协议的丢失唤醒问题

quanyemostima@gmail.com (杨全烨) — Sun, 05 Jul 2026 19:24:12 +0800

https://github.com/valkey-io/valkey/issues/3345#issuecomment-4084382404

用户使用benchmark客户端GET有问题?初步分析就是丢失唤醒的问题.

删除代码比加上代码牛逼.

git清理
#

 git clean # 清理未跟踪的文件

git clean -nd src/unit

Raft-based cluster bus (Cluster V2)

quanyemostima@gmail.com (杨全烨) — Thu, 02 Jul 2026 23:24:33 +0800

最近，valkey社区在尝试新的feature,Cluster总线通信方式利用Raft协议，笔者刚学完Raft和主从相关的内容，同时认领了一个issue。于是想尝试多解决几个这里的问题，就深度研究一下。

以下是几个社区中讨论的链接：父issue 分为多个subissues：我们总结一下：

1.核心底座：Raft 共识与状态机持久化
#

这是 Raft 算法最原教旨主义的部分，确保集群在断电或崩溃后不丢失状态。

Valkey Over RDMA-支持多线程测试(新测试框架)

quanyemostima@gmail.com (杨全烨) — Mon, 29 Jun 2026 17:13:42 +0800

我就直接认为这是一个新的feature了，就是利用libvalkey的client客户端进行模拟的压测，同时是需要支持多线程的。

本次修改的测试逻辑
#

这算是一个新的feature,我们需要提一个新的PR来解决问题。

在tests/rdma的目录下方，增加libvalkey-test.c，直接使用libvalkey的client相关的API来进行测试即可。

CVE-2026-25243 Invalid Memory Access in Redis RESTORE Command May Lead to Remote Code Execution

quanyemostima@gmail.com (杨全烨) — Wed, 27 May 2026 23:17:00 +0800

CVE-2026-25243 — Invalid Memory Access in Redis RESTORE Command May Lead to Remote Code Execution
#

该漏洞的触发点位于 Redis 的 RESTORE 命令。

CVE-2026-27623 Pre-Authentication DOS from malformed RESP request

quanyemostima@gmail.com (杨全烨) — Tue, 26 May 2026 23:06:59 +0800

CVE-2026-27623 — Pre-Authentication DOS from malformed RESP request
#

Valkey 预认证拒绝服务 | RESP 协议状态机 | CVSS 3.1: 7.5 HIGH | CWE-20 | 无需认证 | 复现步骤

多线程下RDMA的崩溃问题

quanyemostima@gmail.com (杨全烨) — Sun, 17 May 2026 10:48:06 +0800

本文记录了作者尝试解决这个[CRASH] Does Valkey over RDMA not support I/O threads? #3112 的问题.

https://github.com/valkey-io/valkey/issues/3112

总结一次实验的workflow,这是拉的战线最长的一次,前前后后整了一个多月还没merge进去.

server端

# 解开当前进程的内存锁
sudo prlimit --memlock=unlimited --pid $$
# 创建在内存中工作的虚拟网卡
sudo modprobe dummy
sudo ip link add dummy0 type dummy
sudo ip link set dummy0 up
# 配置本地的IP
sudo ip addr add 10.0.0.1/24 dev dummy0
# 做RXE的绑定
sudo rdma link add rxe_dummy type rxe netdev dummy0
# 停止本来运行的 valkey
sudo systemctl stop valkey
# 编译一遍
make BUILD_RDMA=yes USE_FAST_FLOAT=yes
# 跑server
sudo ./src/valkey-server valkey.conf --rdma-bind 10.0.0.1 --rdma-port 6379

client端

为什么多线程会出现问题的总结

quanyemostima@gmail.com (杨全烨) — Fri, 15 May 2026 22:11:18 +0800

多线程下RDMA的崩溃问题 多线程下的RDMA的崩溃问题(无锁队列IO模型) 上述的两个问题都和RDMA通知模型相关. 对 socket/unix，ConnectionType 里 update_state 为 NULL，connUpdateState 基本是空操作。对 RDMA，updateRdmaState 会直接调用数据面：

static void updateRdmaState(struct connection *conn) {
	rdma_connection *rdma_conn = (rdma_connection *)conn;
	connRdmaSetRwHandler(conn);
	connRdmaEventHandler(NULL, -1, rdma_conn, 0);
}

而 connRdmaEventHandler 会 poll CQ，并在未 postpone 时循环调用 read_handler（把已 DMA 到 rx.addr 的数据交给上层）：

多线程下RDB文件crash

quanyemostima@gmail.com (杨全烨) — Fri, 15 May 2026 22:10:35 +0800

这个应该就是多线程的情况下才会发生的问题,之后再看. 这是我个人在做测试的时候发现valkey的一个新的问题,可以先试试 workflow可以这样: 首先在unstable上进行编译,先起一个服务器,但是不要更改valkey.conf,之后压测的时候应该默认会产生对应的RDB文件才对. 我们就在主线程上做测试看看是否会出现问题.

# 解开当前进程的内存锁
sudo prlimit --memlock=unlimited --pid $$
# 创建在内存中工作的虚拟网卡
sudo modprobe dummy
sudo ip link add dummy0 type dummy
sudo ip link set dummy0 up
# 配置本地的IP
sudo ip addr add 10.0.0.1/24 dev dummy0
# 做RXE的绑定
sudo rdma link add rxe_dummy type rxe netdev dummy0
# 停止本来运行的 valkey
sudo systemctl stop valkey
# 编译一遍
make BUILD_RDMA=yes USE_FAST_FLOAT=yes
# 跑server
sudo ./src/valkey-server valkey.conf --rdma-bind 10.0.0.1 --rdma-port 6379

之后我们起客户端做压测: