[BUG] hung task in i2c_transfer via i2c-dev ioctl (rt_mutex lock not released?)

[WangzXD0325@xxxxxxxxxxx]

Hello,

I am reporting a hung task issue observed during fuzz testing involving
i2c-dev ioctl and i2c_transfer.

=== Summary ===

Multiple userspace tasks become stuck in D state inside i2c_transfer(),
waiting on the I2C bus rt_mutex. The hung task watchdog triggers after
~143 seconds.

The issue appears to be triggered by unsupported or malformed I2C
transactions issued via i2c-dev, leading to a bus lock that is not
released.

=== Environment ===

Kernel: 6.18.0 (locally built)
Config: PREEMPT (voluntary)
Arch: x86_64
Hardware: QEMU Standard PC (i440FX + PIIX)
Workload: syz-executor (fuzzing via i2c-dev)

=== Observed behavior ===

Kernel repeatedly reports:

INFO: task syz.* blocked for more than 143 seconds
i2c i2c-0: Unsupported transaction 7
i2c i2c-0: Unsupported transaction 8

Multiple syz processes block concurrently.

=== Call trace (hung tasks) ===

All affected tasks are blocked in i2c_lock_bus():

rt_mutex_lock_nested
i2c_lock_bus
i2c_transfer
i2cdev_ioctl_rdwr
i2cdev_ioctl
__x64_sys_ioctl

Lockdep output shows the same adapter lock held:

i2c_register_adapter (rt_mutex)

=== Additional stack (adapter side) ===

One CPU is observed executing inside the bit-banging I2C algorithm:

cx8800_bit_getscl [cx88xx]
sclhi
i2c_stop
try_address
bit_xfer
__i2c_transfer

This suggests the adapter or algorithm may be stuck while holding the
bus lock.

=== Reproducer ===

No standalone reproducer is currently available.
The issue was observed during syzkaller-style fuzzing via i2c-dev.

=== Expected behavior ===

Invalid or unsupported I2C transactions issued via i2c-dev should fail
gracefully and must not leave the I2C bus locked indefinitely.

=== Notes ===

This may indicate:

a missing unlock in an error path, or

lack of timeout / abort handling in bit-banging I2C algorithms or the
cx88xx adapter driver when facing malformed transactions.

I can provide additional logs or configuration details if needed.

Thanks for your time.

Reported-by:
Zhi Wang