CVE-2026-68478

memstick: ms_block: reject a card that reports too many blocks

N/A
Published: August 15, 2026 at 05:51 AM UTC
Updated: August 17, 2026 at 06:17 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

3.12 ≤ v < 5.10.2613.12 ≤ v < 5.15.2123.12 ≤ v < 6.1.1783.12 ≤ v < 6.12.973.12 ≤ v < 6.18.403.12 ≤ v < 6.6.1453.12 ≤ v < 7.1.53.12 ≤ v < 7.20ab30494bc4f3bc1ea4659b7c5d97c5218554a633.12
Vendor states this is fixed in 39151f0708c84221e94cdd6aa070aba5d7cb1c01 (fixed)
Vendor states this is fixed in 47f0c7d856c67c9935546d2644f18c0d0131b449 (fixed)
Vendor states this is fixed in 718178f524b98bc920d74bc771aed823c8b81425 (fixed)
Vendor states this is fixed in 8937b11f1c3896e066c3fb07387ba17bc8c50b8a (fixed)
Vendor states this is fixed in a4b9961efe8640f50800811b4a2b2046b3dc2ccc (fixed)
Vendor states this is fixed in b86666ac4009a252501cc17242582a7ec9ed976e (fixed)
Vendor states this is fixed in d5db3439ee8d1c165a09a47e984c4ba508c130df (fixed)
Vendor states this is fixed in f1c675ecf6e5ad02722f0019f729d8bb588d502e (fixed)
Vendor states this is fixed in 3.12 (unaffected)
Vendor states this is fixed in 5.10.261 (unaffected)
Vendor states this is fixed in 5.15.212 (unaffected)
Vendor states this is fixed in 6.1.178 (unaffected)
Vendor states this is fixed in 6.12.97 (unaffected)
Vendor states this is fixed in 6.18.40 (unaffected)
Vendor states this is fixed in 6.6.145 (unaffected)
Vendor states this is fixed in 7.1.5 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card