CVE-2022-49900

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:

piix4probe() piix4addadapterssb800() / piix4addadapter() i2caddadapter()

Based on the probed device type, piix4addadapterssb800() or single piix4addadapter() will be called. For the former case, piix4adapter_count is set as the number of adapters, while for antoher case it is not set and kept default zero.

When piix4 is removed, piix4remove() removes the adapters added in piix4probe(), basing on the piix4adaptercount 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: errorcode(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:i2cdefaultprobe (drivers/i2c/i2c-core-base.c:2259) i2ccore RSP: 0018:ffff888107477710 EFLAGS: 00000246 ... <TASK> i2cdetect (drivers/i2c/i2c-core-base.c:2302) i2ccore _processnewdriver (drivers/i2c/i2c-core-base.c:1336) i2ccore busforeachdev (drivers/base/bus.c:301) i2cforeachdev (drivers/i2c/i2c-core-base.c:1823) i2ccore i2cregisterdriver (drivers/i2c/i2c-core-base.c:1861) i2ccore dooneinitcall (init/main.c:1296) doinitmodule (kernel/module/main.c:2455) ... </TASK> ---[ end trace 0000000000000000 ]---

Fix this problem by correctly set piix4adaptercount as 1 for the single adapter so it can be normally removed.