Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #89564 > unrolled thread

Bug#1117959: ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1117959: ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration Garri Djavadyan <g.djavadyan@gmail.com> - 2025-10-13 00:00 +0200
    Bug#1117959: ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration Salvatore Bonaccorso <carnil@debian.org> - 2025-10-13 08:30 +0200
    Processed: Re: Bug#1117959: ipv6_route flags RTF_ADDRCONF and  RTF_PREFIX_RT are not cleared when static on-link routes are added during  IPv6 address configuration "Debian Bug Tracking System" <owner@bugs.debian.org> - 2025-10-13 08:30 +0200
    Bug#1117959: ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration Garri Djavadyan <g.djavadyan@gmail.com> - 2025-10-16 00:20 +0200
      Bug#1117959: ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration Stephen Hemminger <stephen@networkplumber.org> - 2025-10-18 03:10 +0200
        Bug#1117959: ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration Salvatore Bonaccorso <carnil@debian.org> - 2025-10-25 17:00 +0200
    Bug#1117959: ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration Salvatore Bonaccorso <carnil@debian.org> - 2025-11-21 12:10 +0100
    Bug#1117959: marked as done (ipv6_route flags RTF_ADDRCONF and  RTF_PREFIX_RT are not cleared when static on-link routes are added during  IPv6 address configuration) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2025-12-15 21:20 +0100

#89564 — Bug#1117959: ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration

Package: linux-image-amd64
Version: 6.12.48-1

Dear Debian Linux Kernel Maintainers,

I noticed that the ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are
not cleared when static on-link routes are added during IPv6 address
configuration, and it leads to situations when the kernel updates the
static on-link routes with expiration time.

To replicate the problem I used the latest Debian 13.1 distribution
with the kernel 6.12.48-1 and radvd (on the second machine) with the
following configuration:

root@localhost:~# cat /etc/debian_version
13.1

root@localhost:~# uname -a
Linux localhost 6.12.48+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.12.48-1 (2025-09-20) x86_64 GNU/Linux

radvd.conf (on a directly connected machine):
interface veth1
{
        AdvSendAdvert on;
        MinRtrAdvInterval 45;
        MaxRtrAdvInterval 60;
        AdvDefaultLifetime 0;
        AdvDefaultPreference low;
        AdvHomeAgentFlag off;
        prefix fd00::/64
        {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr off;
                AdvPreferredLifetime 60;
                AdvValidLifetime 120;
        };
};


When I first add a manual IPv6 address to the interface receiving
ICMPv6 RA packets and then receive an ICMPv6 RA with the same on-link
prefix, the packet is silently ignored and no ipv6_route flags,
including RTF_EXPIRES, get set on the static route. Everything works as
expected.

However, if an ICMPv6 RA is received before a manual IPv6 address is
set on the interface, and the RA route is installed in the IPv6 route
table, along with the ipv6_route flags RTF_ADDRCONF, RTF_PREFIX_RT, and
RTF_EXPIRES, only the flag RTF_EXPIRES gets cleared when a manual IPv6
address is configured on the interface later. As a result, after
configuring the IPv6 address, it does not have any associated
expiration time, but the kernel still treats it as an RA-learned route,
so the next received RA packet sets the expiration time again.

Below are the steps leading to the described issue:


# RAs are accepted by the inteface ens4
root@localhost:~# cat /proc/sys/net/ipv6/conf/ens4/accept_ra
1


# Nothing is assigned to ens4 yet
root@localhost:~# ip -6 addr show dev ens4
root@localhost:~# ip -6 ro show dev ens4
root@localhost:~#


# No fd00::/64 routes are present in the IPv6 route table
root@localhost:~# egrep '^fd0+\ ' /proc/net/ipv6_route
root@localhost:~#


# Received on-link prefix fd00::/64 from the router
root@localhost:~# tcpdump -vi ens4 'icmp6[0] = 134'
tcpdump: listening on ens4, link-type EN10MB (Ethernet), snapshot
length 262144 bytes

