Re: [PATCH 2/2] media: i2c: add driver for ITE IT6625/IT6626

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 13 potential issue(s) to consider:
- [High] Premature registration of the V4L2 subdevice exposes uninitialized hardware and control state to the system.
- [High] The probe error path uses non-synchronous `cancel_delayed_work()`, leading to a use-after-free.
- [High] `get_fmt` and `set_fmt` mishandle `V4L2_SUBDEV_FORMAT_TRY` and unsupported formats, violating the API and corrupting active state.
- [High] Banked register reads in the threaded interrupt handler and `get_detected_timings` omit mutex locking, causing data corruption.
- [High] An uninitialized stack variable `rxmsg` is passed to the CEC framework, leaking kernel stack memory to userspace.
- [High] The CEC interrupt handler uses an `else if` block, permanently dropping TX completion interrupts if an RX interrupt fires simultaneously.
- [High] Teardown asymmetry in `it6625_remove` cancels background work before unregistering the subdevice.
- [Medium] The `v4l2_ctrl_handler` memory is leaked on multiple probe error paths.
- [Medium] Incorrect parameters passed to `read_poll_timeout()` severely delay timeouts and defeat the polling mechanism.
- [Medium] EDID capacity querying and clearing fail with `-EINVAL` because `blocks == 0` is strictly rejected.
- [Medium] The debugfs handler `it6625_mipi_reg_write` misuses `simple_write_to_buffer` and parses uninitialized stack memory.
- [Medium] `it6625_cec_adap_transmit` sets the hardware transmit trigger but fails to wait for confirmation, risking aborted transmissions.
- [Low] The `i2c_device_id` array uses positional rather than C99 designated initializers.
--

--- Patch [2]: [PATCH 2/2] media: i2c: add driver for ITE IT6625/IT6626 ---
commit 09bd00239552da9315d71f96392b0c2b3c5769e2
Author: Hermes Wu <Hermes.wu@ite.com.tw>

    media: i2c: add driver for ITE IT6625/IT6626
    
    Add a V4L2 subdevice driver for the ITE IT6625/IT6626 HDMI-to-MIPI
    CSI-2 bridge chips. IT6625 accepts an HDMI 2.0 input and IT6626 an
    HDMI 2.1 input, converting it to a D-PHY (or C/D-PHY on IT6626)
    MIPI CSI-2 output. The bridge is configured over I2C, exposes an
    HDMI CEC adapter, and supports EDID read/write, DV timings
    detection/configuration, and HPD control via the standard V4L2
    subdevice pad and video ops.

