CVE-2024-26807 Affecting kernel-default-devel package, versions <5.14.21-150500.55.62.2


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.05% (18th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-SLES155-KERNELDEFAULTDEVEL-6858568
  • published16 May 2024
  • disclosed15 May 2024

Introduced: 15 May 2024

CVE-2024-26807  (opens in a new tab)

How to fix?

Upgrade SLES:15.5 kernel-default-devel to version 5.14.21-150500.55.62.2 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-default-devel package and not the kernel-default-devel package as distributed by SLES. See How to fix? for SLES:15.5 relevant fixed versions and status.

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

Both cadence-quadspi ->runtime_suspend() and ->runtime_resume() implementations start with:

struct cqspi_st *cqspi = dev_get_drvdata(dev);
struct spi_controller *host = dev_get_drvdata(dev);

This obviously cannot be correct, unless "struct cqspi_st" is the first member of " struct spi_controller", or the other way around, but it is not the case. "struct spi_controller" is allocated by devm_spi_alloc_host(), which allocates an extra amount of memory for private data, used to store "struct cqspi_st".

The ->probe() function of the cadence-quadspi driver then sets the device drvdata to store the address of the "struct cqspi_st" structure. Therefore:

struct cqspi_st *cqspi = dev_get_drvdata(dev);

is correct, but:

struct spi_controller *host = dev_get_drvdata(dev);

is not, as it makes "host" point not to a "struct spi_controller" but to the same "struct cqspi_st" structure as above.

This obviously leads to bad things (memory corruption, kernel crashes) directly during ->probe(), as ->probe() enables the device using PM runtime, leading the ->runtime_resume() hook being called, which in turns calls spi_controller_resume() with the wrong pointer.

This has at least been reported [0] to cause a kernel crash, but the exact behavior will depend on the memory contents.

[0] https://lore.kernel.org/all/20240226121803.5a7r5wkpbbowcxgx@dhruva/

This issue potentially affects all platforms that are currently using the cadence-quadspi driver.

CVSS Scores

version 3.1