[Bug] DFS partition probing accepts out-of-range MBR partition geometry and may forward out-of-bounds I/O to the parent block device

[XueDugu]

RT-Thread Version

master, verified on commit 2b58dec87b584aa7ded6e8c736498716f8d29cd0

Hardware Type/Architectures

Any BSP using block devices with DFS partition probing enabled

Develop Toolchain

GCC

Describe the bug

Summary

RT-Thread's DFS/MBR partition probing and logical block partition layer accept attacker-controlled partition geometry from the MBR without validating it against the real device capacity. As a result, a crafted external storage device or disk image can register a logical partition whose (offset, size) extends beyond the actual media boundary.

This is not just a partition-display inconsistency. Because the logical partition I/O path also performs insufficient boundary checks, later reads and writes through the forged logical partition may be translated into out-of-range parent-device I/O requests.

In practice, this is best classified as an external-media-triggered partition boundary validation vulnerability. The most likely impact is mount failure, I/O failure, or denial of service. If the lower-level block driver also fails to reject out-of-range LBAs, the impact may escalate to unintended reads or writes outside the real media boundary.

---

Affected Components

Component	File	Function / Area
DFS v2 MBR parsing	components/dfs/dfs_v2/src/dfs_fs.c:679	dfs_filesystem_get_partition()
DFS v1 MBR parsing	components/dfs/dfs_v1/src/dfs_fs.c:156	dfs_filesystem_get_partition()
DFS partition probing	components/drivers/block/partitions/dfs.c:18	dfs_partition()
Logical partition registration	components/drivers/block/blk_partition.c:27	blk_put_partition()
Logical partition I/O path	components/drivers/block/blk_dev.c:36	blk_dev_read() / blk_dev_write()
Automatic reachability	components/drivers/block/blk.c:334 and components/drivers/block/blk.c:426	Block registration / optional automatic mount path

---

Details

1. MBR partition geometry is accepted without capacity validation

In both DFS v1 and DFS v2, dfs_filesystem_get_partition() directly reads the partition offset and size from the MBR partition entry and returns them to the caller.

However, the parser does not reject cases such as:

• size == 0
• offset >= real_device_capacity
• size > real_device_capacity - offset

This means the partition layer can accept a forged partition entry that points partially or completely outside the physical media.

Relevant locations:

• components/dfs/dfs_v2/src/dfs_fs.c:679
• components/dfs/dfs_v1/src/dfs_fs.c:156

2. The unchecked geometry is registered as a logical partition

dfs_partition() passes the parsed values into blk_put_partition().

blk_put_partition() then registers the logical partition using the supplied start/count values without revalidating them against the real parent disk capacity.

Relevant locations:

• components/drivers/block/partitions/dfs.c:18
• components/drivers/block/blk_partition.c:27

At this point, RT-Thread has already created a logical partition object based on attacker-controlled out-of-range metadata.

3. The issue is reachable beyond partition enumeration

If the bug stopped at logical partition registration, it would mostly be a metadata robustness defect.

However, the logical block device read/write path in blk_dev.c also performs insufficient boundary checks. Based on the current code, it does not robustly enforce the full equivalent of:

• sector <= blk->sector_count
• sector_count <= blk->sector_count - sector

before translating the request into parent-device LBAs.

It also does not independently verify that the translated parent-device range still stays within the real media capacity.

Relevant location:

• components/drivers/block/blk_dev.c:36

As a result, an oversized or out-of-range logical partition created from a malicious MBR is not only visible to upper layers, but may also be used for later I/O attempts that go beyond the intended physical storage boundary.

4. Automatic trigger path exists

This issue is externally reachable because RT-Thread will automatically probe partitions during disk registration.

Relevant path:

• components/drivers/block/blk.c:334

With RT_USING_DFS_MNTTABLE enabled, the system may proceed toward automatic mount handling after partition discovery as well.

Relevant path:

• components/drivers/block/blk.c:426

