NULL Pointer Dereference Affecting kernel-cross-headers package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
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 applicationsSnyk Learn
Learn about NULL Pointer Dereference vulnerabilities in an interactive lesson.
Start learning- Snyk IDSNYK-CENTOS9-KERNELCROSSHEADERS-7180052
- published3 Jun 2024
- disclosed30 May 2024
Introduced: 30 May 2024
CVE-2024-36930 (opens in a new tab)How to fix?
There is no fixed version for Centos:9 kernel-cross-headers.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-cross-headers package and not the kernel-cross-headers package as distributed by Centos.
See How to fix? for Centos:9 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
spi: fix null pointer dereference within spi_sync
If spi_sync() is called with the non-empty queue and the same spi_message is then reused, the complete callback for the message remains set while the context is cleared, leading to a null pointer dereference when the callback is invoked from spi_finalize_current_message().
With function inlining disabled, the call stack might look like this:
_raw_spin_lock_irqsave from complete_with_flags+0x18/0x58 complete_with_flags from spi_complete+0x8/0xc spi_complete from spi_finalize_current_message+0xec/0x184 spi_finalize_current_message from spi_transfer_one_message+0x2a8/0x474 spi_transfer_one_message from __spi_pump_transfer_message+0x104/0x230 __spi_pump_transfer_message from __spi_transfer_message_noqueue+0x30/0xc4 __spi_transfer_message_noqueue from __spi_sync+0x204/0x248 __spi_sync from spi_sync+0x24/0x3c spi_sync from mcp251xfd_regmap_crc_read+0x124/0x28c [mcp251xfd] mcp251xfd_regmap_crc_read [mcp251xfd] from _regmap_raw_read+0xf8/0x154 _regmap_raw_read from _regmap_bus_read+0x44/0x70 _regmap_bus_read from _regmap_read+0x60/0xd8 _regmap_read from regmap_read+0x3c/0x5c regmap_read from mcp251xfd_alloc_can_err_skb+0x1c/0x54 [mcp251xfd] mcp251xfd_alloc_can_err_skb [mcp251xfd] from mcp251xfd_irq+0x194/0xe70 [mcp251xfd] mcp251xfd_irq [mcp251xfd] from irq_thread_fn+0x1c/0x78 irq_thread_fn from irq_thread+0x118/0x1f4 irq_thread from kthread+0xd8/0xf4 kthread from ret_from_fork+0x14/0x28
Fix this by also setting message->complete to NULL when the transfer is complete.
References
- https://access.redhat.com/security/cve/CVE-2024-36930
- https://git.kernel.org/stable/c/2070d008cc08bff50a58f0f4d30f12d3ebf94c00
- https://git.kernel.org/stable/c/4756fa529b2f12b7cb8f21fe229b0f6f47190829
- https://git.kernel.org/stable/c/a30659f1576d2c8e62e7426232bb18b885fd951a
- https://git.kernel.org/stable/c/e005d6754e3e440257006795b687c4ad8733b493