Root Cause Analysis

1. Involved Functions, Structs, and Files

• Files:
  • drivers/md/dm-cache-target.c: Contains calculate_discard_block_size() and too_many_discard_blocks().
  • drivers/md/dm-cache-policy-internal.h: Contains alloc_bitset() and bitset_size_in_bytes().
  • include/linux/device-mapper.h: Defines dm_sector_div_up().
  • include/asm-generic/div64.h & include/linux/math.h: Defines sector_div(n, base) which wraps do_div(n, base).
  • mm/vmalloc.c: Contains __vmalloc_node_range_noprof().
• Functions & Structs:
  • struct cache: Fields cache->origin_sectors (sector_t), cache->discard_block_size (uint32_t), cache->discard_nr_blocks (dm_dblock_t), cache->discard_bitset (unsigned long *).
  • calculate_discard_block_size() / too_many_discard_blocks(): Computes discard block size such that origin sectors divided by discard block size does not exceed MAX_DISCARD_BLOCKS (16384).
  • dm_sector_div_up(): Computes ceil(n / sz) using sector_div().
  • alloc_bitset(): Computes bytes needed for a bitset and invokes vzalloc().
  • __vmalloc_node_range_noprof(): Checks WARN_ON_ONCE(!size).

2. Trigger Mechanism and Bug Flow

1. Large Origin Size Specification: During a DM_TABLE_LOAD ioctl, a cache target is created with a very large target sector length (cache->origin_sectors = ti->len = 0x3fffffffffffff) and block size ca->block_size = 1024.

2. Discard Block Size Calculation Loop: In cache_create() (drivers/md/dm-cache-target.c:2524), the kernel calculates:

   cache->discard_block_size =
       calculate_discard_block_size(cache->sectors_per_block, cache->origin_sectors);
   

   calculate_discard_block_size() doubles discard_block_size while too_many_discard_blocks(discard_block_size, origin_size) returns true:

   static bool too_many_discard_blocks(sector_t discard_block_size, sector_t origin_size)
   {
       (void) sector_div(origin_size, discard_block_size);
       return origin_size > MAX_DISCARD_BLOCKS;
   }
   

   Because origin_sectors is huge (0x3fffffffffffff), discard_block_size (starting at 1024) is doubled in a loop. Even at 1ULL << 31 (2147483648), 0x3fffffffffffff / (1ULL << 31) = 0x7fffff = 8388607 > MAX_DISCARD_BLOCKS (16384). Therefore, the loop doubles discard_block_size once more to 1ULL << 32 (0x100000000).

3. Divisor 32-bit Truncation in sector_div(): sector_div(n, base) is defined as do_div(n, base). Per include/asm-generic/div64.h:

   #define do_div(n, base) ({ \
       uint32_t __base = (base); \
       ...
   

   The divisor is cast and truncated to a 32-bit uint32_t. When discard_block_size == 1ULL << 32, (uint32_t)(1ULL << 32) == 0.

4. Architectural Divergence on Division by Zero:

   • On ARM64 (the architecture of this report): ARM64 hardware integer division (udiv) architecturally specifies that division by zero does not trap and returns 0. Consequently, sector_div(origin_size, 0) sets origin_size = 0. The condition 0 > 16384 evaluates to false, exiting the loop and returning 1ULL << 32.
   • On x86_64: Division by zero triggers a CPU Division Error (#DE) exception, resulting in an immediate kernel panic/oops in kernel mode.

5. Subsequent Zero-Size Allocation on ARM64: On ARM64, execution continues:

   • Line 2527 computes cache->discard_nr_blocks = to_dblock(dm_sector_div_up(cache->origin_sectors, cache->discard_block_size));. In dm_sector_div_up(), sector_div() is called with sz = 1ULL << 32 (again truncated to 0), yielding 0. Thus cache->discard_nr_blocks = 0.
   • Line 2529 calls alloc_bitset(from_dblock(cache->discard_nr_blocks)), which calculates: bitset_size_in_bytes(0) = sizeof(unsigned long) * dm_div_up(0, BITS_PER_LONG) = 0.
   • vzalloc(0) invokes __vmalloc_node_range_noprof(0, ...) with size = 0.
   • Line 4037 of mm/vmalloc.c:

     if (WARN_ON_ONCE(!size))
         return NULL;
     

     triggers the syzkaller warning splat.

3. Runtime Consequences in a Production Build

• On the corresponding ARM64 production build (without panic_on_warn):
  • WARN_ON_ONCE(!size) is non-fatal and outputs a diagnostic message without halting the kernel.
  • __vmalloc_node_range_noprof() returns NULL.
  • cache_create() inspects the return value:

    if (!cache->discard_bitset) {
        *error = "could not allocate discard bitset";
        goto bad;
    }
    

    and enters error recovery at bad:, calling __destroy(cache) to free all allocated resources and return -ENOMEM.
  • The ioctl returns -ENOMEM to userspace with device-mapper error messages logged. No locks are leaked, no state is corrupted, and execution proceeds normally. Under the criteria for WARNING reports with graceful error handling, RawDenialOfService is false.
• On x86_64 production builds:
  • sector_div with a divisor truncated to zero triggers an unhandled #DE exception and halts execution (kernel panic / oops).

4. Classification Summary

• MemoryCorruption: false (No memory corruption, out-of-bounds writes, or use-after-free occurs; on ARM64 the allocation returns NULL and errors out, and on x86_64 execution traps on division by zero).
• InfoLeak: "none" (No kernel memory contents are exposed to userspace).
• RawDenialOfService: false (On the corresponding ARM64 production build matching the report, execution is not halted: WARN_ON_ONCE(!size) is caught and gracefully handled by cache_create(), unwinding all state and returning -ENOMEM).
• IsNetCandidate: false (Storage / Device Mapper subsystem; no network stack involvement).
• IsKVMCandidate: false (No KVM or virtualization stack involvement).