Root Cause Analysis
1. Functions, Structs, and Files Involved
2. Mechanism and Trigger
During device probing (in this report, when probing a msi2500 USB device via msi2500_probe()), the driver attempts to register an SPI host controller by calling spi_register_controller(). To allocate a dynamic bus number, spi_register_controller() calls spi_controller_id_alloc(ctlr, first_dynamic, 0):
static int spi_controller_id_alloc(struct spi_controller *ctlr, int start, int end)
{
int id;
mutex_lock(&board_lock);
id = idr_alloc(&spi_controller_idr, ctlr, start, end, GFP_KERNEL);
mutex_unlock(&board_lock);
if (WARN(id < 0, "couldn't get idr"))
return id == -ENOSPC ? -EBUSY : id;
ctlr->bus_num = id;
return 0;
}
When idr_alloc() requires internal radix tree node allocation (radix_tree_node_alloc()), the memory allocation can fail if the system is under memory pressure or when fault injection (failslab) is activated. In such cases, idr_alloc() returns -ENOMEM (observed as 0xfffffff4 in register R14).
However, spi_controller_id_alloc() inappropriately uses WARN(id < 0, "couldn't get idr") for all negative return values. In the Linux kernel, memory allocation failures are expected runtime conditions that must be gracefully handled rather than triggering a kernel WARNING. Syzkaller's fault-injection engine intercepted this WARN() invocation.
3. Production Runtime Consequences
- Production behavior without sanitizers and without
panic_on_warn:
board_lock is unlocked before the WARN macro.- The function returns the error code:
id == -ENOSPC ? -EBUSY : id (evaluating to -ENOMEM).
spi_register_controller() catches the non-zero status and aborts cleanly.msi2500_probe() catches the failure and follows its error path (err_put_controller: -> spi_controller_put() -> v4l2_device_unregister() -> kfree()), unwinding all allocated state cleanly.- Execution continues normally; no kernel panic, hang, deadlock, or resource leak occurs.
- Memory Corruption:
false. The error path is well-defined and frees resources properly without double frees, dangling references, or corruptions.
- Information Leak:
none. No uninitialized memory or kernel addresses are leaked.
- Raw Denial of Service:
false. In a standard production build without panic_on_warn, a WARN macro does not halt execution, and the failure is handled gracefully by caller error recovery.
- Networking / KVM Candidate:
false. Neither networking nor KVM/virtualization subsystems are involved.