CVE-2024-26600 - Linux Kernel phy-omap-usb2 NULL Pointer Vulnerability—How It Happens, Exploitation, and the Simple Fix
A critical security flaw, CVE-2024-26600, has been discovered and resolved in the Linux kernel, impacting the phy-omap-usb2 driver. This bug could lead to a NULL pointer dereference, possibly crashing systems, particularly when a USB Ethernet gadget is running and an external PHY (Physical Layer) device that does not implement certain methods is used.
In plain language, if your hardware setup triggers the bug, the Linux kernel could panic and crash unexpectedly, leading to denial of service. In this post, we’ll break down what the problem is, show you how it can be triggered, walk through example stack traces and code snippets, and explain the remediation.
What’s the Bug?
The Linux kernel uses PHY drivers for USB interfaces on platforms like Texas Instruments (TI) OMAP-based systems. The function calls for SRP (Session Request Protocol) rely on methods (functions) that may or may not be defined by the external PHY driver.
Key Point:
The kernel code can (accidentally) try to call send_srp() or set_vbus(), even if those functions weren't set — if they're missing in the external PHY, you'll end up calling a NULL pointer. This is a classic cause for a kernel crash.
Here’s an actual log/stack trace for the crash
configfs-gadget.g1 gadget.: ECM Suspend
configfs-gadget.g1 gadget.: Port suspended. Triggering wakeup
...
Unable to handle kernel NULL pointer dereference at virtual address
00000000 when execute
...
PC is at x
LR is at musb_gadget_wakeup+x1d4/x254 [musb_hdrc]
...
musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+x1c/x3c [udc_core]
usb_gadget_wakeup [udc_core] from eth_start_xmit+x3b/x3d4 [u_ether]
eth_start_xmit [u_ether] from dev_hard_start_xmit+x94/x24c
dev_hard_start_xmit from sch_direct_xmit+x104/x2e4
sch_direct_xmit from __dev_queue_xmit+x334/xd88
__dev_queue_xmit from arp_solicit+xf/x268
...
Here is a simplified example of what the vulnerable kernel code might look like (pre-fix)
struct usb_phy {
int (*send_srp)(struct usb_phy *);
int (*set_vbus)(struct usb_phy *, int);
// Other members...
};
void omap_usb2_wakeup(struct usb_phy *phy)
{
// The bug: These were called without checks!
phy->send_srp(phy);
phy->set_vbus(phy, 1);
}
If either function pointer is NULL (that is, not implemented), the kernel dereferences a NULL, leading to an oops (crash).
How Could It Be Exploited?
While this is primarily a stability/availability bug and doesn't allow remote code execution or privilege escalation by itself, it is important for two reasons:
- Denial of Service (DoS): An attacker (or buggy software) could make the kernel panic by simply triggering a gadget wakeup (possible without special privileges in some systems).
- Embedded Systems: Devices like routers or industrial controllers using these TI OMAP chips could be knocked offline if they run into this condition, even without a direct attacker.
The fix is to check for NULL before calling function pointers
void omap_usb2_wakeup(struct usb_phy *phy)
{
// FIX: Only call if the function pointers are valid.
if (phy->send_srp)
phy->send_srp(phy);
if (phy->set_vbus)
phy->set_vbus(phy, 1);
}
This small change prevents the kernel from crashing due to missing function implementations.
Patch and References
The fix is now present in recent Linux kernel mainline releases and stable trees.
Upstream Patch:
Linux kernel commit c9c1fdda1ce49eb5
CVE Entry:
LKML Discussion:
Linux Kernel Mailing List Patch Discussion
Conclusion & Mitigation
If you run hardware or custom Linux flavors using the Texas Instruments OMAP USB2 PHY driver, update your kernel as soon as possible to pull in the fix for CVE-2024-26600. The fix is simple, the risk in affected systems is total loss of functionality until reboot, and the vulnerability could be poked accidentally by network or gadget activity.
Bottom line: Always check function pointers before calling them in kernel code!
Stay safe, and keep your Linux kernels secure.
*Exclusive content by AI, tailored for clarity. For further reading, visit the official patch commit or NVD CVE-2024-26600 entry.*
Timeline
Published on: 02/26/2024 16:27:59 UTC
Last modified on: 04/17/2024 18:29:25 UTC