20:41:57.733151 IP6 (flowlabel 0x15aa0, hlim 255, next-header ICMPv6
(58) payload length: 56) fe80::f83a:f0ff:fe69:27d2 > ip6-allnodes:
[icmp6 sum ok] ICMP6, router advertisement, length 56
        hop limit 64, Flags [none], pref low, router lifetime 0s,
reachable time 0ms, retrans timer 0ms
          prefix info option (3), length 32 (4): fd00::/64, Flags
[onlink, auto], valid time 120s, pref. time 60s
          source link-address option (1), length 8 (1):
fa:3a:f0:69:27:d2
    
        
# The RA route is installed in the ipv6_route structure with the flags
0x004c0001
# 0x4c: RTF_ADDRCONF, RTF_PREFIX_RT, and RTF_EXPIRES
root@localhost:~# egrep '^fd0+\ ' /proc/net/ipv6_route
fd000000000000000000000000000000 40 00000000000000000000000000000000 00
00000000000000000000000000000000 00000100 00000002 00000000 004c0001  
ens4


# The route has an expiration time assigned as expected
root@localhost:~# ip -6 ro show dev ens4
fd00::/64 proto kernel metric 256 expires 88sec pref medium


# Now, the manual IPv6 address from the subnet fd00::/64 is configured
on the interface
root@localhost:~# ip addr add fd00::2/64 dev ens4
root@localhost:~# ip -6 addr show dev ens4
3: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UP group default qlen 1000
    altname enp0s4
    altname enx525400123457
    inet6 fd00::2/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fd00::5054:ff:fe12:3457/64 scope global dynamic mngtmpaddr
proto kernel_ra
       valid_lft 88sec preferred_lft 28sec


# The ipv6_route entry for fd00::/64 gets updated: the flags are
changed to 0x000c0001.
# 0x0c: RTF_ADDRCONF, RTF_PREFIX_RT
# The flag RTF_EXPIRES is removed but the RA-specific flags
RTF_ADDRCONF, RTF_PREFIX_RT are still set.
root@localhost:~# egrep '^fd0+\ ' /proc/net/ipv6_route
fd000000000000000000000000000000 40 00000000000000000000000000000000 00
00000000000000000000000000000000 00000100 00000001 00000000 000c0001  
ens4


# From user's perspective the on-link route looks permanent, no
expiration time is present
root@localhost:~# ip -6 ro show dev ens4
fd00::/64 proto kernel metric 256 pref medium


# Next RA packet has come at this point


# And the permanent route turned into a temporary one again
(0x004c0001)
root@localhost:~# egrep '^fd0+\ ' /proc/net/ipv6_route
fd000000000000000000000000000000 40 00000000000000000000000000000000 00
00000000000000000000000000000000 00000100 00000002 00000000 004c0001  
ens4

root@localhost:~# ip -6 ro show dev ens4
fd00::/64 proto kernel metric 256 expires 77sec pref medium


# The kernel is instructed not to accept RAs anymore
root@localhost:~# echo 0 > /proc/sys/net/ipv6/conf/ens4/accept_ra
root@localhost:~# cat /proc/sys/net/ipv6/conf/ens4/accept_ra

0


# After 2 minutes, the on-link route gets vanished
# while the manual IPv6 address is still installed on the interface
root@localhost:~# ping -Oi 10 fd00::1
PING fd00::1 (fd00::1) 56 data bytes
64 bytes from fd00::1: icmp_seq=1 ttl=64 time=0.508 ms
64 bytes from fd00::1: icmp_seq=2 ttl=64 time=1.18 ms
64 bytes from fd00::1: icmp_seq=3 ttl=64 time=0.519 ms
64 bytes from fd00::1: icmp_seq=4 ttl=64 time=0.565 ms
64 bytes from fd00::1: icmp_seq=5 ttl=64 time=0.702 ms
64 bytes from fd00::1: icmp_seq=6 ttl=64 time=0.737 ms
64 bytes from fd00::1: icmp_seq=7 ttl=64 time=1.10 ms
64 bytes from fd00::1: icmp_seq=8 ttl=64 time=0.643 ms
64 bytes from fd00::1: icmp_seq=9 ttl=64 time=0.668 ms
64 bytes from fd00::1: icmp_seq=10 ttl=64 time=0.679 ms
64 bytes from fd00::1: icmp_seq=11 ttl=64 time=0.529 ms
64 bytes from fd00::1: icmp_seq=12 ttl=64 time=1.24 ms
64 bytes from fd00::1: icmp_seq=13 ttl=64 time=0.738 ms
no answer yet for icmp_seq=14
no answer yet for icmp_seq=15

