[BUG] i2c: i801: interrupt storm and hung task with invalid block read size

[w15303746062]

From: Mingyu Wang <25181214217@xxxxxxxxxxxxxxxxx>

Hi all,

During concurrent fuzzing of the i2c-i801 driver, a severe interrupt
storm and hung task were observed. 

Note: The crash log below is from our fuzzing environment, but I have 
audited the latest upstream master branch and the defective error 
recovery logic remains untouched.

The issue occurs when the hardware returns an invalid block read size 
(e.g., len = 0 or len > 32) during a byte-by-byte block transaction. 
While triggered in QEMU, a faulty physical SMBus slave or bus noise 
returning a 0-length could similarly cause a kernel-level DoS.

Code path analysis:
In IRQ mode, i801_isr_byte_done() reads the block size. If invalid, 
i801_get_block_len() returns -EPROTO. However, the ISR catches this 
negative value and forces the length to 32 instead of aborting:

	if (priv->len < 0)
		/* FIXME: Recover */
		priv->len = I2C_SMBUS_BLOCK_MAX;

Because the transaction is not cleanly aborted:
1. priv->status is not set to an error state, and complete() is never 
   called. The caller hangs in wait_for_completion_timeout(), holding 
   the i2c adapter lock.
2. The hardware remains in HOST_BUSY, continually asserting the IRQ 
   line and trapping the CPU in i801_isr() (interrupt storm).

Crash logs snippet:
------------------------------------------------------------------
i801_smbus 0000:00:1f.3: Illegal SMBus block read size 0
clocksource: Long readout interval, skipping watchdog check
INFO: task syz.3.373:3148 blocked for more than 143 seconds.
      Not tainted 6.18.0 #10
...
1 lock held by syz.0.370/3150:
 #0: ffff888101d110a8 (i2c_register_adapter){+.+.}-{4:4}, at: i2c_smbus_xfer
...
NMI backtrace for cpu 2
CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.18.0 #10 PREEMPT
Call Trace:
 <IRQ>
 i801_isr+0x167/0x990 [i2c_i801]
 __handle_irq_event_percpu+0x222/0x870
 handle_irq_event+0xb0/0x1f0
...
------------------------------------------------------------------

Could you please advise on the preferred way to properly abort the 
transaction here without corrupting the hardware state machine?

Best regards,

Mingyu Wang
25181214217@xxxxxxxxxxxxxxxxx