CVE-2026-98722

What it actually does

Divide-by-zero error in block2mtd kernel module add_device() when erase_size module parameter is zero, evaluated in size % erase_size check and triggering kernel oops/panic.

Why it matters to the business

System instability or full denial of service on Linux hosts using the block2mtd module, causing unplanned downtime and requiring reboots or recovery procedures.

How an attack unfolds

An attacker with privileges to write kernel module parameters (via sysfs or modprobe) supplies erase_size=0, causing the division during block2mtd_setup2 and resulting in an immediate kernel panic.

How to fix it

Apply a kernel patch that rejects zero erase_size before the modulo operation so the existing invalid-argument error path is reached instead of crashing.

How to confirm the fix worked

Confirm the updated module parameter handler returns an error for erase_size=0 without generating a divide error, and test module load with both valid and zero values.

Typical attack path

1. Obtain ability to load or configure kernel modules on target system
2. Write zero value to the block2mtd erase_size parameter via param_attr_store
3. Trigger module initialization path
4. Execute modulo operation with zero divisor to induce divide error and panic

How to detect it

Inspect kernel logs (dmesg, /var/log/kern.log) for divide error oops referencing block2mtd.c add_device or block2mtd_setup2 during module parameter writes.

• divide error: 0000 [#1] PREEMPT SMP PTI
• RIP: 0010:add_device drivers/mtd/devices/block2mtd.c:296
• block2mtd_setup2+0x592/0xda0 drivers/mtd/devices/block2mtd.c:459
• Call Trace: block2mtd_setup+0x27/0xe0

What your security team should do

• Prioritize kernel updates containing the block2mtd fix
• Restrict unprivileged module loading and parameter modification via sysfs permissions
• Enable kernel panic logging and monitoring for rapid detection of crashes