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

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

[Jean Delvare]

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?

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


-- 
Jean Delvare
SUSE L3 Support

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

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

[Jean Delvare]

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

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

[Greg Kroah-Hartman]

On Thu, Apr 18, 2024 at 04:44:33PM +0200, Jean Delvare wrote:
> 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.

Thanks for the explaination and looking into it.

> > 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.

Now rejected, thanks for letting us know.

greg k-h