CVE-2026-31736

What it actually does

This is a Linux kernel denial-of-service flaw in the MediaTek Ethernet packet processing engine path. On affected systems where GMAC0 is disabled, the driver can dereference a NULL net_device pointer while checking whether an ingress device is valid. A local user able to trigger the affected networking path can cause a kernel oops or panic, resulting in loss of system availability. The issue does not provide confidentiality or integrity impact based on the provided scoring, and exploitation requires local privileges.

Why it matters to the business

Successful exploitation can crash affected Linux systems, including embedded, networking, or appliance-style devices using MediaTek Ethernet hardware, causing service interruption until the system is restarted or recovers. The current EPSS is very low, has not trended upward over 30 days, there is no known KEV listing, and no public exploit maturity is reported, so broad active exploitation is not indicated; however, the operational impact can still be significant for systems where uptime is critical.

How an attack unfolds

An attacker first needs local access to a vulnerable Linux system with the affected MediaTek Ethernet driver configuration, specifically a configuration where GMAC0 is disabled and the mtk_ppe ingress-device validation path can be reached. The attacker then generates or routes local network activity that causes the kernel to evaluate the ingress device. Because the driver assumes eth->netdev[0] is valid and accesses netdev_ops without first confirming the pointer is non-NULL, the kernel dereferences a NULL pointer. This causes a kernel fault and can crash or panic the system, denying service to users and dependent workloads.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the upstream fix for the MediaTek mtk_ppe NULL pointer dereference when GMAC0 is disabled. No specific fixed package versions were provided in the input, so use the distribution, device vendor, or appliance maintainer advisory as the source of truth for the corrected kernel build. After updating, reboot into the patched kernel and remove or disable boot entries for vulnerable kernels where operationally appropriate. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted users, disabling unnecessary local accounts, and reviewing whether the affected MediaTek PPE/offload driver path or GMAC0-disabled configuration can be avoided without disrupting service.

How to confirm the fix worked

Confirm the running kernel is the patched vendor build, not merely that the package is installed. Validate with kernel package inventory and runtime checks such as uname -a, package manager output, and the vendor advisory’s fixed build identifier. On affected hardware, verify whether MediaTek Ethernet/PPE components are present and whether GMAC0 is disabled in the device tree or platform configuration. Review boot logs after patching to ensure the system is running the expected kernel and that no new mtk_ppe, mtk_eth, NULL pointer dereference, oops, or panic messages appear during normal network operation. Where feasible, reproduce prior network initialization and traffic conditions in a staging environment to confirm the crash no longer occurs.

Typical attack path

1. Gain local authenticated access to an affected Linux system.
2. Confirm or rely on the system using the vulnerable MediaTek Ethernet driver path with GMAC0 disabled.
3. Trigger network activity that reaches the mtk_ppe ingress-device validation logic.
4. Cause the kernel to dereference a NULL net_device pointer while accessing netdev_ops.
5. Crash the kernel or cause a kernel oops/panic, resulting in denial of service.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, persistent journal entries, crash dumps, console logs, and device/appliance monitoring for kernel oops or panic events around times of unexplained reboots or network disruption. Useful sources include dmesg output, systemd journal kernel records, /var/log/kern.log, /var/log/messages, /var/crash, kdump/vmcore artifacts, appliance serial-console logs, watchdog reset logs, and network-device health telemetry. Focus on crashes containing NULL pointer dereference language and stack traces or module references involving mtk_ppe, mtk_eth, MediaTek Ethernet, net_device, or netdev_ops. Correlate crash times with local login/session records and commands from untrusted users, because the assessed attack vector is local. Absence of these artifacts does not prove absence of exploitation if logs were volatile or lost during panic/reboot.

• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops: 0000
• mtk_ppe
• mtk_eth
• netdev_ops
• net_device
• gmac0
• GMAC0
• /var/log/kern.log
• /var/log/messages
• /var/crash
• /proc/vmcore

What your security team should do

• Prioritize patching affected Linux systems that use MediaTek Ethernet hardware and are configured with GMAC0 disabled, especially routers, gateways, appliances, and other uptime-sensitive systems.
• Confirm whether any deployed kernels include the vulnerable mtk_ppe code path by checking hardware inventory, kernel configuration, device tree settings, and vendor advisories.
• Restrict local access on potentially affected systems until patched, because exploitation requires local privileges according to the provided CVSS vector.
• Monitor kernel logs and crash telemetry for NULL pointer dereference, oops, or panic events referencing mtk_ppe, mtk_eth, net_device, or netdev_ops.
• Because the CVE is not in KEV, has no reported ransomware use, and has a very low stable EPSS, handle through normal kernel maintenance timelines unless affected systems are highly critical or repeatedly crashing.
• Ensure rollback procedures do not reintroduce vulnerable kernels after remediation.