Recent i2c-designware initialization fix

[Jean Delvare <jdelvare@suse.de>]

Hello Michael,

I have been looking into your kernel commit 3d30048958e0
("i2c/designware: Fix an initialization issue"), as it received a CVE
number (CVE-2025-38380), I was asked to evaluate the severity of the
bug.

I was not familiar with the i2c-designware driver so it took me some
reading time to form an opinion on the matter. But after a careful
review, my conclusion is that there was no actual bug in the first
place. If I'm correct then CVE-2025-38380 is invalid.

My reasoning is as follows:
* struct dw_i2c_dev is allocated per-PCI device in i2c_dw_pci_probe()
  using devm_kzalloc(), therefore all its members, including
  dev->msg_write_idx, are initialized to 0.
* The supposedly problematic code path is only taken if (dev->flags &
  MODEL_MASK) == MODEL_AMD_NAVI_GPU.
* The only place where dev->msg_write_idx is set to a non-zero value is
  in i2c_dw_xfer_msg(). This function is only called by i2c_dw_isr(),
  which in turn is only called if the device is not in polling mode.
* The flags set for the AMD Navi GPU devices are:
  dev->flags |= MODEL_AMD_NAVI_GPU | ACCESS_POLLING
  so these devices are always in polling mode and never use an
  interrupt so i2c_dw_isr() is never called for them.

If my reasoning is correct, then for the AMD Navi GPU devices,
dev->msg_write_idx is implicitly initialized to 0 at allocation time
and its value is never changed after that, so the explicit
initialization to 0 which has been added in amd_i2c_dw_xfer_quirk() is
a no-op.

What do you think? Am I missing something?

Thanks,
-- 
Jean Delvare
SUSE L3 Support