Bug 144832 - IPv6 netfilter: bug in esp and icmp with option header match
IPv6 netfilter: bug in esp and icmp with option header match
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-11 15:23 EST by Peter Bieringer
Modified: 2015-01-04 17:15 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-03 19:04:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Bieringer 2005-01-11 15:23:08 EST
Description of problem:
During setup of IPv6 firewalling I found that IPv6 netfilter code has
two bugs, one about matching on esp, the other matching on icmpv6 with
options. With help of developers, I got fixes which solve the issues.

Version-Release number of selected component (if applicable):
kernel-2.6.10-1.737_FC3

How reproducible:
Always

Steps to Reproduce:
1. setup rule which should match IPv6 esp packages
2. setup rule which should match ICMPv6 packages regardless packages
contain option headers

    

Actual Results:  No match

Expected Results:  Match

Additional info:

See threads:
http://www.linux-ipv6.org/ml/usagi-users/msg03166.html
http://oss.sgi.com/projects/netdev/archive/2005-01/msg00015.html

And here the patch:

--- net/ipv6/netfilter/ip6_tables.c.orig        2004-12-26
19:16:57.461634470 +0100
+++ net/ipv6/netfilter/ip6_tables.c     2004-12-26 19:17:45.456219406
+0100
@@ -220,7 +220,7 @@
                u_int16_t ptr;          /* Header offset in skb */
                u_int16_t hdrlen;       /* Header */

-               ptr = IPV6_HDR_LEN;
+               ptr = ((char *) ipv6 - (char *) skb->data) + IPV6_HDR_LEN;

                while (ip6t_ext_hdr(currenthdr)) {
                        /* Is there enough space for the next ext
header? */
@@ -232,7 +232,7 @@
                         * we will change the return 0 to 1*/
                        if ((currenthdr == IPPROTO_NONE) ||
                                (currenthdr == IPPROTO_ESP))
-                               return 0;
+                               break;

                        hdrptr = (struct ipv6_opt_hdr *)(skb->data + ptr);
Comment 1 Dave Jones 2005-07-15 14:34:40 EDT
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.
Comment 2 Peter Bieringer 2005-08-13 10:38:26 EDT
At least the problem with the option header still exist:

Aug 13 16:34:59 host kernel: FW6-default-DROP-intOUT:IN= OUT=eth0
SRC=fe80:0000:0000:0000:0280:c8ff:feb9:cef9
DST=ff02:0000:0000:0000:0000:0000:0000:0016 LEN=96 TC=0 HOPLIMIT=1 FLOWLBL=0
PROTO=ICMPv6 TYPE=143 CODE=0

Roule still does't match:

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     icmpv6    *      *       fe80::/10           
ff02::16/128       ipv6-icmp type 143 HL match HL == 1
    0     0 ACCEPT     icmpv6    *      *       ::/128              
ff02::16/128       ipv6-icmp type 143 HL match HL == 1
    6   400 ACCEPT     icmpv6    *      *       ::/0                 ::/0      
        

Kernel: 2.6.12-1.1398_FC4
Comment 3 Peter Bieringer 2005-08-13 10:43:57 EDT
Note that while kernel log do no longer show "OPT ( )", a Hop-By-Hop option is
still in the packet:

Frame 1 (110 bytes on wire, 110 bytes captured)
    Arrival Time: Aug 13, 2005 16:43:19.386977000
    Time delta from previous packet: 0.000000000 seconds
    Time since reference or first frame: 0.000000000 seconds
    Frame Number: 1
    Packet Length: 110 bytes
    Capture Length: 110 bytes
    Protocols in frame: eth:ipv6:icmpv6
Ethernet II, Src: D-Link_b9:ce:f9 (00:80:c8:b9:ce:f9), Dst:
IPv6-Neighbor-Discovery_00:00:00:16 (33:33:00:00:00:16)
    Destination: IPv6-Neighbor-Discovery_00:00:00:16 (33:33:00:00:00:16)
    Source: D-Link_b9:ce:f9 (00:80:c8:b9:ce:f9)
    Type: IPv6 (0x86dd)
Internet Protocol Version 6
    Version: 6
    Traffic class: 0x00
    Flowlabel: 0x00000
    Payload length: 56
    Next header: IPv6 hop-by-hop option (0x00)
    Hop limit: 1
    Source address: fe80::280:c8ff:feb9:cef9 (fe80::280:c8ff:feb9:cef9)
    Destination address: ff02::16 (ff02::16)
Hop-by-hop Option Header
    Next header: ICMPv6 (0x3a)
    Length: 0 (8 bytes)
    Router alert: MLD (4 bytes)
    PadN: 2 bytes
Internet Control Message Protocol v6
    Type: 143 (Multicast Listener Report Message v2)
    Code: 0 (Should always be zero)
    Checksum: 0xd3b5 [correct]
    Changed to exclude: ff05::1:3 (ff05::1:3)
        Mode: Changed to exclude
        Aux data len: 0
        Multicast Address: ff05::1:3
    Changed to exclude: ff02::1:2 (ff02::1:2)
        Mode: Changed to exclude
        Aux data len: 0
        Multicast Address: ff02::1:2
Comment 4 Dave Jones 2005-09-30 02:52:00 EDT
Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.
Comment 5 Peter Bieringer 2005-10-03 16:36:33 EDT
I can confirm that match works now (btw: packets are generated by dhcp6s):

    2   192 ACCEPT     icmpv6    *      *       fe80::/10           
ff02::16/128       ipv6-icmp type 143 HL match HL == 1

Note You need to log in before you can comment on or make changes to this bug.