root@localhost:~# ip -6 ro show dev ens4
root@localhost:~# egrep '^fd0+\ ' /proc/net/ipv6_route
root@localhost:~#

root@localhost:~# ip -6 addr show dev ens4
3: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UP group default qlen 1000
    altname enp0s4
    altname enx525400123457
    inet6 fd00::2/64 scope global
       valid_lft forever preferred_lft forever


In some environements, in which RA-sending routers are present and the
RA processing is disabled by the interface init scripts, a race
condition may lead to automatic removal of the permanent on-link
routes. For example:

1. the OS boots, RAs are accepted;
2. RA with PIO is received from router #1;
3. the kernel installs a temporary on-link route;
4. the OS's init scripts configure a manual IPv6 address;
5. the kernel removes the expiration time from the on-link route;
6. RA with PIO is received from router #2;
7. the kernel sets the expiration time to the on-link route;
8. the OS's init scripts set 'net.ipv6.conf.xxx.accept_ra = 0' for the
interface;
9. the installed IPv6 route is no longer updated by the RAs;
10. the installed IPv6 route expires after N seconds leading to IPv6
reachability issues


The problem was first noticed in a Debian 11 system running kernel
5.10.197-1. The respective bug report [1] in the upstream tracker was
created a year ago.

Thank you.

Regards,
Garri

[1] https://bugzilla.kernel.org/show_bug.cgi?id=219205

[toc] | [next] | [standalone]

#89566

Control: tags -1 + moreinfo

Hi,

