NULL Pointer Dereference Affecting kernel-64k-modules-partner 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-KERNEL64KMODULESPARTNER-6274619
- published25 Feb 2024
- disclosed24 Feb 2024
Introduced: 24 Feb 2024
CVE-2024-26600 (opens in a new tab)How to fix?
There is no fixed version for Centos:9 kernel-64k-modules-partner.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-64k-modules-partner package and not the kernel-64k-modules-partner 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:
phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP
If the external phy working together with phy-omap-usb2 does not implement send_srp(), we may still attempt to call it. This can happen on an idle Ethernet gadget triggering a wakeup for example:
configfs-gadget.g1 gadget.0: ECM Suspend configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup ... Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute ... PC is at 0x0 LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc] ... musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core] usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether] eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4 sch_direct_xmit from __dev_queue_xmit+0x334/0xd88 __dev_queue_xmit from arp_solicit+0xf0/0x268 arp_solicit from neigh_probe+0x54/0x7c neigh_probe from __neigh_event_send+0x22c/0x47c __neigh_event_send from neigh_resolve_output+0x14c/0x1c0 neigh_resolve_output from ip_finish_output2+0x1c8/0x628 ip_finish_output2 from ip_send_skb+0x40/0xd8 ip_send_skb from udp_send_skb+0x124/0x340 udp_send_skb from udp_sendmsg+0x780/0x984 udp_sendmsg from __sys_sendto+0xd8/0x158 __sys_sendto from ret_fast_syscall+0x0/0x58
Let's fix the issue by checking for send_srp() and set_vbus() before calling them. For USB peripheral only cases these both could be NULL.
References
- https://access.redhat.com/security/cve/CVE-2024-26600
- https://git.kernel.org/stable/c/0430bfcd46657d9116a26cd377f112cbc40826a4
- https://git.kernel.org/stable/c/14ef61594a5a286ae0d493b8acbf9eac46fd04c4
- https://git.kernel.org/stable/c/396e17af6761b3cc9e6e4ca94b4de7f642bfece1
- https://git.kernel.org/stable/c/486218c11e8d1c8f515a3bdd70d62203609d4b6b
- https://git.kernel.org/stable/c/7104ba0f1958adb250319e68a15eff89ec4fd36d
- https://git.kernel.org/stable/c/8398d8d735ee93a04fb9e9f490e8cacd737e3bf5
- https://git.kernel.org/stable/c/8cc889b9dea0579726be9520fcc766077890b462
- https://git.kernel.org/stable/c/be3b82e4871ba00e9b5d0ede92d396d579d7b3b3
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html