So a crafted removable storage device or user-supplied disk image can trigger this path without any local code modification.

---

Why This Matters

This is not just "wrong partition size shown in logs".

A malicious MBR can create a logical partition whose geometry extends beyond the actual device. If application code, filesystem code, or mount logic later reads or writes near the end of that forged partition, RT-Thread may translate those requests into out-of-range parent-device LBAs.

The final impact depends on the lower block driver:

• If the lower driver correctly rejects out-of-range LBAs, the result will usually be failed I/O, mount failure, error spam, or denial of service.
• If the lower driver does not sufficiently validate translated LBAs, the result may become unintended reads or writes outside the intended partition and potentially outside the real media boundary.

So the bug should not be dismissed as a non-security issue. It is an externally triggerable partition boundary validation flaw with downstream impact determined partly by lower-layer driver robustness.

---

Steps to Reproduce

A full hardware PoC is not included here yet, but the trigger conditions are straightforward.

1. Build RT-Thread with DFS partition probing enabled on a target that accepts external block media.
2. Ensure the target performs normal partition probing when the block device is registered.
3. Prepare a crafted MBR sector with a non-empty partition entry whose geometry exceeds the actual media capacity. Example shape:
   • offset near the end of the disk
   • size large enough that offset + size exceeds the true number of sectors
4. Present the crafted media to the target through SD/MMC, USB-backed storage, or another block backend.
5. Let RT-Thread register the disk and probe partitions.
6. Observe that a logical partition is created from the forged entry.
7. Attempt to mount the partition or issue reads/writes through it, especially near the partition end.

A stronger trigger shape is to choose geometry such that the logical partition is accepted but any access near its tail necessarily translates beyond the real parent-device capacity.

---

Expected Behavior

RT-Thread should reject malformed or out-of-range MBR partition entries before registering a logical partition.

At minimum, it should reject:

• size == 0
• offset >= capacity
• size > capacity - offset

In addition, the logical partition I/O path should reject requests unless the full translated range remains inside the logical partition and, after translation, still remains inside the parent block device boundary.

---

Actual Behavior

RT-Thread accepts attacker-controlled MBR partition offset and size values without validating them against the real media capacity, registers a logical partition from them, and may later forward translated out-of-range I/O requests to the lower block driver.

This can lead to:

• Oversized invalid logical partitions
• Mount failure
• Out-of-range I/O attempts
• Denial of service
• Depending on the lower driver, possible unintended access to physical sectors outside the intended partition or outside the real media boundary

---

Impact

Vulnerability Type

Partition boundary validation flaw / out-of-range logical partition registration / potential out-of-bounds I/O propagation

Attack Precondition

Attacker controls the partition table on external or user-supplied storage media.

Most Realistic Impact

• Mount failure
• Read/write failure
• Denial of service
• Persistent error conditions due to malformed media

Potential Higher Impact

If the lower block layer fails to strictly reject out-of-range translated LBAs, this may result in unintended reads or writes to physical sectors outside the intended partition or beyond the actual storage boundary.

Who Is Impacted

• Products that mount or probe untrusted removable storage
• Systems that accept user-provided disk images
• Embedded devices that automatically probe or auto-mount external media

---

Suggested Fix

The issue should be fixed in both layers, not only in MBR parsing.

Partition Parsing / Registration Side

Before registering a logical partition, reject:

• size == 0
• offset >= capacity
• size > capacity - offset

This validation should happen before blk_put_partition() is called, and ideally also be enforced inside blk_put_partition() as a final defensive layer.

Logical Partition I/O Side

In blk_dev_read() / blk_dev_write(), enforce proper request bounds before translating to the parent device:

• Reject if sector > blk->sector_count
• Reject if sector_count > blk->sector_count - sector

And after translation, ensure the parent-device request still remains within the real parent capacity.

That way, even if malformed partition metadata slips through, later I/O will still be contained safely.

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

Other additional context

No response