linux-kernel - [BUG] hung task in i2c_transfer via i2c-dev ioctl (rt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID:
 <KL1PR03MB8800984941696A40C81FEE77A184A@KL1PR03MB8800.apcprd03.prod.outlook.com>
Date: Wed, 7 Jan 2026 05:16:43 +0000
From: "WangzXD0325@...look.com" <WangzXD0325@...look.com>
To: Wolfram Sang <wsa@...nel.org>
CC: "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Mauro Carvalho
 Chehab <mchehab@...nel.org>, "linux-media@...r.kernel.org"
	<linux-media@...r.kernel.org>
Subject: [BUG] hung task in i2c_transfer via i2c-dev ioctl (rt_mutex lock not
 released?)

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