On Sun, Oct 12, 2025 at 11:56:09PM +0200, Garri Djavadyan wrote:
> Package: linux-image-amd64
> Version: 6.12.48-1
> 
> Dear Debian Linux Kernel Maintainers,
> 
> I noticed that the ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are
> not cleared when static on-link routes are added during IPv6 address
> configuration, and it leads to situations when the kernel updates the
> static on-link routes with expiration time.
> 
> To replicate the problem I used the latest Debian 13.1 distribution
> with the kernel 6.12.48-1 and radvd (on the second machine) with the
> following configuration:
> 
> root@localhost:~# cat /etc/debian_version
> 13.1
> 
> root@localhost:~# uname -a
> Linux localhost 6.12.48+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian
> 6.12.48-1 (2025-09-20) x86_64 GNU/Linux
> 
> radvd.conf (on a directly connected machine):
> interface veth1
> {
>         AdvSendAdvert on;
>         MinRtrAdvInterval 45;
>         MaxRtrAdvInterval 60;
>         AdvDefaultLifetime 0;
>         AdvDefaultPreference low;
>         AdvHomeAgentFlag off;
>         prefix fd00::/64
>         {
>                 AdvOnLink on;
>                 AdvAutonomous on;
>                 AdvRouterAddr off;
>                 AdvPreferredLifetime 60;
>                 AdvValidLifetime 120;
>         };
> };
> 
> 
> When I first add a manual IPv6 address to the interface receiving
> ICMPv6 RA packets and then receive an ICMPv6 RA with the same on-link
> prefix, the packet is silently ignored and no ipv6_route flags,
> including RTF_EXPIRES, get set on the static route. Everything works as
> expected.
> 
> However, if an ICMPv6 RA is received before a manual IPv6 address is
> set on the interface, and the RA route is installed in the IPv6 route
> table, along with the ipv6_route flags RTF_ADDRCONF, RTF_PREFIX_RT, and
> RTF_EXPIRES, only the flag RTF_EXPIRES gets cleared when a manual IPv6
> address is configured on the interface later. As a result, after
> configuring the IPv6 address, it does not have any associated
> expiration time, but the kernel still treats it as an RA-learned route,
> so the next received RA packet sets the expiration time again.
> 
> Below are the steps leading to the described issue:
> 
> 
> # RAs are accepted by the inteface ens4
> root@localhost:~# cat /proc/sys/net/ipv6/conf/ens4/accept_ra
> 1
> 
> 
> # Nothing is assigned to ens4 yet
> root@localhost:~# ip -6 addr show dev ens4
> root@localhost:~# ip -6 ro show dev ens4
> root@localhost:~#
> 
> 
> # No fd00::/64 routes are present in the IPv6 route table
> root@localhost:~# egrep '^fd0+\ ' /proc/net/ipv6_route
> root@localhost:~#
> 
> 
> # Received on-link prefix fd00::/64 from the router
> root@localhost:~# tcpdump -vi ens4 'icmp6[0] = 134'
> tcpdump: listening on ens4, link-type EN10MB (Ethernet), snapshot
> length 262144 bytes
> 
> 20:41:57.733151 IP6 (flowlabel 0x15aa0, hlim 255, next-header ICMPv6
> (58) payload length: 56) fe80::f83a:f0ff:fe69:27d2 > ip6-allnodes:
> [icmp6 sum ok] ICMP6, router advertisement, length 56
>         hop limit 64, Flags [none], pref low, router lifetime 0s,
> reachable time 0ms, retrans timer 0ms
>           prefix info option (3), length 32 (4): fd00::/64, Flags
> [onlink, auto], valid time 120s, pref. time 60s
>           source link-address option (1), length 8 (1):
> fa:3a:f0:69:27:d2
>     
>         
> # The RA route is installed in the ipv6_route structure with the flags
> 0x004c0001
> # 0x4c: RTF_ADDRCONF, RTF_PREFIX_RT, and RTF_EXPIRES
> root@localhost:~# egrep '^fd0+\ ' /proc/net/ipv6_route
> fd000000000000000000000000000000 40 00000000000000000000000000000000 00
> 00000000000000000000000000000000 00000100 00000002 00000000 004c0001  
> ens4
> 
> 
> # The route has an expiration time assigned as expected
> root@localhost:~# ip -6 ro show dev ens4
> fd00::/64 proto kernel metric 256 expires 88sec pref medium
> 
> 
> # Now, the manual IPv6 address from the subnet fd00::/64 is configured
> on the interface
> root@localhost:~# ip addr add fd00::2/64 dev ens4
> root@localhost:~# ip -6 addr show dev ens4
> 3: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
> state UP group default qlen 1000
>     altname enp0s4
>     altname enx525400123457
>     inet6 fd00::2/64 scope global
>        valid_lft forever preferred_lft forever
>     inet6 fd00::5054:ff:fe12:3457/64 scope global dynamic mngtmpaddr
> proto kernel_ra
>        valid_lft 88sec preferred_lft 28sec
> 
> 
> # The ipv6_route entry for fd00::/64 gets updated: the flags are
> changed to 0x000c0001.
> # 0x0c: RTF_ADDRCONF, RTF_PREFIX_RT
> # The flag RTF_EXPIRES is removed but the RA-specific flags
> RTF_ADDRCONF, RTF_PREFIX_RT are still set.
> root@localhost:~# egrep '^fd0+\ ' /proc/net/ipv6_route
> fd000000000000000000000000000000 40 00000000000000000000000000000000 00
> 00000000000000000000000000000000 00000100 00000001 00000000 000c0001  
> ens4
> 
> 
> # From user's perspective the on-link route looks permanent, no
> expiration time is present
> root@localhost:~# ip -6 ro show dev ens4
> fd00::/64 proto kernel metric 256 pref medium
> 
> 
> # Next RA packet has come at this point
> 
> 
> # And the permanent route turned into a temporary one again
> (0x004c0001)
> root@localhost:~# egrep '^fd0+\ ' /proc/net/ipv6_route
> fd000000000000000000000000000000 40 00000000000000000000000000000000 00
> 00000000000000000000000000000000 00000100 00000002 00000000 004c0001  
> ens4
> 
> root@localhost:~# ip -6 ro show dev ens4
> fd00::/64 proto kernel metric 256 expires 77sec pref medium
> 
> 
> # The kernel is instructed not to accept RAs anymore
> root@localhost:~# echo 0 > /proc/sys/net/ipv6/conf/ens4/accept_ra
> root@localhost:~# cat /proc/sys/net/ipv6/conf/ens4/accept_ra
> 0
> 
> 
> # After 2 minutes, the on-link route gets vanished
> # while the manual IPv6 address is still installed on the interface
> root@localhost:~# ping -Oi 10 fd00::1
> PING fd00::1 (fd00::1) 56 data bytes
> 64 bytes from fd00::1: icmp_seq=1 ttl=64 time=0.508 ms
> 64 bytes from fd00::1: icmp_seq=2 ttl=64 time=1.18 ms
> 64 bytes from fd00::1: icmp_seq=3 ttl=64 time=0.519 ms
> 64 bytes from fd00::1: icmp_seq=4 ttl=64 time=0.565 ms
> 64 bytes from fd00::1: icmp_seq=5 ttl=64 time=0.702 ms
> 64 bytes from fd00::1: icmp_seq=6 ttl=64 time=0.737 ms
> 64 bytes from fd00::1: icmp_seq=7 ttl=64 time=1.10 ms
> 64 bytes from fd00::1: icmp_seq=8 ttl=64 time=0.643 ms
> 64 bytes from fd00::1: icmp_seq=9 ttl=64 time=0.668 ms
> 64 bytes from fd00::1: icmp_seq=10 ttl=64 time=0.679 ms
> 64 bytes from fd00::1: icmp_seq=11 ttl=64 time=0.529 ms
> 64 bytes from fd00::1: icmp_seq=12 ttl=64 time=1.24 ms
> 64 bytes from fd00::1: icmp_seq=13 ttl=64 time=0.738 ms
> no answer yet for icmp_seq=14
> no answer yet for icmp_seq=15
> 
> root@localhost:~# ip -6 ro show dev ens4
> root@localhost:~# egrep '^fd0+\ ' /proc/net/ipv6_route
> root@localhost:~#
> 
> root@localhost:~# ip -6 addr show dev ens4
> 3: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
> state UP group default qlen 1000
>     altname enp0s4
>     altname enx525400123457
>     inet6 fd00::2/64 scope global
>        valid_lft forever preferred_lft forever
> 
> 
> In some environements, in which RA-sending routers are present and the
> RA processing is disabled by the interface init scripts, a race
> condition may lead to automatic removal of the permanent on-link
> routes. For example:
> 
> 1. the OS boots, RAs are accepted;
> 2. RA with PIO is received from router #1;
> 3. the kernel installs a temporary on-link route;
> 4. the OS's init scripts configure a manual IPv6 address;
> 5. the kernel removes the expiration time from the on-link route;
> 6. RA with PIO is received from router #2;
> 7. the kernel sets the expiration time to the on-link route;
> 8. the OS's init scripts set 'net.ipv6.conf.xxx.accept_ra = 0' for the
> interface;
> 9. the installed IPv6 route is no longer updated by the RAs;
> 10. the installed IPv6 route expires after N seconds leading to IPv6
> reachability issues
> 
> 
> The problem was first noticed in a Debian 11 system running kernel
> 5.10.197-1. The respective bug report [1] in the upstream tracker was
> created a year ago.

