Cloudanix VulnDB

CVE-2026-98884

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A configuration mistake in how the operating system talks to certain storage devices can make the whole computer crash during startup or when a card is inserted.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Unsigned short max_segs truncation to zero triggers kmalloc(0) returning ZERO_SIZE_PTR, causing sg_init_table to dereference invalid memory and panic the kernel during MMC queue initialization.

Why it matters to the business

Unexpected kernel crashes during storage device initialization can cause system downtime, failed boots, or loss of MMC/SD card functionality on affected Linux systems.

How an attack unfolds

An attacker supplies or loads a host driver that sets an excessively large max_segs value; during mmc_blk_alloc or mmc_rescan the truncated zero value reaches mmc_mq_init_request, producing the invalid allocation and page fault.

How to fix it

Apply the upstream patch that adds the sg_len zero-value check and error return in mmc_mq_init_request; rebuild and deploy the fixed kernel; audit custom host drivers to ensure max_segs is set to a valid non-zero value.

How to confirm the fix worked

Boot with the patched kernel and confirm absence of the sg_init_table paging fault; inspect dmesg for the new validation error message when an invalid driver is intentionally loaded; verify max_segs values in driver source remain within unsigned short range.

Typical attack path

  1. Load or configure a host driver that sets max_segs larger than unsigned short can hold
  2. Trigger MMC device enumeration or rescan
  3. mmc_mq_init_request derives zero sg_len and calls kmalloc(0)
  4. sg_init_table dereferences ZERO_SIZE_PTR and triggers kernel oops

How to detect it

Search kernel logs and crash dumps for call traces containing sg_init_table, mmc_mq_init_request, and mmc_blk_alloc_req; look for the specific paging fault address pattern and "Unable to handle kernel paging request" messages tied to MMC workqueues.

  • sg_init_table+0x2c/0x50
  • mmc_mq_init_request+0x64/0x90
  • Unable to handle kernel paging request at virtual address 0000001ffffffff0
  • Workqueue: events_freezable mmc_rescan

What your security team should do

  • Prioritize kernel update on all systems using MMC/SD controllers within the published remediation window
  • Review and constrain max_segs assignments in any out-of-tree host drivers
  • Add kernel oops monitoring for mmc and sg_init_table symbols to existing crash telemetry

The record

In the Linux kernel, the following vulnerability has been resolved: mmc: core: Add validation for host-provided max_segs The max_segs field is of type unsigned short, and if a host driver sets an excessively large value, it may be truncated to zero. This can cause mmc_alloc_sg() to call kmalloc_objs() with a zero size allocation request, which leads to undefined behavior. Under the SLUB allocator, kmalloc(0) returns a special pointer (ZERO_SIZE_PTR). The subsequent 'if (sg)' check will evaluate to true, and sg_init_table() will then attempt to access invalid memory, resulting in a crash: dwmmc_rockchip 2a310000.mmc: Successfully tuned phase to 133 mmc1: new UHS-I speed SDR104 SDHC card at address aaaa Unable to handle kernel paging request at virtual address 0000001ffffffff0 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000102c88000 [0000001ffffffff0] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 2 UID: 0 PID: 102 Comm: kworker/2:1 Not tainted 7.0.0-rc6-next-20260331-00013-g4d93c25963c5-dirty #80 PREEMPT Hardware name: Rockchip RK3576 EVB V10 Board (DT) Workqueue: events_freezable mmc_rescan pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : sg_init_table+0x2c/0x50 lr : sg_init_table+0x24/0x50 sp : ffff8000837db710 x29: ffff8000837db710 x28: 000000000000c000 x27: 0000000000000300 x26: 0000000000000000 x25: 0000000000000040 x24: ffff0000c46a0000 x23: 0000000000000000 x22: ffff0000c0c73c00 x21: 0000000000000010 x20: 0000000000000010 x19: 0000000000000000 x18: 000000000000002c x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 x14: 0000000000000400 x13: ffff8000837dc000 x12: 0000000000000000 x11: ffff0000c0c73ca0 x10: 0000000000000040 x9 : 459ec1f0abbdbb00 x8 : 0000001fffffffe0 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000035579 x4 : 0000000000000901 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000010 Call trace: sg_init_table+0x2c/0x50 (P) mmc_mq_init_request+0x64/0x90 blk_mq_alloc_map_and_rqs+0x3ac/0x480 blk_mq_alloc_set_map_and_rqs+0x98/0x1e0 blk_mq_alloc_tag_set+0x1c0/0x290 mmc_init_queue+0x120/0x370 mmc_blk_alloc_req+0x150/0x420 To prevent this, add a validation check in mmc_mq_init_request() to detect when sg_len (derived from max_segs) is zero. If sg_len is zero, we return an error and print an error message, allowing host driver developers to identify and fix incorrect max_segs configuration. This is a defensive measure that ensures the MMC core fails gracefully when host drivers provide invalid max_segs values, rather than crashing with a page fault.

Affected packages

Ecosystem Package Introduced Fixed