Linux Kernel EMAC EUVD-2026-67490

Exploitation requires the target system to run Linux with the IBM EMAC network driver on compatible PowerPC-based embedded or SoC hardware. The race window exists only during emac_probe() execution - specifically in the interval after devm_request_irq() registers the interrupt handler but before devm_platform_ioremap_resource() maps dev->emacp - which typically spans only milliseconds. An EMAC hardware interrupt must be delivered within this window, which can be triggered by an incoming Ethernet frame on the physical interface. Systems that have already completed driver initialization are entirely unaffected; the vulnerability cannot be triggered during normal runtime operation. Key limiting factors include: the extremely narrow and non-repeatable timing window during probe only; requirement for EMAC-equipped PowerPC-based hardware (not general-purpose x86 or ARM systems); and the inability of a remote attacker to precisely control interrupt delivery timing, making reliable exploitation dependent on opportunistic conditions such as simultaneous boot and active network traffic.

The official CVSS base score of 7.5 with vector AV:N/AC:L/PR:N/UI:N overstates practical exploitability for this vulnerability. The race window exists solely during the execution of emac_probe() - a kernel initialization phase that typically spans only milliseconds - and successfully triggering it requires a hardware interrupt to arrive during that precise interval, which in practice demands either unlucky boot-time timing or deliberate frame-flooding of the network interface during driver load. This is far better characterized as AC:H than AC:L, and the EPSS score of 0.17% at the 6th percentile is consistent with that assessment. There is no CISA KEV listing and no public exploit code has been identified at time of analysis, meaning the risk is almost entirely theoretical. The impact is purely an availability denial (kernel panic or reboot) with zero confidentiality or integrity consequences. Critically, the EMAC driver is specific to IBM PowerPC-based embedded hardware - not the general x86/ARM server or cloud fleet - so the realistic exposed population is narrow and largely in legacy or specialized industrial deployments. The combination of low EPSS, no KEV listing, niche hardware target, and a narrow exploitable timing window makes this a low operational priority for most organizations despite the elevated CVSS score; patching should proceed on the normal kernel update cycle rather than as an emergency response.

An attacker or a network peer sends Ethernet frames to the target system's EMAC-connected interface precisely during kernel boot or EMAC driver module reload, when emac_probe() has registered the interrupt handler but has not yet mapped dev->emacp. The resulting hardware interrupt invokes emac_irq(), which dereferences the NULL pointer and triggers a kernel panic, causing an immediate system crash or reboot. No public exploit code exists, and reliably timing this race from a remote network position is highly non-trivial given the millisecond-scale initialization window.