[BUG] BeeGFS 7.4.4 Out-of-Bounds Read in Serialization_deserializeStrAlign4 (S→C)
From: ven0mfuzzer
Date: Thu Apr 02 2026 - 07:10:54 EST
BeeGFS 7.4.4 Out-of-Bounds Read in Serialization_deserializeStrAlign4 (S→C)
1. Vulnerability Title
BeeGFS 7.4.4 Client Kernel Module Out-of-Bounds Read in String Deserializer via Corrupted String Length Field
2. High-Level Overview
This report describes an out-of-bounds read vulnerability in the BeeGFS 7.4.4 client kernel module's serialization/deserialization layer. The `Serialization_deserializeStrAlign4()` function reads a string length value from a network buffer and uses it to calculate a read offset without sufficient bounds checking. When a MITM attacker corrupts the string length field in a BeeGFS response message (e.g., `OpenFileResp`), the deserializer reads beyond the allocated buffer boundary, triggering a kernel page fault (Oops).
This bug was triggered approximately 40 times across multiple fuzzing sessions, confirming it is highly reproducible under MITM mutation.
In a non-KASAN kernel, this vulnerability could lead to information disclosure (reading adjacent kernel memory) or kernel crash (denial of service).
This vulnerability was discovered using ven0mfuzzer, our custom-designed MITM-based network filesystem fuzzer developed by our team.
Attack Model
The attack direction is Server → Client (S→C) via MITM:
An attacker with network access between a BeeGFS client and its servers intercepts BeeGFS TCP traffic and corrupts the string length field in response messages (e.g., `fileHandleID` length in `OpenFileResp`, or `responseFlags` causing misaligned field parsing in `LookupIntentResp`). The client kernel module's deserializer reads past the buffer boundary.
3. Affected Product and Version Information
Product: BeeGFS 7.4.4 (client kernel module, compiled from DKMS source)
Affected Component: `client_module/source/common/toolkit/Serialization.c` — `Serialization_deserializeStrAlign4()`
Supporting Components:
- `OpenFileRespMsg_deserializePayload()` — deserializes file open responses
- `LookupIntentRespMsg_deserializePayload()` — deserializes lookup responses
- `__NetMessageFactory_deserializeRaw()` — generic message deserialization
Server Components: BeeGFS 7.4.4 official packages (beegfs-mgmtd, beegfs-meta, beegfs-storage)
Tested Versions (confirmed vulnerable)
- BeeGFS 7.4.4 client DKMS module on Linux kernel 6.19.0 (commit `44331bd6a610`, gcc 11.4.0)
- Kernel built with KASAN enabled
Affected Distributions and Products
| Vendor / Product | Notes |
| --- | --- |
| HPC clusters using BeeGFS | Primary user base; BeeGFS is widely deployed in research and enterprise HPC storage |
| Any Linux distribution with BeeGFS 7.4.4 DKMS | BeeGFS is a third-party kernel module (not in mainline Linux). Affects any distro where BeeGFS 7.4.4 DKMS module is installed. |
| ThinkParQ official packages | Official BeeGFS packages from thinkparq.com |
4. Root Cause Analysis
4.a. Detailed Description
`Serialization_deserializeStrAlign4()` is a core BeeGFS deserialization function that reads variable-length strings from network message buffers. The function:
1. Reads a 4-byte length field from the buffer
2. Uses this length to calculate the offset of the string data
3. Returns a pointer to the string within the buffer
The vulnerability is that the function does not adequately validate the length field against the remaining buffer size. When a MITM attacker corrupts the length field to a value larger than the actual buffer, the function calculates an offset that extends beyond the allocated buffer. Subsequent access to the "string" data reads from unmapped KASAN shadow memory (or adjacent kernel memory on a non-KASAN kernel), triggering a page fault.
The bug affects all response messages containing serialized strings, including but not limited to `OpenFileResp`, `LookupIntentResp`, and any message passing file handle IDs, path strings, or metadata strings.
4.b. Code Flow
---
[VFS operation, e.g., open()]
FhgfsOpsRemoting_openfile+0x472/0xfd0 [beegfs]
__MessagingTk_requestResponseWithRRArgsComm+0xd90/0x1b60 [beegfs]
NetMessageFactory_createFromBuf+0xff/0x160 [beegfs]
__NetMessageFactory_deserializeRaw+0x1c1/0x350 [beegfs]
OpenFileRespMsg_deserializePayload+0x116/0x2e0 [beegfs]
Serialization_deserializeStrAlign4+0x160/0x2a0 [beegfs]
← reads length field (corrupted by MITM to large value)
← calculates offset: buf_ptr + corrupted_length
← accesses memory beyond buffer boundary
→ PAGE FAULT on unmapped address
---
4.c. Crash Trace
This vulnerability was discovered by ven0mfuzzer. The following kernel trace is submitted following syzkaller's common practice of providing the raw crash trace as the primary reproduction evidence:
---
BUG: unable to handle page fault for address: fffff5202064ba05
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
Oops: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:Serialization_deserializeStrAlign4+0x160/0x2a0 [beegfs]
Call Trace:
<TASK>
OpenFileRespMsg_deserializePayload+0x116/0x2e0 [beegfs]
__NetMessageFactory_deserializeRaw+0x1c1/0x350 [beegfs]
NetMessageFactory_createFromBuf+0xff/0x160 [beegfs]
__MessagingTk_requestResponseWithRRArgsComm+0xd90/0x1b60 [beegfs]
FhgfsOpsRemoting_openfile+0x472/0xfd0 [beegfs]
</TASK>
---
Key observations:
- Faulting address: `fffff5202064ba05` — KASAN shadow memory region (beyond allocated buffer)
- Access type: Supervisor read in kernel mode
- Faulting instruction: `Serialization_deserializeStrAlign4+0x160` — the string data access
- Trigger: MITM corruption of string length field in `OpenFileResp`
- ~40 instances reproduced across multiple fuzzing sessions
- Affected messages: OpenFileResp, LookupIntentResp, and any response containing serialized strings
4.d. Suggested Fix
Add bounds checking to `Serialization_deserializeStrAlign4()` to validate the string length against the remaining buffer size:
---
bool Serialization_deserializeStrAlign4(const char buf, size_t* bufLen,
unsigned outLen, const char* outStr)
{
unsigned strLen;
/ read length field /
if (*bufLen < sizeof(unsigned))
return false;
strLen = (unsigned)(*buf);
+ / Validate string length against remaining buffer /
+ unsigned alignedLen = BEEGFS_ALIGN(strLen + 1, 4);
+ if (alignedLen > *bufLen - sizeof(unsigned))
+ return false;
*outLen = strLen;
outStr = buf + sizeof(unsigned);
*buf += sizeof(unsigned) + alignedLen;
*bufLen -= sizeof(unsigned) + alignedLen;
return true;
}
---
This fix ensures the deserializer never reads beyond the buffer boundary, regardless of the length value received from the network.
5. Discovery Method and Reproduction
5.a. Discovery
This vulnerability was discovered using ven0mfuzzer, a custom-designed MITM-based network filesystem fuzzer developed by our team. The fuzzer operates by positioning an AF_PACKET/TCP transparent proxy between a Linux kernel filesystem client (VM-A) and its server (VM-B), then mutating network protocol messages in-flight. We designed ven0mfuzzer specifically for this class of network filesystem vulnerabilities.
The bug was found during Phase 1 (structural mutation), where the fuzzer corrupts message structure fields including string length fields.
Following the common syzkaller practice, we submit the kernel crash trace as the primary reproduction artifact.
5.b. Reproduction Setup
---
VM-A (BeeGFS client) ──BeeGFS──► Host (MITM proxy) ──TCP──► VM-B (BeeGFS servers)
---
Trigger condition: MITM corrupts the string length field in any BeeGFS response message containing serialized strings (e.g., `fileHandleID` in `OpenFileResp`).
Reproduction steps:
1. Build kernel 6.19.0 (commit `44331bd6a610`) with KASAN enabled
2. Install BeeGFS 7.4.4 client DKMS module
3. Start BeeGFS servers (beegfs-mgmtd, beegfs-meta, beegfs-storage) on VM-B
4. Start MITM proxy on host, configured to corrupt string length fields in BeeGFS response packets
5. Mount BeeGFS filesystem in VM-A through the MITM proxy
6. Execute filesystem operations (open, read, stat) on mounted files
---
Reported-by: ven0mfuzzer <ven0mkernelfuzzer@xxxxxxxxx>
Link: https://github.com/KernelStackFuzz/KernelStackFuzz