Thanks for reporting the issue, I have updated some metadata on the
bug. I think the best course of action here is that you try to get
upstream's attation again with your issue to see if they agree on th
issue (you might want to include the netdev mailinglist I think,
other: correct me if there is better place). Please do include this
bugreport in CC.

Until then we cannot have an action donwstream in Debian.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#89567 — Processed: Re: Bug#1117959: ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration

Processing control commands:

> tags -1 + moreinfo
Bug #1117959 [src:linux] ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration
Added tag(s) moreinfo.

-- 
1117959: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1117959
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#89645

Hi Everyone,

A year ago I noticed a problem with handling ipv6_route flags that in
some scenarios can lead to reachability issues. It was reported here:

https://bugzilla.kernel.org/show_bug.cgi?id=219205


Also it was recently reported in the Debian tracker after checking if
the latest Debian stable is still affected:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1117959


Unfortunately, the Debian team cannot act on the report because no one
from the upstream kernel team has confirmed if the report in the
upstream tracker is valid or not. Therefore, I am checking if anyone
can help confirm if the observed behavior is indeed a bug.

Many thanks in advance!

Regards,
Garri

[toc] | [prev] | [next] | [standalone]

#89668

On Thu, 16 Oct 2025 00:12:40 +0200
Garri Djavadyan <g.djavadyan@gmail.com> wrote:

