NULL Pointer Dereference Affecting kernel-devel 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-CENTOS7-KERNELDEVEL-7912523
- published5 Sept 2024
- disclosed4 Sept 2024
Introduced: 4 Sep 2024
CVE-2024-45006 (opens in a new tab)How to fix?
There is no fixed version for Centos:7 kernel-devel.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-devel package and not the kernel-devel package as distributed by Centos.
See How to fix? for Centos:7 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration
re-enumerating full-speed devices after a failed address device command can trigger a NULL pointer dereference.
Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size value during enumeration. Usb core calls usb_ep0_reinit() in this case, which ends up calling xhci_configure_endpoint().
On Panther point xHC the xhci_configure_endpoint() function will additionally check and reserve bandwidth in software. Other hosts do this in hardware
If xHC address device command fails then a new xhci_virt_device structure is allocated as part of re-enabling the slot, but the bandwidth table pointers are not set up properly here. This triggers the NULL pointer dereference the next time usb_ep0_reinit() is called and xhci_configure_endpoint() tries to check and reserve bandwidth
[46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd [46710.713699] usb 3-1: Device not responding to setup address. [46710.917684] usb 3-1: Device not responding to setup address. [46711.125536] usb 3-1: device not accepting address 5, error -71 [46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008 [46711.125600] #PF: supervisor read access in kernel mode [46711.125603] #PF: error_code(0x0000) - not-present page [46711.125606] PGD 0 P4D 0 [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1 [46711.125620] Hardware name: Gigabyte Technology Co., Ltd. [46711.125623] Workqueue: usb_hub_wq hub_event [usbcore] [46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c
Fix this by making sure bandwidth table pointers are set up correctly after a failed address device command, and additionally by avoiding checking for bandwidth in cases like this where no actual endpoints are added or removed, i.e. only context for default control endpoint 0 is evaluated.
References
- https://access.redhat.com/security/cve/CVE-2024-45006
- https://git.kernel.org/stable/c/0f0654318e25b2c185e245ba4a591e42fabb5e59
- https://git.kernel.org/stable/c/365ef7c4277fdd781a695c3553fa157d622d805d
- https://git.kernel.org/stable/c/5ad898ae82412f8a689d59829804bff2999dd0ea
- https://git.kernel.org/stable/c/6b99de301d78e1f5249e57ef2c32e1dec3df2bb1
- https://git.kernel.org/stable/c/8fb9d412ebe2f245f13481e4624b40e651570cbd
- https://git.kernel.org/stable/c/a57b0ebabe6862dce0a2e0f13e17941ad72fc56b
- https://git.kernel.org/stable/c/af8e119f52e9c13e556be9e03f27957554a84656
- https://git.kernel.org/stable/c/ef0a0e616b2789bb804a0ce5e161db03170a85b6