CVE-2022-49900 in Linux
Summary
by MITRE • 05/01/2025
In the Linux kernel, the following vulnerability has been resolved:
i2c: piix4: Fix adapter not be removed in piix4_remove()
In piix4_probe(), the piix4 adapter will be registered in:
piix4_probe() piix4_add_adapters_sb800() / piix4_add_adapter() i2c_add_adapter()
Based on the probed device type, piix4_add_adapters_sb800() or single piix4_add_adapter() will be called. For the former case, piix4_adapter_count is set as the number of adapters, while for antoher case it is not set and kept default *zero*.
When piix4 is removed, piix4_remove() removes the adapters added in piix4_probe(), basing on the piix4_adapter_count value. Because the count is zero for the single adapter case, the adapter won't be removed and makes the sources allocated for adapter leaked, such as the i2c client and device.
These sources can still be accessed by i2c or bus and cause problems. An easily reproduced case is that if a new adapter is registered, i2c will get the leaked adapter and try to call smbus_algorithm, which was already freed:
Triggered by: rmmod i2c_piix4 && modprobe max31730
BUG: unable to handle page fault for address: ffffffffc053d860 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 3752 Comm: modprobe Tainted: G Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:i2c_default_probe (drivers/i2c/i2c-core-base.c:2259) i2c_core RSP: 0018:ffff888107477710 EFLAGS: 00000246 ... <TASK> i2c_detect (drivers/i2c/i2c-core-base.c:2302) i2c_core __process_new_driver (drivers/i2c/i2c-core-base.c:1336) i2c_core bus_for_each_dev (drivers/base/bus.c:301) i2c_for_each_dev (drivers/i2c/i2c-core-base.c:1823) i2c_core i2c_register_driver (drivers/i2c/i2c-core-base.c:1861) i2c_core do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ... </TASK> ---[ end trace 0000000000000000 ]---
Fix this problem by correctly set piix4_adapter_count as 1 for the single adapter so it can be normally removed.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 03/15/2026
The vulnerability described in CVE-2022-49900 represents a critical resource management flaw within the Linux kernel's i2c subsystem, specifically affecting the piix4 driver implementation. This issue stems from improper initialization of adapter count tracking variables during device removal operations, creating a persistent memory leak scenario that can lead to system instability and potential security implications. The vulnerability manifests when the piix4 driver attempts to clean up resources associated with I2C adapters during module removal, particularly impacting the SMBus controller functionality on certain motherboards.
The technical root cause lies in the inconsistent handling of adapter count variables within the piix4 driver's probe and remove functions. During device initialization in piix4_probe(), the driver correctly sets up multiple adapters for certain device types through the piix4_add_adapters_sb800() function, which properly initializes the piix4_adapter_count variable to reflect the actual number of adapters created. However, for single adapter configurations, the piix4_add_adapter() function is called without properly setting the piix4_adapter_count variable, leaving it at its default value of zero. This discrepancy creates a fundamental mismatch between the number of adapters that were actually registered and the number that the removal function attempts to clean up.
When the module is unloaded via rmmod, the piix4_remove() function relies on the piix4_adapter_count value to determine how many adapters to process for cleanup. Since this count remains zero for single adapter cases, the function fails to iterate through and properly remove the registered adapter, resulting in resource leaks that persist in kernel memory. These leaked resources include I2C client structures and device objects that remain accessible to the I2C subsystem even after the module should have been completely unloaded. The persistence of these resources creates a dangerous state where subsequent module loading operations can attempt to access already freed memory structures, leading to kernel page faults and system crashes.
The operational impact of this vulnerability extends beyond simple resource leaks to potentially compromise system stability and security integrity. When a new I2C driver such as max31730 is loaded after the problematic i2c_piix4 module has been removed, the kernel's I2C core attempts to probe for new devices and encounters the leaked adapter structures. This situation triggers a page fault when the system attempts to access memory locations that were already freed, specifically referencing the smbus_algorithm structure that should have been properly deallocated. The resulting kernel oops and system crash demonstrate how this resource management failure can lead to complete system instability, as evidenced by the KASAN (Kernel Address Sanitizer) output showing the attempt to read from address ffffffff c053d860 which corresponds to freed memory.
This vulnerability aligns with CWE-415: Double Free and CWE-416: Use After Free categories, as it represents a classic case of improper resource management where allocated kernel memory is freed but subsequently accessed, leading to undefined behavior and system crashes. From an ATT&CK framework perspective, this vulnerability could be leveraged by adversaries to achieve privilege escalation or denial of service conditions by repeatedly loading and unloading the affected module, potentially causing system instability or creating conditions for more sophisticated attacks. The fix implemented addresses this by ensuring that piix4_adapter_count is properly initialized to one for single adapter configurations, enabling the removal function to correctly process and clean up all registered adapters. This remediation directly addresses the root cause by maintaining proper synchronization between adapter registration and removal operations, preventing the accumulation of stale kernel memory structures that could be exploited or cause system instability.