• Bug#1108430: Kernel Regression between 6.1.0-35 and 6.1.0-37: IPv6 link

    From Aiden Yang@1:229/2 to All on Sat Jun 28 15:00:01 2025
    XPost: linux.debian.bugs.dist
    From: [email protected]

    PACKAGE: linux SUBJECT: Kernel Regression between 6.1.0-35 and
    6.1.0-37: IPv6 link-local multicast over GRE tunnel is silently
    dropped SEVERITY: normal

    ===================================================================

    Summary:
    This report details a regression in the Linux kernel that prevents
    IPv6 link-local all-nodes multicast packets (ff02::1) from being
    transmitted over a GRE tunnel. The issue is confirmed to have been
    introduced between kernel versions 6.1.0-35-cloud-amd64 (working) and 6.1.0-37-cloud-amd64 (failing) on Debian 12 (Bookworm).
    On affected kernels, the ping utility reports 100% packet loss, and a
    tcpdump on the underlying physical interface confirms that the kernel
    is silently dropping the encapsulated GRE packets instead of sending
    them. The sendto() system call does not return an error to the
    userspace application in the default namespace.

    ===================================================================

    Regression Point:
    Last Known Good Version: 6.1.0-35-cloud-amd64
    First Failing Version: 6.1.0-37-cloud-amd64
    The regression is also present in later kernels tested, including
    6.12.33 and 6.15.x on Debian 13 (Trixie).

    ===================================================================

    Steps to Reproduce:
    Use a Debian system with an affected kernel (e.g., >= 6.1.0-37).
    Establish a GRE tunnel. Replace [PEER_IP] and [LOCAL_IP] with actual
    endpoint addresses.
    ip tunnel add tun_gre mode gre remote [PEER_IP] local [LOCAL_IP] ttl
    255 ip link set tun_gre up
    In one terminal, start a tcpdump on the physical interface that
    provides the local IP, to monitor for outgoing GRE packets (GRE is IP
    protocol 47).
    tcpdump -i [PHYSICAL_IFACE] -n 'proto gre'
    In a second terminal, attempt to ping the link-local all-nodes
    multicast address via the GRE tunnel interface.
    ping ff02::1%tun_gre -c 4

    ===================================================================

    Observed Behavior (The Bug):
    The ping command runs and reports "4 packets transmitted, 0 received,
    100% packet loss".
    The tcpdump window on the physical interface shows NO outgoing GRE
    packets. This proves the kernel is silently dropping the packets.

    ===================================================================

    Expected Behavior (as observed on kernel 6.1.0-35):
    The ping command runs.
    The tcpdump window shows outgoing GRE packets being sent from
    [LOCAL_IP] to [PEER_IP] for each ICMPv6 echo request. (Receiving a
    reply is dependent on the peer configuration, but the packets should
    be transmitted).

    ===================================================================

    Additional Diagnostic Information:
    VRF Context: When the failing GRE interface (tun_gre) is placed within
    a VRF, the failure mode changes. The ping or sendto() system call
    fails immediately with an ENETUNREACH (Network is unreachable) error.
    This is likely because the VRF routing table does not have a route to
    the tunnel's physical peer address, and the kernel correctly
    identifies this dependency issue.
    veth Control Test: The issue is specific to the gre tunnel interface
    type. A control test using a veth pair inside a VRF works perfectly
    for link-local multicast, proving the core VRF and multicast logic is
    sound.
    This detailed bracketing of the regression should provide a strong
    starting point for identifying the specific commit that introduced
    this behavior.

    --

    WARNING: *This email (including its attachments) may contain confidential information protected by confidentiality agreements or other rights, and is intended only for the designated recipient or individuals who need to know
    it for the stated purpose. The recipient is prohibited from disclosing this information to unauthorized parties without prior permission from MoeDove
    LLC. If you have received this email in error, please notify the sender immediately and delete this email and its attachments from your system. Any use, dissemination, transmission, or copying of this email by someone other than the intended recipient is prohibited and may be unlawful.*

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Salvatore Bonaccorso@1:229/2 to Aiden Yang on Sat Jun 28 21:20:01 2025
    XPost: linux.debian.bugs.dist
    From: [email protected]

    Control: tags -1 + moreinfo

    On Sat, Jun 28, 2025 at 08:49:17PM +0800, Aiden Yang wrote:
    PACKAGE: linux SUBJECT: Kernel Regression between 6.1.0-35 and
    6.1.0-37: IPv6 link-local multicast over GRE tunnel is silently
    dropped SEVERITY: normal

    ===================================================================

    Summary:
    This report details a regression in the Linux kernel that prevents
    IPv6 link-local all-nodes multicast packets (ff02::1) from being
    transmitted over a GRE tunnel. The issue is confirmed to have been
    introduced between kernel versions 6.1.0-35-cloud-amd64 (working) and 6.1.0-37-cloud-amd64 (failing) on Debian 12 (Bookworm).
    On affected kernels, the ping utility reports 100% packet loss, and a
    tcpdump on the underlying physical interface confirms that the kernel
    is silently dropping the encapsulated GRE packets instead of sending
    them. The sendto() system call does not return an error to the
    userspace application in the default namespace.

    ===================================================================

    Regression Point:
    Last Known Good Version: 6.1.0-35-cloud-amd64
    First Failing Version: 6.1.0-37-cloud-amd64
    The regression is also present in later kernels tested, including
    6.12.33 and 6.15.x on Debian 13 (Trixie).

    ===================================================================

    Steps to Reproduce:
    Use a Debian system with an affected kernel (e.g., >= 6.1.0-37).
    Establish a GRE tunnel. Replace [PEER_IP] and [LOCAL_IP] with actual
    endpoint addresses.
    ip tunnel add tun_gre mode gre remote [PEER_IP] local [LOCAL_IP] ttl
    255 ip link set tun_gre up
    In one terminal, start a tcpdump on the physical interface that
    provides the local IP, to monitor for outgoing GRE packets (GRE is IP protocol 47).
    tcpdump -i [PHYSICAL_IFACE] -n 'proto gre'
    In a second terminal, attempt to ping the link-local all-nodes
    multicast address via the GRE tunnel interface.
    ping ff02::1%tun_gre -c 4

    ===================================================================

    Observed Behavior (The Bug):
    The ping command runs and reports "4 packets transmitted, 0 received,
    100% packet loss".
    The tcpdump window on the physical interface shows NO outgoing GRE
    packets. This proves the kernel is silently dropping the packets.

    ===================================================================

    Expected Behavior (as observed on kernel 6.1.0-35):
    The ping command runs.
    The tcpdump window shows outgoing GRE packets being sent from
    [LOCAL_IP] to [PEER_IP] for each ICMPv6 echo request. (Receiving a
    reply is dependent on the peer configuration, but the packets should
    be transmitted).

    ===================================================================

    Additional Diagnostic Information:
    VRF Context: When the failing GRE interface (tun_gre) is placed within
    a VRF, the failure mode changes. The ping or sendto() system call
    fails immediately with an ENETUNREACH (Network is unreachable) error.
    This is likely because the VRF routing table does not have a route to
    the tunnel's physical peer address, and the kernel correctly
    identifies this dependency issue.
    veth Control Test: The issue is specific to the gre tunnel interface
    type. A control test using a veth pair inside a VRF works perfectly
    for link-local multicast, proving the core VRF and multicast logic is
    sound.
    This detailed bracketing of the regression should provide a strong
    starting point for identifying the specific commit that introduced
    this behavior.

    since you can reproduce the regression on all newer upstream versions
    as well, can you please report in to upstream and report back here the
    upstream report so we can follow its status.

    Thanks already.

    Regards,
    Salvatore

    WARNING: *This email (including its attachments) may contain confidential information protected by confidentiality agreements or other rights, and is intended only for the designated recipient or individuals who need to know
    it for the stated purpose. The recipient is prohibited from disclosing this information to unauthorized parties without prior permission from MoeDove LLC. If you have received this email in error, please notify the sender immediately and delete this email and its attachments from your system. Any use, dissemination, transmission, or copying of this email by someone other than the intended recipient is prohibited and may be unlawful.*

    Drop this when you send public bugreports, thanks.

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Debian Bug Tracking System@21:1/5 to All on Tue Jul 22 21:20:01 2025
    This is a multi-part message in MIME format...

    Your message dated Tue, 22 Jul 2025 18:00:11 +0000
    with message-id <[email protected]>
    and subject line Bug#1108430: fixed in linux 6.16~rc7-1~exp1
    has caused the Debian Bug report #1108430,
    regarding Kernel Regression between 6.1.0-35 and 6.1.0-37: IPv6 link-local multicast over GRE tunnel is silently dropped
    to be marked as done.

    This means that you claim that the problem has been dealt with.
    If this is not the case it is now your responsibility to reopen the
    Bug report if necessary, and/or fix the problem forthwith.

    (NB: If you are a system administrator and have no idea what this
    message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected]
    immediately.)


    --
    1108430: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1108430
    Debian Bug Tracking System
    Contact [email protected] with problems

    Received: (at submit) by bugs.debian.org; 28 Jun 2025 12:49:32 +0000 X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02
    (2024-03-25) on buxtehude.debian.org
    X-Spam-Level:
    X-Spam-Status: No, score=-15.2 required=4.0 tests=BAYES_00,
    BODY_INCLUDES_PACKAGE,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,
    DKIM_VALID_EF,HAS_PACKAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS
    autolearn=ham autolearn_force=no
    version=4.0.1-bugs.debian.org_2005_01_02
    X-Spam-Bayes: score:0.0000 Tokens: new, 56; hammy, 146; neutral, 146; spammy,
    4. spammytokens:0.987-1--H*r:59673, 0.987-1--*This, 0.974-+--rights,
    0.956-+--receiving hammytokens:0.000-+--trixie, 0.000-+--bookworm,
    0.000-+--Bookworm, 0.000-+--Trixie, 0.000-+--ff02
    Return-path: <[email protected]>
    Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]:59673)
    by buxtehude.debian.org with es