CVE-2026-43173

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel Ethernet driver for Intel/IXP4xx XScale platforms. The affected driver calls the PTP timestamp support lookup routine unconditionally from the ethtool timestamp information path, even on hardware variants that do not support that PTP feature. On unsupported ixp4xx systems, a local user who can issue the relevant network device ioctl through tools such as ethtool or tcpdump can trigger a NULL pointer dereference in kernel context, causing an oops, process failure, or potentially a kernel panic depending on system configuration. The impact is availability loss only; the described flaw does not provide confidentiality or integrity compromise.

Why it matters to the business

Systems using affected Linux kernels on ixp4xx/XScale Ethernet hardware can be crashed or destabilized by a local user or by software that queries network timestamping capabilities. This can interrupt embedded routing, firewalling, packet capture, monitoring, or network appliance functions. The risk is narrower than a remote internet-facing vulnerability because exploitation requires local privileges and specific hardware/driver exposure, and current EPSS is very low with no known KEV listing or public exploit maturity; however, affected embedded devices may be operationally sensitive and harder to patch quickly.

How an attack unfolds

An attacker first needs local access to an affected Linux system with the ixp4xx Ethernet driver active on hardware that lacks the ixp46x PTP feature. The attacker then invokes a code path that requests Ethernet timestamping information, commonly through an ioctl issued by tools such as tcpdump, ethtool, or a custom local program. The kernel enters the ethtool timestamp query path, calls ixp4xx_get_ts_info(), and then incorrectly calls ixp46x_ptp_find() without first verifying that the platform supports ixp46x PTP. Because the required PTP structure is absent, the driver dereferences a NULL pointer around ptp_clock_index, producing a kernel oops and potentially a system panic or service disruption.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the ixp4xx Ethernet PTP support check. Because no exact fixed package versions were provided, use the fixed kernel versions supplied by the relevant Linux distribution, embedded firmware vendor, OpenWrt build, BSP provider, or device manufacturer. Where immediate kernel replacement is not possible, reduce exposure by limiting local shell access, restricting who can run packet capture and network diagnostic tools, disabling or removing the affected ixp4xx Ethernet driver if not required, and avoiding automated jobs that query timestamping capabilities on affected interfaces. Mitigations should be treated as temporary; the durable fix is a patched kernel.

How to confirm the fix worked

Confirm the running kernel or firmware includes the patch that checks for ixp46x support before PTP setup in ixp46x_ptp_find() / ixp4xx_get_ts_info(). Validate by reviewing vendor advisories, kernel changelogs, package metadata, or source patches for the ixp4xx Ethernet driver. On a non-production test system with matching hardware, run timestamp capability queries such as ethtool -T <interface> or packet capture commands that previously triggered the fault, and verify that the system returns an unsupported-operation response rather than logging a NULL pointer dereference or crashing. Also verify that kernel logs no longer contain the affected call trace after testing.

Typical attack path

1. Obtain local user-level access to an affected Linux system using the ixp4xx Ethernet driver.
2. Identify an active ixp4xx Ethernet interface, such as eth0.
3. Run a tool or program that requests timestamping information for the interface, for example packet capture or ethtool timestamp queries.
4. Trigger the vulnerable ioctl path through dev_ethtool / __ethtool_get_ts_info / ixp4xx_get_ts_info.
5. Cause ixp46x_ptp_find() to dereference a missing PTP object on unsupported hardware.
6. Induce a kernel oops, process crash, or system-wide denial of service depending on kernel panic settings.

How to detect it

To determine whether exploitation or accidental triggering has already occurred, review kernel logs, persistent journal entries, console logs, crash dumps, and appliance watchdog reboot records for NULL pointer dereference events involving the ixp4xx Ethernet driver. Relevant log sources include dmesg output, /var/log/kern.log, /var/log/messages, journalctl -k, pstore/ramoops records, kdump/vmcore summaries, and embedded firmware crash logs. Focus on events where packet capture, ethtool, or ioctl activity occurred shortly before a kernel oops or reboot. Look for call traces containing ptp_clock_index, ixp46x_ptp_find, ixp4xx_get_ts_info, __ethtool_get_ts_info, __dev_ethtool, dev_ethtool, dev_ioctl, sock_ioctl, or sys_ioctl. Also review command history and audit logs, if enabled, for executions of tcpdump or ethtool against ixp4xx Ethernet interfaces near the crash time. There are no known threat actors or ransomware campaigns associated with this issue based on the provided data.

• Unable to handle kernel NULL pointer dereference at virtual address 00000238
• ptp_clock_index from ixp46x_ptp_find
• ixp46x_ptp_find from ixp4xx_get_ts_info
• ixp4xx_get_ts_info from __ethtool_get_ts_info
• __ethtool_get_ts_info from __dev_ethtool
• __dev_ethtool from dev_ethtool
• dev_ethtool from dev_ioctl
• dev_ioctl from sock_ioctl
• sock_ioctl from sys_ioctl
• sys_ioctl from ret_fast_syscall
• tcpdump -vv -X -i eth0
• ethtool -T eth0
• ixp46x_ptp_find
• ixp4xx_get_ts_info
• ptp_clock_index

What your security team should do

• Inventory Linux-based embedded, router, firewall, and appliance systems that use ixp4xx/XScale Ethernet hardware or kernels containing the ixp4xx Ethernet driver.
• Prioritize patching affected systems that provide critical network connectivity, monitoring, routing, firewalling, or packet capture functions.
• Obtain fixed kernels or firmware from the relevant distribution, OpenWrt build, BSP, or hardware vendor, and deploy through the normal kernel/firmware update process.
• Until patched, restrict local interactive access and administrative tool execution to trusted users only.
• Review scheduled diagnostics, monitoring agents, and packet capture workflows that may call ethtool timestamp information paths on ixp4xx interfaces.
• Monitor kernel logs for NULL pointer dereference traces involving ixp46x_ptp_find, ixp4xx_get_ts_info, __ethtool_get_ts_info, or ptp_clock_index.
• Because EPSS is low, there is no KEV listing, and exploitation is local, handle this as a targeted availability hardening issue rather than an emergency internet-wide exploitation event unless affected devices are operationally critical.