CVE-2026-45844

What it actually does

This is a Linux kernel netfilter/arptables parsing flaw affecting ARP handling on IEEE1394/FireWire interfaces. The vulnerable code assumes a standard ARP payload containing both source and target hardware addresses, but IPv4-over-IEEE1394 ARP omits the target hardware address. As a result, arptables matching and mangling logic can read or write at incorrect offsets, causing rules to evaluate against invalid packet data or corrupt packets. The primary technical consequence is incorrect ARP filtering or packet drops on affected interfaces, creating a local availability impact and possible unintended network policy behavior for FireWire ARP traffic. The issue does not indicate remote code execution or direct data disclosure.

Why it matters to the business

Systems using Linux kernels with IEEE1394/FireWire networking and arptables rules may make incorrect network filtering decisions or drop/corrupt ARP traffic, potentially disrupting connectivity for niche but operationally sensitive environments that still rely on FireWire networking. The risk is lower for most modern server and cloud environments because IEEE1394 interfaces are uncommon, EPSS is very low, the vulnerability is not in CISA KEV, and no public exploit maturity is reported. However, organizations with legacy industrial, media, lab, embedded, or specialized hardware using FireWire should treat this as a reliability and network-control issue and patch during the next appropriate kernel maintenance window.

How an attack unfolds

An attacker first needs local access or access to a path where they can influence ARP traffic on an IEEE1394/FireWire network interface. They identify that the host is running a vulnerable Linux kernel and that arptables rules are applied to ARP traffic on the IEEE1394 interface, especially rules matching or mangling target hardware or target IP fields. The attacker then sends IPv4-over-IEEE1394 ARP packets whose layout omits the target hardware address as defined by the protocol. The vulnerable arptables code parses the packet as if the missing field exists, causing comparisons to use the wrong bytes or mangling operations to modify the wrong packet location. Depending on the active rules, packets may be accepted when they should be blocked, dropped when they should be accepted, or corrupted and dropped, resulting primarily in denial of service or unintended ARP policy behavior. There is no indication from the provided data that this issue is being exploited in the wild or used by ransomware campaigns.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the upstream fix for netfilter arp_tables IEEE1394 ARP payload parsing. No exact fixed package versions were provided, so track vendor advisories for the affected kernel branch and verify that the patch updates arp_packet_match() and arpt_mangle() handling for ARPHRD_IEEE1394 in net/ipv4/netfilter/arp_tables.c. Where immediate patching is not possible, reduce exposure by disabling unused IEEE1394/FireWire networking, unloading or blacklisting FireWire kernel modules where operationally safe, avoiding arptables rules that match or mangle unsupported IEEE1394 ARP target hardware/IP fields, and limiting local users or services with CAP_NET_ADMIN or equivalent privileges. If FireWire is not required, disabling the interface or hardware support is an effective mitigation.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version matches a vendor release that contains the fix, not merely that an updated package is installed on disk. Check vendor changelogs or kernel source/backport notes for the netfilter arp_tables IEEE1394 ARP parsing fix. On source-based or custom kernels, inspect net/ipv4/netfilter/arp_tables.c to confirm IEEE1394 ARP handling no longer advances over a nonexistent target hardware address and that unsupported IEEE1394 mangling paths safely fail or drop as intended. Validate exposure by checking whether IEEE1394 interfaces or FireWire modules are present and whether arptables rules are configured. Functional testing, if performed in a lab, should verify that IPv4-over-IEEE1394 ARP packets are not incorrectly matched or mangled by target-hardware-address rules after the update.

Typical attack path

1. Gain local access to the system, access to the IEEE1394 network segment, or another position that allows sending ARP traffic over a FireWire interface.
2. Confirm the target uses a vulnerable Linux kernel with IEEE1394/FireWire networking enabled.
3. Identify or infer that arptables/netfilter ARP rules are active on the IEEE1394 interface, particularly rules matching or mangling ARP target hardware or target IP fields.
4. Send IPv4-over-IEEE1394 ARP packets that omit the target hardware address, which is valid for RFC 2734 traffic.
5. Trigger incorrect pointer arithmetic in arptables ARP matching or mangling logic.
6. Cause incorrect ARP filtering decisions, packet corruption, or packet drops that may disrupt network connectivity or bypass intended ARP filtering behavior.

How to detect it

There are no unique public exploitation indicators provided for this vulnerability. To investigate possible prior exploitation, focus on systems with IEEE1394/FireWire networking enabled and review kernel logs, audit logs, network configuration history, and firewall rule history. Look for unexpected FireWire device activation, loading of FireWire-related kernel modules, creation or reconfiguration of IEEE1394 interfaces, arptables rule changes, and spikes in ARP-related packet drops or connectivity failures on FireWire interfaces. Useful log sources include systemd journal, /var/log/kern.log, /var/log/messages, auditd execve records for arptables or modprobe, shell history for privileged users, endpoint telemetry for kernel module loading, and packet captures from affected IEEE1394 segments. Because the vulnerability causes incorrect parsing rather than a distinctive crash or payload signature, absence of logs does not prove absence of exploitation; correlate ARP disruption with local account activity and FireWire interface state changes.

What your security team should do

• Prioritize patching systems that have IEEE1394/FireWire hardware enabled, use IPv4-over-IEEE1394 networking, or rely on arptables ARP filtering.
• Inventory Linux systems for loaded FireWire modules, IEEE1394 network interfaces, and arptables rules; most environments without FireWire networking are unlikely to be practically exposed.
• If FireWire networking is not required, disable it at the BIOS/UEFI, kernel module, or operating-system configuration level.
• Restrict local administrative and network-configuration privileges, especially CAP_NET_ADMIN, to reduce the ability to configure or abuse arptables behavior.
• Monitor for unexpected FireWire device activation, arptables rule changes, and unusual ARP packet drops on systems where IEEE1394 remains enabled.
• Treat this as a targeted availability and network-policy reliability issue rather than a broadly exploitable remote compromise, given the low EPSS, no KEV listing, and no reported public exploit maturity.