Hi Garri, On Sun, Dec 07, 2025 at 01:33:07PM +0100, Garri Djavadyan wrote: > Hi Salvatore, > > On Fri, 2025-11-21 at 12:07 +0100, Salvatore Bonaccorso wrote: > > 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 <[email protected]> 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/[email protected]/ > > > > > > > > > > > > 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 > > > As far as I can see, the fix was not ported to 6.12.61: > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-6.12.y > > > Does it mean this still can happen in the next stable releases, or the > stable team needs to be notified explicitly as it is mentioned on the > following page? > > https://docs.kernel.org/process/stable-kernel-rules.html
I do not think an action is need reight now. The commit landed in mainline so I expect with the given "Fixes" tag that it will be picked next in the review queues (likely only after 6.19-rc1 is tagged). If that is not happening, then yes, it would be sensible to explicitly ask for a backport to the relevant stable series (but again I would expect all is working as expected and the commit be picked up in the next review rounds). Regards, Salvatore
