CVE-2026-45844

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: arp_tables: fix IEEE1394 ARP payload parsing<br /> <br /> Weiming Shi says:<br /> <br /> "arp_packet_match() unconditionally parses the ARP payload assuming two<br /> hardware addresses are present (source and target). However,<br /> IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address<br /> field, and arp_hdr_len() already accounts for this by returning a<br /> shorter length for ARPHRD_IEEE1394 devices.<br /> <br /> As a result, on IEEE1394 interfaces arp_packet_match() advances past a<br /> nonexistent target hardware address and reads the wrong bytes for both<br /> the target device address comparison and the target IP address. This<br /> causes arptables rules to match against garbage data, leading to<br /> incorrect filtering decisions: packets that should be accepted may be<br /> dropped and vice versa.<br /> <br /> The ARP stack in net/ipv4/arp.c (arp_create and arp_process) already<br /> handles this correctly by skipping the target hardware address for<br /> ARPHRD_IEEE1394. Apply the same pattern to arp_packet_match()."<br /> <br /> Mangle the original patch to always return 0 (no match) in case user<br /> matches on the target hardware address which is never present in<br /> IEEE1394.<br /> <br /> Note that this returns 0 (no match) for either normal and inverse match<br /> because matching in the target hardware address in ARPHRD_IEEE1394 has<br /> never been supported by arptables. This is intentional, matching on the<br /> target hardware address should never evaluate true for ARPHRD_IEEE1394.<br /> <br /> Moreover, adjust arpt_mangle to drop the packet too as AI suggests:<br /> <br /> In arpt_mangle, the logic assumes a standard ARP layout. Because<br /> IEEE1394 (FireWire) omits the target hardware address, the linear<br /> pointer arithmetic miscalculates the offset for the target IP address.<br /> This causes mangling operations to write to the wrong location, leading<br /> to packet corruption. To ensure safety, this patch drops packets<br /> (NF_DROP) when mangling is requested for these fields on IEEE1394<br /> devices, as the current implementation cannot correctly map the FireWire<br /> ARP payload.<br /> <br /> This omits both mangling target hardware and IP address. Even if IP<br /> address mangling should be possible in IEEE1394, this would require<br /> to adjust arpt_mangle offset calculation, which has never been<br /> supported.<br /> <br /> Based on patch from Weiming Shi .