[Bug] 9PFS client trusts server-controlled stat/name lengths in getdents path, leading to out-of-bounds read

[XueDugu]

RT-Thread Version

master, verified on current worktree at commit 25295501c0cc7181d6a541a867fdf7214879ddf8

Hardware Type/Architectures

Any BSP using DFS v1 9PFS with an untrusted 9P transport/peer

Develop Toolchain

GCC

Describe the bug

Summary

A 9PFS client-side parsing vulnerability exists in RT-Thread DFS v1 9PFS.

RT-Thread's 9PFS client receives the actual reply size from the transport layer in p9_transaction(), but later parsing code such as dfs_9pfs_getdents() ignores that received size and instead trusts server-controlled fields embedded in the reply body, including count, stat_size, and name_len.

As a result, a malicious 9P server can return a short or malformed reply whose internal size fields cause the client to read beyond the received message buffer while parsing directory entries.

The most realistic impact is denial of service (crash / fault) in the 9PFS client. Depending on memory layout, the client may also copy out-of-bounds data into returned dirent entries and expose unintended memory contents to local callers.

---

Affected Components

• components/dfs/dfs_v1/filesystems/9pfs/dfs_9pfs.c
• components/dfs/dfs_v1/filesystems/9pfs/dfs_9pfs.h
• components/libc/compilers/common/include/dirent.h

---

Key Evidence

1. Actual reply length is discarded by callers

p9_transaction() receives the transport-reported reply length:

• components/dfs/dfs_v1/filesystems/9pfs/dfs_9pfs.c:179
• components/dfs/dfs_v1/filesystems/9pfs/dfs_9pfs.h:132

But callers such as dfs_9pfs_read() and dfs_9pfs_getdents() pass RT_NULL for out_rx_size, so the actual received length is discarded.

2. Field access helpers have no bounds checking

• components/dfs/dfs_v1/filesystems/9pfs/dfs_9pfs.c:48

get_rx_value16_of() / get_rx_value32_of() directly read from conn->rx_buffer[idx] by offset without any bounds validation.

3. dfs_9pfs_getdents() trusts server-controlled lengths

Relevant locations:

• components/dfs/dfs_v1/filesystems/9pfs/dfs_9pfs.c:815
• components/dfs/dfs_v1/filesystems/9pfs/dfs_9pfs.c:846
• components/dfs/dfs_v1/filesystems/9pfs/dfs_9pfs.c:854
• components/dfs/dfs_v1/filesystems/9pfs/dfs_9pfs.c:880
• components/dfs/dfs_v1/filesystems/9pfs/dfs_9pfs.c:882

The function uses:

ret = get_rx_value32_of(conn, P9_MSG_READ_COUNT);
stat_size = get_rx_value16_of(conn, off + P9_MSG_STAT_SIZE) + sizeof(rt_uint16_t);
dirp->d_namlen = get_rx_value16_of(conn, off + P9_MSG_STAT_NAME_LEN);
rt_strncpy(dirp->d_name, conn->rx_buffer + off + P9_MSG_STAT_NAME, dirp->d_namlen);

But it does not verify that:

• ret <= actual_rx_size - P9_MSG_READ_DATA
• off + P9_MSG_STAT_SIZE + 2 <= actual_rx_size
• stat_size <= remaining returned data
• off + P9_MSG_STAT_NAME + d_namlen <= actual_rx_size

4. getdents() is worse than read()

dfs_9pfs_read() is still problematic because it ignores the actual reply size, but got is at least constrained by got <= set, and set <= conn->msg_size - P9_MSG_READ_DATA.

dfs_9pfs_getdents() is worse because ret, stat_size, and name_len are all trusted and off keeps increasing based on unvalidated values.

5. Primary issue is source-buffer over-read, not a local dirent destination overflow

• components/libc/compilers/common/include/dirent.h:57

d_namlen is uint8_t and d_name is 256 bytes, so the more credible issue is reading past the received 9P reply buffer and then copying that data into the returned dirent.

---

Impact

If a system mounts an untrusted 9P peer, the peer can send malformed directory reply data that drives the client into out-of-bounds reads while parsing directory entries.

Practical impact:

• Client crash / fault / denial of service
• Undefined behavior during directory enumeration
• Possible copying of out-of-bounds data into returned dirent structures, which may leak unintended memory contents to local callers

---

Steps to Reproduce

A practical PoC requires a malicious or instrumented 9P server / transport peer.

1. Build RT-Thread with DFS v1 9PFS enabled.
2. Connect or mount a 9P peer that the attacker controls.
3. Trigger a directory listing on the mounted 9P filesystem so that dfs_9pfs_getdents() is used.
4. Return a malformed Rread reply where:
   • The actual received packet is short, but
   • P9_MSG_READ_COUNT is set larger than the real reply payload, and/or
   • The embedded stat record size field is inflated, and/or
   • name_len points beyond the actual received message body.
5. Observe that the RT-Thread client continues parsing using those server-controlled lengths and reads beyond the valid received reply data.

---

Expected Behavior

The 9PFS client should track the actual reply size returned by the transport and reject any response whose internal fields exceed that boundary.

In particular:

• dfs_9pfs_getdents() should reject replies if ret exceeds the actual received payload size
• Each parsed stat_size should be validated before advancing off
• Each name_len should be validated against the remaining received message length before reading or copying the name

---

Actual Behavior

The 9PFS client ignores the transport-reported reply length in this parsing path and trusts internal reply fields from the server to drive further buffer reads.

This allows a malicious 9P server to induce out-of-bounds reads during directory entry parsing, likely causing a crash or other denial-of-service condition.

---

Suggested Fix

The fix should make reply parsing length-aware and reject malformed replies early.

At minimum:

• Propagate and use the actual rx_size returned by p9_transaction() in all reply parsing paths
• Reject any Rread where P9_MSG_READ_COUNT exceeds rx_size - P9_MSG_READ_DATA
• In dfs_9pfs_getdents(), before each field access, validate that the corresponding offset is still within the actual received reply length
• Reject any record where:
  • stat_size is smaller than the fixed stat header
  • stat_size exceeds the remaining returned data
  • name_len extends past the received message boundary
• Stop using raw get_rx_valueXX_of() on unvalidated offsets for attacker-controlled message bodies

Kindly let me know if you intend to request a CVE ID upon confirmation of the vulnerability.

Other additional context

No response