CVE-2024-26827: i2c: qcom-geni: Correct I2C TRE sequence

CVE-2024-26827: i2c: qcom-geni: Correct I2C TRE sequence

[Greg Kroah-Hartman]

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

i2c: qcom-geni: Correct I2C TRE sequence

For i2c read operation in GSI mode, we are getting timeout
due to malformed TRE basically incorrect TRE sequence
in gpi(drivers/dma/qcom/gpi.c) driver.

I2C driver has geni_i2c_gpi(I2C_WRITE) function which generates GO TRE and
geni_i2c_gpi(I2C_READ)generates DMA TRE. Hence to generate GO TRE before
DMA TRE, we should move geni_i2c_gpi(I2C_WRITE) before
geni_i2c_gpi(I2C_READ) inside the I2C GSI mode transfer function
i.e. geni_i2c_gpi_xfer().

TRE stands for Transfer Ring Element - which is basically an element with
size of 4 words. It contains all information like slave address,
clk divider, dma address value data size etc).

Mainly we have 3 TREs(Config, GO and DMA tre).
- CONFIG TRE : consists of internal register configuration which is
               required before start of the transfer.
- DMA TRE :    contains DDR/Memory address, called as DMA descriptor.
- GO TRE :     contains Transfer directions, slave ID, Delay flags, Length
               of the transfer.

I2c driver calls GPI driver API to config each TRE depending on the
protocol.

For read operation tre sequence will be as below which is not aligned
to hardware programming guide.

- CONFIG tre
- DMA tre
- GO tre

As per Qualcomm's internal Hardware Programming Guide, we should configure
TREs in below sequence for any RX only transfer.

- CONFIG tre
- GO tre
- DMA tre

The Linux kernel CVE team has assigned CVE-2024-26827 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.18 with commit d8703554f4de and fixed in 6.1.79 with commit 083870b029c0
	Issue introduced in 5.18 with commit d8703554f4de and fixed in 6.6.18 with commit 0589dff4fbf4
	Issue introduced in 5.18 with commit d8703554f4de and fixed in 6.7.6 with commit 9318483e99f2
	Issue introduced in 5.18 with commit d8703554f4de and fixed in 6.8 with commit 83ef106fa732

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-26827
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/i2c/busses/i2c-qcom-geni.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/083870b029c06da6a9a49340dd78637eec35a1d4
	https://git.kernel.org/stable/c/0589dff4fbf4a7b88a909a34ecfa7b5d3daf51f5
	https://git.kernel.org/stable/c/9318483e99f242ec4059e2fa20887e1d28efd5ae
	https://git.kernel.org/stable/c/83ef106fa732aea8558253641cd98e8a895604d7

Re: CVE-2024-26827: i2c: qcom-geni: Correct I2C TRE sequence

[Greg Kroah-Hartman]

On Thu, Apr 18, 2024 at 02:56:33PM +0200, Jean Delvare wrote:
> Hi Greg,
> 
> On Wed, 2024-04-17 at 11:44 +0200, Greg Kroah-Hartman wrote:
> > Description
> > ===========
> > 
> > In the Linux kernel, the following vulnerability has been resolved:
> > 
> > i2c: qcom-geni: Correct I2C TRE sequence
> > 
> > For i2c read operation in GSI mode, we are getting timeout
> > due to malformed TRE basically incorrect TRE sequence
> > in gpi(drivers/dma/qcom/gpi.c) driver.
> > (...)
> 
> I was assigned the task to backport this security fix to the SUSE
> kernels. However, from the description, I fail to see how this fix
> qualifies as a security fix. I can't find the reason why a CVE was
> assigned to the issue.
> 
> What is the considered attack vector? Or if there is no attack vector,
> what consequence does this bug have, which would put the system
> security at stake?

We reviewed this commit as fitting the fact that timeouts due to
malformed messages would fit into the definition of "vulnerability" in
the CVE world as it would cause a system to incure "negative impact to
confidentiality, integrity, or availability".

If as the i2c maintainer, you don't think this would be the case, we
will be glad to revoke this CVE and just mark it down as a "normal
bugfix".

> From my perspective, all we have here is a functional bug in newly
> introduced code. It's not even a regression.

Regressions are not an issue for CVE assignments :(

thanks,

greg k-h