diff --git a/drivers/media/i2c/it6625.c b/drivers/media/i2c/it6625.c
new file mode 100644
index 0000000000000..2c1200dd273b4
--- /dev/null
+++ b/drivers/media/i2c/it6625.c
@@ -0,0 +1,2088 @@
[ ... ]
> +static int it6625_wait_for_status(struct it6625 *it6625, u8 reg, u8 val,
> +				  int timeout_ms)
> +{
> +	struct device *dev = it6625->dev;
> +	int status;
> +	int rval;
> +
> +	status = read_poll_timeout(it6625_read_byte, rval, rval == val,
> +				   50 * 1000,
> +				   timeout_ms * 1000,
> +				   false, it6625, reg);

[Severity: Medium]
Are the parameters to read_poll_timeout() reversed here?

The sleep_us parameter is passed as 50 * 1000 (50ms) while timeout_us is
timeout_ms * 1000 (e.g. 25ms in some callers). Because the sleep duration is
twice the length of the total timeout, if the condition is not met
immediately, won't this sleep for 50ms and unconditionally time out on the
next check, effectively breaking the polling behavior?

[ ... ]
> +static int it6625_read_edid(struct it6625 *it6625, u8 *edid, int start_block,
> +			    int num_blocks)
> +{
> +	int i, bank_ctrl, err = 0;
> +	struct device *dev = it6625->dev;
> +
> +	if (!edid) {
> +		dev_err(dev, "edid buffer is NULL");
> +		return -EINVAL;
> +	}
> +
> +	if (start_block < 0 || num_blocks <= 0 ||
> +	    start_block + num_blocks > EDID_NUM_BLOCKS_MAX) {
> +		dev_err(dev,
> +			"invalid block range: start_block=%d, num_blocks=%d",
> +			start_block, num_blocks);
> +		return -EINVAL;
> +	}

[Severity: Medium]
Will rejecting num_blocks <= 0 break standard V4L2 EDID operations?

The V4L2 specification defines VIDIOC_SUBDEV_G_EDID with blocks = 0 as the
command to query the maximum supported blocks. Since this unconditionally
returns -EINVAL for 0, how does userspace query capacity?

[ ... ]
> +static int it6625_write_edid(struct it6625 *it6625, u8 *edid, int start_block,
> +			     int num_blocks)
> +{
> +	int i, bank_ctrl, err = 0;
> +	struct device *dev = it6625->dev;
> +
> +	if (start_block < 0 || num_blocks <= 0 ||
> +	    start_block + num_blocks > EDID_NUM_BLOCKS_MAX) {
> +		dev_err(dev,
> +			"invalid block range: start_block=%d, num_blocks=%d",
> +			start_block, num_blocks);
> +		return -EINVAL;
> +	}

[Severity: Medium]
Will this prevent userspace from clearing the EDID?

VIDIOC_SUBDEV_S_EDID with blocks = 0 is defined as the command to clear the
EDID. Unconditionally rejecting 0 here appears to break that functionality.

[ ... ]
> +static int it6625_get_detected_timings(struct it6625 *it6625,
> +				       struct v4l2_dv_timings *timings)
> +{
> +	struct v4l2_bt_timings *bt = &timings->bt;
> +	int val;
> +	unsigned int width, height, frame_width, frame_height;
> +	u8 buffer[8];
> +
> +	if (no_signal(it6625)) {
> +		dev_err(it6625->dev, "no signal detected");
> +		return -ENOLINK;
> +	}
> +
> +	memset(timings, 0, sizeof(struct v4l2_dv_timings));
> +	timings->type = V4L2_DV_BT_656_1120;
> +	val = it6625_read_byte(it6625, REG_VID_INFO);
> +	if (val < 0) {
> +		dev_err(it6625->dev, "failed to read video info");
> +		return -EIO;
> +	}
> +
> +	bt->interlaced = val & B_INTERLACE ?
> +			 V4L2_DV_INTERLACED : V4L2_DV_PROGRESSIVE;
> +
> +	if (it6625_read_bytes(it6625, REG_H_ACTIVE_1, buffer, 8) < 0)
> +		return -EIO;

[Severity: High]
Can this read from the wrong register bank if a concurrent EDID read is in
progress?

The chip appears to use a banked register layout where REG_INFO_BANK_SEL
swaps the meaning of registers. While it6625_read_edid() correctly acquires
it6625_lock to switch the bank, this function reads from REG_VID_INFO (0x68)
without acquiring the mutex.

If a format query runs concurrently with an EDID read, could it silently read
EDID data instead of Video Info?

[ ... ]
> +static int it6625_cec_adap_transmit(struct cec_adapter *adap, u8 attempts,
> +				    u32 signal_free_time, struct cec_msg *msg)
> +{
> +	struct it6625 *it6625 = adap->priv;
> +
> +	dump_cec_msg(it6625, msg, "CEC_TX");
> +
> +	guard(mutex)(&it6625->it6625_lock);
> +	it6625_write_bytes(it6625, REG_CEC_TX_DATA, msg->msg, msg->len);
> +	it6625_write_byte(it6625, REG_CEC_TX_DATA_LEN, msg->len);
> +	it6625_set_bits(it6625, REG_HOST_CTRL_INT, B_CEC_SEND_DATA, B_CEC_SEND_DATA);
> +
> +	return 0;
> +}

[Severity: Medium]
Does this command need to wait for hardware acceptance before releasing the
lock?

Other functions using REG_HOST_CTRL_INT wait for the hardware to clear the
trigger bit via it6625_wait_for_status().

If another thread acquires the mutex immediately after this returns and calls
it6625_set_bank(), it will write to REG_HOST_CTRL_INT directly. Since it uses
a bare write rather than set_bits, won't that clear B_CEC_SEND_DATA before
the hardware has latched the command, aborting the transmission?

[ ... ]
> +static void it6625_cec_handler(struct it6625 *it6625, u8 intstatus)
> +{
> +	struct cec_msg rxmsg;
> +	int val = 0;

[Severity: High]
Could this leak uninitialized kernel stack memory to userspace?

The rxmsg structure is allocated on the stack, but only the msg array and
len field are populated below before passing it to cec_received_msg(). The
CEC core initializes several tracking fields but leaves others (like timeout,
reply, and compiler padding) untouched.

When the CEC framework copies this to userspace via the CEC_RECEIVE ioctl,
won't the uninitialized bytes be leaked?

> +
> +	if (intstatus & B_CEC_RX_RECEIVED) {
> +		val = it6625_read_byte(it6625, REG_CEC_RX_DATA_LEN);
> +		if (val <= 0 || val > 16) {
> +			dev_err(it6625->dev, "invalid CEC RX length %d", val);
> +			return;
> +		}

[Severity: High]
If the RX data length is invalid, won't the early return immediately
terminate processing and guarantee any pending TX interrupt is lost?

> +
> +		it6625_read_bytes(it6625, REG_CEC_RX_DATA, &rxmsg.msg[0], val);

[Severity: High]
Can this read the wrong data if an EDID read is happening concurrently?

Similar to it6625_get_detected_timings(), this reads from REG_CEC_RX_DATA
(0x20) without acquiring it6625_lock. If an EDID read has switched the bank,
won't this read EDID bytes instead of the CEC payload?

> +		rxmsg.len = val;
> +		it6625_write_byte(it6625, REG_CEC_RX_DATA_LEN, 0);
> +		cec_received_msg(it6625->cec_adap, &rxmsg);
> +		dump_cec_msg(it6625, &rxmsg, "CEC_RX");
> +
> +	} else if (intstatus & B_CEC_TX_UPDATE) {

[Severity: High]
Will this logic permanently drop a TX completion interrupt if an RX interrupt
fires at the same time?

The TX and RX interrupt status checks are chained with an 'else if'. If both
B_CEC_RX_RECEIVED and B_CEC_TX_UPDATE are asserted, it looks like the TX
branch is skipped entirely, causing CEC transmission timeouts.

[ ... ]
> +static int it6625_get_fmt(struct v4l2_subdev *sd,
> +			  struct v4l2_subdev_state *sd_state,
> +			  struct v4l2_subdev_format *format)
> +{
> +	struct it6625 *it6625 = sd_to_6625(sd);
> +	struct v4l2_dv_timings timings;
> +
> +	if (format->pad != 0)
> +		return -EINVAL;
> +
> +	format->format.code = it6625->mbus_fmt_code;
> +	it6625_get_timings(it6625, &timings);

[Severity: High]
Does this ignore format->which and always return the active format instead of
the TRY state when V4L2_SUBDEV_FORMAT_TRY is requested?

[ ... ]
> +static int it6625_set_fmt(struct v4l2_subdev *sd,
> +			  struct v4l2_subdev_state *sd_state,
> +			  struct v4l2_subdev_format *format)
> +{
[ ... ]
> +	ret = it6625_csi_mbus_code_idx(mbus_fmt_code);
> +
> +	if (ret < 0) {
> +		v4l2_dbg(1, debug, sd, "%s: unsupported format code 0x%x",
> +			 __func__, mbus_fmt_code);
> +		return ret;
> +	}
> +
> +	it6625->csi_format = it6625_formats[ret].csi_format;
> +
> +	if (format->which == V4L2_SUBDEV_FORMAT_TRY) {

[Severity: High]
Does this unconditionally mutate the active hardware state
(it6625->csi_format) before checking if it is a V4L2_SUBDEV_FORMAT_TRY
request?

It looks like a TRY_FMT ioctl would silently corrupt the active hardware
configuration.

Also, if the requested format code is unsupported, this returns -EINVAL
instead of falling back to a supported format as required by the V4L2 API.
Could this cause issues with generic userspace tools?

[ ... ]
> +static ssize_t it6625_mipi_reg_write(struct file *file,
> +				     const char __user *user_buf,
> +				     size_t count, loff_t *ppos)
> +{
> +	struct it6625 *it6625 = file_inode(file)->i_private;
> +	char buf[32];
> +	unsigned int addr, val;
> +	ssize_t len;
> +
> +	len = simple_write_to_buffer(buf, sizeof(buf) - 1, ppos, user_buf, count);
> +	if (len < 0)
> +		return len;
> +	buf[len] = '\0';
> +
> +	if (sscanf(buf, "%X %X", &addr, &val) != 2)

[Severity: Medium]
Is it safe to pass buf to sscanf if *ppos is greater than zero?

simple_write_to_buffer() writes the user data to buf + *ppos. If a user
performs a write with an offset (*ppos > 0), the beginning of the buf array
remains uninitialized stack memory. sscanf() will then parse this random
garbage, potentially leading to unpredictable register writes.

[ ... ]
> +static int it6625_init_v4l2_subdev(struct it6625 *it6625)
> +{
[ ... ]
> +	sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE | V4L2_SUBDEV_FL_HAS_EVENTS;
> +	if (it6625_v4l2_init_controls(sd)) {
> +		dev_err(it6625->dev, "Failed to initialize v4l2 controls");
> +		return -ENOMEM;
> +	}
> +
> +	it6625->pad.flags = MEDIA_PAD_FL_SOURCE;
> +	sd->entity.function = MEDIA_ENT_F_CAM_SENSOR;
> +	err = media_entity_pads_init(&sd->entity, 1, &it6625->pad);
> +	if (err < 0) {
> +		dev_err(it6625->dev, "%s %d err=%d", __func__, __LINE__, err);
> +		return err;
> +	}

[Severity: Medium]
If media_entity_pads_init() fails, does this leak the v4l2_ctrl_handler
memory?

The controls are successfully initialized via it6625_v4l2_init_controls()
above, but the error path returns directly without freeing them.

> +
> +	err = v4l2_async_register_subdev(sd);
> +	if (err < 0) {
> +		dev_err(it6625->dev, "%s %d err=%d", __func__, __LINE__, err);
> +		media_entity_cleanup(&sd->entity);
> +		return err;
> +	}

[Severity: High]
Is the subdevice registered prematurely here?

v4l2_async_register_subdev() exposes the subdevice to the system. However,
critical setup like v4l2_ctrl_handler_setup(), cec_allocate_adapter(), and
it6625_initial_setup() happens later in probe.

If a host driver binds and calls subdev operations immediately after
registration, couldn't it operate on uninitialized chip state or trigger
NULL pointer dereferences on the CEC adapter?

[ ... ]
> +static int it6625_probe(struct i2c_client *client)
> +{
[ ... ]
> +err_clean_hdl:
> +	v4l2_ctrl_handler_free(&it6625->hdl);
> +err_clean_media_entity:
> +	v4l2_async_unregister_subdev(sd);
> +	v4l2_device_unregister_subdev(sd);
> +	media_entity_cleanup(&sd->entity);
> +
> +err_clean_work_queues:
> +	if (!client->irq)
> +		timer_shutdown_sync(&it6625->timer);
> +	cancel_work_sync(&it6625->polling_work);
> +	cancel_delayed_work(&it6625->hpd_delayed_work);
> +	mutex_destroy(&it6625->it6625_lock);
> +	return err;
> +}

[Severity: Medium]
Do the err_clean_media_entity and err_clean_work_queues paths bypass the
control handler cleanup?

If v4l2_ctrl_handler_setup() or CEC setup fail, jumping to these labels
permanently leaks the allocated v4l2_ctrl_handler memory.

[Severity: High]
Does using a non-synchronous cancel here lead to a use-after-free?

If probe fails late in the process, the prematurely registered subdevice
could have already received an s_edid ioctl, which schedules
hpd_delayed_work. If cancel_delayed_work() is used instead of the
synchronous variant, the work function can execute concurrently while the
driver destroys it6625_lock and frees the it6625 structure, causing a crash.

[ ... ]
> +static void it6625_remove(struct i2c_client *client)
> +{
> +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
> +	struct it6625 *it6625 = sd_to_6625(sd);
> +
> +	if (client->irq)
> +		disable_irq(client->irq);
> +	else
> +		timer_shutdown_sync(&it6625->timer);
> +
> +	cancel_work_sync(&it6625->polling_work);
> +	cancel_delayed_work_sync(&it6625->hpd_delayed_work);
> +	debugfs_remove_recursive(it6625->debugfs_dir);
> +	cec_unregister_adapter(it6625->cec_adap);
> +	v4l2_async_unregister_subdev(sd);

[Severity: High]
Is it safe to cancel the background work before unregistering the subdevice?

Since the subdevice is still actively registered when
cancel_delayed_work_sync() is called, an ioctl like s_edid can immediately
call it6625_enable_hpd() and reschedule the canceled work. When remove()
finishes and frees the it6625 structure, the rescheduled work will
subsequently dereference freed memory.

[ ... ]
> +static const struct i2c_device_id it6625_id[] = {
> +	{ "it6625", IT6625_CHIP },
> +	{ "it6626", IT6626_CHIP },
> +	{}
> +};

[Severity: Low]
Would it be better to use C99 designated initializers here?

Using positional initialization relies on the exact member order in
struct i2c_device_id.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-upstream-it6625-it6626-v1-0-475912f74459@ite.com.tw?part=2