Description
In the Linux kernel, the following vulnerability has been resolved:

netfilter: arp_tables: fix IEEE1394 ARP payload parsing

Weiming Shi says:

"arp_packet_match() unconditionally parses the ARP payload assuming two
hardware addresses are present (source and target). However,
IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address
field, and arp_hdr_len() already accounts for this by returning a
shorter length for ARPHRD_IEEE1394 devices.

As a result, on IEEE1394 interfaces arp_packet_match() advances past a
nonexistent target hardware address and reads the wrong bytes for both
the target device address comparison and the target IP address. This
causes arptables rules to match against garbage data, leading to
incorrect filtering decisions: packets that should be accepted may be
dropped and vice versa.

The ARP stack in net/ipv4/arp.c (arp_create and arp_process) already
handles this correctly by skipping the target hardware address for
ARPHRD_IEEE1394. Apply the same pattern to arp_packet_match()."

Mangle the original patch to always return 0 (no match) in case user
matches on the target hardware address which is never present in
IEEE1394.

Note that this returns 0 (no match) for either normal and inverse match
because matching in the target hardware address in ARPHRD_IEEE1394 has
never been supported by arptables. This is intentional, matching on the
target hardware address should never evaluate true for ARPHRD_IEEE1394.

Moreover, adjust arpt_mangle to drop the packet too as AI suggests:

In arpt_mangle, the logic assumes a standard ARP layout. Because
IEEE1394 (FireWire) omits the target hardware address, the linear
pointer arithmetic miscalculates the offset for the target IP address.
This causes mangling operations to write to the wrong location, leading
to packet corruption. To ensure safety, this patch drops packets
(NF_DROP) when mangling is requested for these fields on IEEE1394
devices, as the current implementation cannot correctly map the FireWire
ARP payload.

This omits both mangling target hardware and IP address. Even if IP
address mangling should be possible in IEEE1394, this would require
to adjust arpt_mangle offset calculation, which has never been
supported.

Based on patch from Weiming Shi <bestswngs@gmail.com>.
Published: 2026-05-27
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability arises because arp_packet_match unconditionally parses an IEEE1394 ARP packet assuming a target hardware address exists, which RFC 2734 specifies should be omitted. As a result, the function advances past a nonexistent field and reads incorrect bytes for both the target hardware and IP addresses. This leads arptables rules to match against garbage data, causing legitimate packets to be dropped or unwanted packets to pass, thereby compromising traffic filtering.

Affected Systems

All Linux kernel builds that ship with arptables running on ARPHRD_IEEE1394 (FireWire) interfaces are affected. Any kernel version prior to the patch that includes the unmodified arp_packet_match implementation is vulnerable. The issue is specific to the IEEE1394 interface type and does not affect Ethernet or other hardware address families.

Risk and Exploitability

The CVSS score is not provided, and EPSS is unavailable, but the defect is not listed in CISA’s KEV catalog. The attack vector is likely local or through firewire-based network access, as the flaw requires crafting ARP packets on an IEEE1394 interface. A local attacker with the ability to send malformed ARP traffic could exploit the bug to disrupt filtering decisions, effectively causing denial of service for legitimate traffic. No public exploit is documented, but the potential for packet loss or incorrect acceptance warrants prompt remediation.

Generated by OpenCVE AI on May 27, 2026 at 11:42 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the Linux kernel or apply the official patch that adjusts arp_packet_match to account for IEEE1394 ARP payloads and drops packets when mangling is requested on unsupported fields.
  • Reconfigure or disable arptables rules that match on target hardware address for ARPHRD_IEEE1394 devices, as such matches are always false and may cause confusion.
  • If a patch cannot be applied immediately, temporarily disable ARP filtering on all IEEE1394 interfaces to prevent unintended packet drops until remediation is completed.

Generated by OpenCVE AI on May 27, 2026 at 11:42 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 27 May 2026 12:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-20

Wed, 27 May 2026 10:30:00 +0000

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

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-27T09:24:47.041Z

Reserved: 2026-05-13T15:03:33.078Z

Link: CVE-2026-45844

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-05-27T11:16:23.847

Modified: 2026-05-27T11:16:23.847

Link: CVE-2026-45844

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-05-27T11:45:15Z

Weaknesses

No weakness.