CVE-2026-98884 in Linux
Summary
by MITRE • 10/23/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel's Multimedia Card (MMC) subsystem contains a critical input validation flaw within its block queue initialization logic, specifically in the mmc_mq_init_request function. This vulnerability stems from an insufficient check on the host-provided max_segs field, which dictates the maximum number of scatter-gather segments allowed for I/O requests. The max_segs variable is defined as an unsigned short integer, a data type with a limited range that can lead to truncation issues if a host driver incorrectly configures it with excessively large values. When such an invalid value is processed through subsequent arithmetic operations or internal conversions within the kernel's memory management subsystem, it may result in a zero-length allocation request being passed to the SLUB allocator via kmalloc_objs(). This scenario represents a classic instance of improper input validation where the system fails to verify that user-controlled or hardware-provided parameters fall within expected operational bounds before utilization.
The technical consequence of this flaw is severe and directly impacts kernel stability through memory corruption and subsequent crashes. Under the SLUB slab allocator, which is commonly used in modern Linux distributions for small object caching, a request for zero bytes does not fail immediately but instead returns a special pointer known as ZERO_SIZE_PTR. While this design choice optimizes performance by avoiding unnecessary allocations for empty buffers, it introduces a trap for code that assumes non-null pointers indicate valid memory regions. The mmc_alloc_sg function performs a standard null check on the returned scatterlist pointer; because ZERO_SIZE_PTR is not NULL, this check passes erroneously. Consequently, the kernel proceeds to initialize the scatter-gather table using sg_init_table(), which attempts to access and manipulate memory at an invalid address derived from the zero-sized allocation. This leads to undefined behavior that manifests as a page fault when the CPU tries to dereference the pointer during subsequent operations.
The operational impact of this vulnerability is primarily denial-of-service, resulting in kernel panics or system crashes rather than arbitrary code execution. As evidenced by crash dumps associated with affected systems such as those using Rockchip RK3576 hardware, the failure occurs deep within the block layer's request allocation path during MMC controller initialization or rescan events. The error trace indicates a data abort exception triggered at sg_init_table, causing an immediate halt of the kernel execution context on the affected CPU core. This disrupts all I/O operations handled by that specific MMC host controller and can destabilize the entire operating system if not contained properly. For embedded devices relying on stable storage interfaces for booting or critical data persistence, such crashes render the device unresponsive until a reboot occurs, posing significant reliability risks in production environments where hardware configuration errors might be introduced through custom driver modifications or misconfigured device tree parameters.
To mitigate this vulnerability and prevent future occurrences of similar issues within the MMC subsystem, developers have implemented explicit validation checks directly in mmc_mq_init_request(). This defensive programming measure involves verifying that sg_len, which is derived from max_segs, is strictly greater than zero before proceeding with memory allocation and initialization routines. If a zero value is detected, the function now returns an appropriate error code rather than attempting to allocate resources or initialize structures. Additionally, diagnostic messages are printed to assist host driver developers in identifying misconfigurations during development cycles. This approach ensures graceful failure modes instead of catastrophic system crashes, aligning with best practices for robust kernel design where input sanitization is performed at the earliest possible entry point into sensitive subsystems.
From a security taxonomy perspective, this vulnerability maps directly to CWE-20 Improper Input Validation, as the core issue lies in the acceptance and processing of untrusted or incorrectly configured host parameters without adequate boundary checks. It also relates to CWE-134 Use of Externally-Controlled Format String if one considers the potential for log injection via error messages, though the primary severity is rooted in memory safety violations leading to availability loss. In terms of adversary behavior and detection frameworks like MITRE ATT&CK, this flaw does not represent an exploitable attack vector for privilege escalation or remote code execution but rather a stability weakness that could be triggered by local physical access if an attacker can manipulate hardware configuration parameters or load malicious kernel modules with incorrect driver settings. Therefore, it is classified under availability impacts rather than confidentiality or integrity breaches. System administrators and developers should ensure their MMC host drivers adhere to strict limits on segment counts and validate these values against the capabilities advertised by the underlying hardware controller to maintain system resilience.