{"id":78922,"date":"2026-05-27T14:46:23","date_gmt":"2026-05-27T11:16:23","guid":{"rendered":"https:\/\/afaghhosting.net\/blog\/cve-2026-45844-netfilter-arp_tables-fix-ieee1394-arp-payload-parsing\/"},"modified":"2026-05-27T14:46:23","modified_gmt":"2026-05-27T11:16:23","slug":"cve-2026-45844-netfilter-arp_tables-fix-ieee1394-arp-payload-parsing","status":"publish","type":"post","link":"https:\/\/afaghhosting.net\/blog\/cve-2026-45844-netfilter-arp_tables-fix-ieee1394-arp-payload-parsing\/","title":{"rendered":"CVE-2026-45844 &#8211; netfilter: arp_tables: fix IEEE1394 ARP payload parsing"},"content":{"rendered":"<p>CVE ID :CVE-2026-45844<\/p>\n<p>  Published : May 27, 2026, 11:16 a.m. | 1\u00a0hour, 15\u00a0minutes ago<\/p>\n<p>  Description :In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>netfilter: arp_tables: fix IEEE1394 ARP payload parsing<\/p>\n<p>Weiming Shi says:<\/p>\n<p>&#8220;arp_packet_match() unconditionally parses the ARP payload assuming two<br \/>\nhardware addresses are present (source and target). However,<br \/>\nIPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address<br \/>\nfield, and arp_hdr_len() already accounts for this by returning a<br \/>\nshorter length for ARPHRD_IEEE1394 devices.<\/p>\n<p>As a result, on IEEE1394 interfaces arp_packet_match() advances past a<br \/>\nnonexistent target hardware address and reads the wrong bytes for both<br \/>\nthe target device address comparison and the target IP address. This<br \/>\ncauses arptables rules to match against garbage data, leading to<br \/>\nincorrect filtering decisions: packets that should be accepted may be<br \/>\ndropped and vice versa.<\/p>\n<p>The ARP stack in net\/ipv4\/arp.c (arp_create and arp_process) already<br \/>\nhandles this correctly by skipping the target hardware address for<br \/>\nARPHRD_IEEE1394. Apply the same pattern to arp_packet_match().&#8221;<\/p>\n<p>Mangle the original patch to always return 0 (no match) in case user<br \/>\nmatches on the target hardware address which is never present in<br \/>\nIEEE1394.<\/p>\n<p>Note that this returns 0 (no match) for either normal and inverse match<br \/>\nbecause matching in the target hardware address in ARPHRD_IEEE1394 has<br \/>\nnever been supported by arptables. This is intentional, matching on the<br \/>\ntarget hardware address should never evaluate true for ARPHRD_IEEE1394.<\/p>\n<p>Moreover, adjust arpt_mangle to drop the packet too as AI suggests:<\/p>\n<p>In arpt_mangle, the logic assumes a standard ARP layout. Because<br \/>\nIEEE1394 (FireWire) omits the target hardware address, the linear<br \/>\npointer arithmetic miscalculates the offset for the target IP address.<br \/>\nThis causes mangling operations to write to the wrong location, leading<br \/>\nto packet corruption. To ensure safety, this patch drops packets<br \/>\n(NF_DROP) when mangling is requested for these fields on IEEE1394<br \/>\ndevices, as the current implementation cannot correctly map the FireWire<br \/>\nARP payload.<\/p>\n<p>This omits both mangling target hardware and IP address. Even if IP<br \/>\naddress mangling should be possible in IEEE1394, this would require<br \/>\nto adjust arpt_mangle offset calculation, which has never been<br \/>\nsupported.<\/p>\n<p>Based on patch from Weiming Shi .<\/p>\n<p>  Severity: 0.0 | NA<\/p>\n<p>  Visit the link for more details, such as CVSS details, affected products, timeline, and more&#8230;\u00a0<\/p>\n","protected":false},"excerpt":{"rendered":"<p>CVE ID :CVE-2026-45844 Published : May 27, 2026, 11:16 a.m. | 1\u00a0hour, 15\u00a0minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: netfilter: arp_tables: fix IEEE1394 ARP payload parsing Weiming Shi says: &#8220;arp_packet_match() unconditionally parses the ARP payload assuming two hardware addresses are present (source and target). However, IPv4-over-IEEE1394 ARP (RFC 2734) &hellip;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-78922","post","type-post","status-publish","format-standard","hentry","category-vulnerability"],"_links":{"self":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/78922","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/comments?post=78922"}],"version-history":[{"count":0,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/78922\/revisions"}],"wp:attachment":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/media?parent=78922"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/categories?post=78922"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/tags?post=78922"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}