> Hi Everyone,
> 
> A year ago I noticed a problem with handling ipv6_route flags that in
> some scenarios can lead to reachability issues. It was reported here:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=219205
> 
> 
> Also it was recently reported in the Debian tracker after checking if
> the latest Debian stable is still affected:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1117959
> 
> 
> Unfortunately, the Debian team cannot act on the report because no one
> from the upstream kernel team has confirmed if the report in the
> upstream tracker is valid or not. Therefore, I am checking if anyone
> can help confirm if the observed behavior is indeed a bug.
> 
> Many thanks in advance!
> 
> Regards,
> Garri
> 

Linux networking does not actively use kernel bugzilla.
I forward the reports to the mailing list, that is all.
After than sometimes developers go back and update bugzilla
but it is not required or expected.

[toc] | [prev] | [next] | [standalone]

#89771

Hi Garri,

On Sat, Oct 18, 2025 at 01:39:02AM -0700, Stephen Hemminger wrote:
> On Thu, 16 Oct 2025 00:12:40 +0200
> Garri Djavadyan <g.djavadyan@gmail.com> wrote:
> 
> > Hi Everyone,
> > 
> > A year ago I noticed a problem with handling ipv6_route flags that in
> > some scenarios can lead to reachability issues. It was reported here:
> > 
> > https://bugzilla.kernel.org/show_bug.cgi?id=219205
> > 
> > 
> > Also it was recently reported in the Debian tracker after checking if
> > the latest Debian stable is still affected:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1117959
> > 
> > 
> > Unfortunately, the Debian team cannot act on the report because no one
> > from the upstream kernel team has confirmed if the report in the
> > upstream tracker is valid or not. Therefore, I am checking if anyone
> > can help confirm if the observed behavior is indeed a bug.
> > 
> > Many thanks in advance!
> > 
> > Regards,
> > Garri
> > 
> 
> Linux networking does not actively use kernel bugzilla.
> I forward the reports to the mailing list, that is all.
> After than sometimes developers go back and update bugzilla
> but it is not required or expected.

Garri, best action would likely be to really post your full report on
netdev directly.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#90178

HI Garri,

