Messages in this thread | | | Subject | Re: CVE-2024-26827: i2c: qcom-geni: Correct I2C TRE sequence | From | Jean Delvare <> | Date | Thu, 18 Apr 2024 16:44:33 +0200 |
| |
On Thu, 2024-04-18 at 15:05 +0200, Greg Kroah-Hartman wrote: > 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 the timeout could be triggered on purpose, then I would agree, as this could possibly be used for a denial-of-service type of attack. But this isn't the case here.
All we have is a failure to read data from a random I2C device due to an incorrect programming of the I2C controller. Simple lack of functionality.
> 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".
Yes, please.
-- Jean Delvare SUSE L3 Support
| |