CVE-2026-68478 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
memstick: ms_block: reject a card that reports too many blocks
msb_ftl_initialize() computes the zone count from the card block count with no bound:
msb->zone_count = msb->block_count / MS_BLOCKS_IN_ZONE; ... for (i = 0; i < msb->zone_count; i++) msb->free_block_count[i] = MS_BLOCKS_IN_ZONE;
msb->block_count is a card value. msb_read_boot_blocks() reads number_of_blocks from the card boot page and byte swaps it. free_block_count is a fixed int[MS_MAX_ZONES]. MS_MAX_ZONES is 16, so the
valid indices are 0 to 15. The init loop above indexes it by zone_count. msb_mark_block_used() and msb_mark_block_unused() index it by pba / MS_BLOCKS_IN_ZONE, for pba up to block_count - 1. A card may report up to 65535 blocks. A block_count above 8192 (MS_MAX_ZONES * MS_BLOCKS_IN_ZONE) lets the pba index reach 16. That writes past free_block_count[] and corrupts struct msb_data. A larger count runs the
init loop past the end too.
A real Memory Stick has at most 16 zones. So it has at most 8192 blocks. msb_ftl_initialize() now rejects a card that reports more than MS_MAX_ZONES * MS_BLOCKS_IN_ZONE blocks.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability in the Linux kernel's memstick subsystem represents a critical buffer overflow condition within the ms_block driver component that arises from inadequate input validation during device initialization. This flaw exists in the msb_ftl_initialize() function where the system computes zone count directly from card-reported block counts without implementing proper bounds checking mechanisms. The technical implementation demonstrates a classic case of improper boundary validation where the block_count value derived from the Memory Stick's boot page is used directly to determine array indexing parameters.
The core technical flaw stems from the absence of input sanitization between the card-reported block count and the internal data structure allocation. When msb_read_boot_blocks() extracts number_of_blocks from the card's boot page, it performs byte swapping but fails to validate whether this value remains within acceptable operational limits. The system assumes that any valid block count will produce a reasonable zone count that fits within the predefined MS_MAX_ZONES constant of 16, yet cards may report values as high as 65535 blocks. This discrepancy creates a direct path for memory corruption through out-of-bounds array access.
The operational impact of this vulnerability extends beyond simple buffer overflow conditions to potentially compromise system stability and security integrity. When a Memory Stick reports more than 8192 blocks, which exceeds the maximum zone capacity of 16 zones with 512 blocks per zone, the initialization loop attempts to write beyond the allocated free_block_count array boundaries. This memory corruption affects the msb_data structure itself, potentially allowing attackers to manipulate critical driver state information and create persistent security weaknesses within the system's storage subsystem. The vulnerability is particularly concerning because it occurs during device enumeration when the kernel initializes device drivers.
The mitigation strategy implemented addresses the root cause by introducing explicit bounds checking that rejects Memory Stick devices reporting excessive block counts beyond the maximum supported zone capacity. This approach aligns with established security practices for preventing buffer overflow vulnerabilities and follows principles similar to those outlined in CWE-129, which addresses insufficient bound checking in array indexing operations. The solution effectively prevents the initialization process from proceeding with malformed device parameters that would otherwise lead to memory corruption.
From an ATT&CK framework perspective, this vulnerability could enable privilege escalation techniques through kernel memory corruption, potentially allowing adversaries to execute arbitrary code with system-level privileges. The mitigation approach directly addresses potential exploitation vectors by preventing the vulnerable code path from executing with malicious input data. This remediation follows industry best practices for device driver security and demonstrates proper validation of external inputs as recommended in secure coding standards. The fix ensures that all Memory Stick devices are properly validated against maximum supported capacity limits, preventing both accidental corruption and intentional exploitation attempts that could leverage this buffer overflow condition to gain unauthorized system access.