On Fri, Nov 21, 2025 at 11:07:39AM +0100, Garri Djavadyan wrote:
> On Sat, 2025-11-15 at 14:02 +0100, Garri Djavadyan wrote:
> > On Mon, 2025-11-10 at 17:54 +0100, Fernando Fernandez Mancera wrote:
> > > 
> > > 
> > > On 10/25/25 11:21 PM, Garri Djavadyan wrote:
> > > > On Sat, 2025-10-25 at 16:53 +0200, Salvatore Bonaccorso wrote:
> > > > > Hi Garri,
> > > > > 
> > > > > On Sat, Oct 18, 2025 at 01:39:02AM -0700, Stephen Hemminger
> > > > > wrote:
> > > > > > On Thu, 16 Oct 2025 00:12:40 +0200
> > > > > > Garri Djavadyan <g.djavadyan@gmail.com> wrote:
> > > > > > 
> > > > > > > Hi Everyone,
> > > > > > > 
> > > > > > > A year ago I noticed a problem with handling ipv6_route
> > > > > > > flags
> > > > > > > that in
> > > > > > > some scenarios can lead to reachability issues. It was
> > > > > > > reported
> > > > > > > here:
> > > > > > > 
> > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=219205
> > > > > > > 
> > > > > > > 
> > > > > > > Also it was recently reported in the Debian tracker after
> > > > > > > checking if
> > > > > > > the latest Debian stable is still affected:
> > > > > > > 
> > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1117959
> > > > > > > 
> > > > > > > 
> > > > > > > Unfortunately, the Debian team cannot act on the report
> > > > > > > because
> > > > > > > no one
> > > > > > > from the upstream kernel team has confirmed if the report
> > > > > > > in
> > > > > > > the
> > > > > > > upstream tracker is valid or not. Therefore, I am checking
> > > > > > > if
> > > > > > > anyone
> > > > > > > can help confirm if the observed behavior is indeed a bug.
> > > > > > > 
> > > > > > > Many thanks in advance!
> > > > > > > 
> > > > > > > Regards,
> > > > > > > Garri
> > > > > > > 
> > > > > > 
> > > > > > Linux networking does not actively use kernel bugzilla.
> > > > > > I forward the reports to the mailing list, that is all.
> > > > > > After than sometimes developers go back and update bugzilla
> > > > > > but it is not required or expected.
> > > > > 
> > > > > Garri, best action would likely be to really post your full
> > > > > report on
> > > > > netdev directly.
> > > > > 
> > > > > Regards,
> > > > > Salvatore
> > > > 
> > > > 
> > > > Thank you for your suggestions Stephen and Salvatore.
> > > > 
> > > > Below is the full report that was originally posted to the kernel
> > > > bugzilla a year ago. It is still reproducible with fresher
> > > > kernels.
> > > > 
> > > > -----BEGIN REPORT-----
> > > > I noticed that the ipv6_route flags RTF_ADDRCONF and
> > > > RTF_PREFIX_RT
> > > > are
> > > > not cleared when static on-link routes are added during IPv6
> > > > address
> > > > configuration, and it leads to situations when the kernel updates
> > > > the
> > > > static on-link routes with expiration time.
> > > > 
> > > 
> > > This is indeed a bug, I have a patch already and I am doing some
> > > testing 
> > > before sending it to net.git. I hope it can be sent tomorrow.
> > > 
> > > Thanks,
> > > Fernando.
> > 
> > 
> > For the record, Fernando submitted the patch for review to net-next:
> > 
> > https://lore.kernel.org/netdev/20251115095939.6967-1-fmancera@suse.de/
> > 
> > 
> > Regards,
> > Garri
> 
> The patch has landed on linux-next:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=f72514b3c5698e4b900b25345e09f9ed33123de6

That is great :)

> Salvatore, could you please clarify a few questions to which I could
> not find clear answers in the Debian Linux kernel handbook?
> 
> - Should the patch first make it to the mainline or stable upstream
> trees before it is considered for acceptance in the Debian trees?
> - Will it be acceptable for both stable and oldstable Debian releases
> to include the fix considering that it can be seen as a security issue
> in some corner cases?

There is really no need for a Debian specific approach here in my
opinion. The patch has the correct fixes tags upstream so once it is
in mainline it should make it the way down to the stable series. 

As you know Debian follows the upstream stable series. In case a fix
is now known to be okay (needs to be at least in mainline, ideally
already queued for stable), we might pick the commit as well for a
next upload in case it is urgent enough. But usually the best thing is
monitor the situation and help that the patch goes accepted in the
desired stable series and it will land in Debian correspondly as well
with the next rebased upload (both done at point release times but as
well in DSAs via a security upload).

The maybe bit shorter answer is, that the fix should be ideally at
least in mainline and well vetted that to go to the stable series, and
might then be picked as well in advance bit earlier than the actual
release in the upstream series.

Does this answers your question?

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#90480 — Bug#1117959: marked as done (ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration)

[Multipart message — attachments visible in raw view] — view raw

Your message dated Mon, 15 Dec 2025 20:10:12 +0000
with message-id <E1vVEtY-00GipS-2G@fasolo.debian.org>
and subject line Bug#1117959: fixed in linux 6.18.1-1~exp1
has caused the Debian Bug report #1117959,
regarding ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration
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 owner@bugs.debian.org
immediately.)


-- 
1117959: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1117959
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web