XPost: linux.kernel, linux.debian.bugs.dist   
   From: regressions@leemhuis.info   
      
   @stable team and/or @net maintainers: this imho needs a judgement call   
   from your side. See below for details.   
      
   On 1/2/26 21:18, Ben Hutchings wrote:   
   > On Fri, 2025-12-19 at 10:19 +0100, Thorsten Leemhuis wrote:   
   >> On 12/18/25 20:50, Salvatore Bonaccorso wrote:   
   >>>   
   >>> Is there soemthing missing?   
   >>>   
   >>> Roland I think it would be helpful if you can test as well more recent   
   >>> stable series versions to confirm if the issue is present there as   
   >>> well or not, which might indicate a 5.10.y specific backporting   
   >>> problem.   
   >>   
   >> FWIW, it (as usual) would be very important to know if this happens with   
   >> mainline as well, as that determines if it's a general problem or a   
   >> backporting problem   
   > [...]   
   >   
   > The bug is this:   
   >   
   > - libvirtd wrongly used to use NLM_F_CREATE (0x400) and NLM_F_EXCL   
   >   (0x200) flags on an RTM_DELLINK operation.  These flags are only   
   >   semantically valid for NEW-type operations.   
   >   
   > - rtnetlink is rather lax about checking the flags on operations, so   
   >   these unsupported flags had no effect.   
   >   
   > - rtnetlink can now support NLM_F_BULK (0x200) on some DEL-type   
   >   operations.  If the flag is used but is not valid for the specific   
   >   operation then the operation now fails with EOPNOTSUPP.  Since   
   >   NLM_F_EXCL == NLM_F_BULK and RTM_DELLINK does not support bulk   
   >   operations, libvirtd now hits this error case.   
   >   
   > I have not tested with mainline, but in principle the same issue should   
   > occur with any other kernel version that has commit a6cec0bcd342 "net:   
   > rtnetlink: add bulk delete support flag"   
      
   FWIW, merged for v5.19-rc1 and backported to v5.10.246 as 1550f3673972c5   
   End of October 2025 in parallel with 5b22f62724a0a0 ("net: rtnetlink:   
   fix module reference count leak issue in rtnetlink_rcv_msg") [v6.0-rc2],   
   which is a fix for the former.   
      
   > together with an older version of libvirt.   
   >   
   > This was fixed in libvirt commit 1334002340b, which appears to have gone   
   > into version 7.1.0,   
      
   Could not find that commit when looking briefly, but that version was   
   released 2021-03-01.   
      
   > but Debian 11 "bullseye" has 7.0.0.   
   >   
   > We can certainly fix the libvirt side of this in Debian, but this also   
   > sounds like a case where the kernel should work around known buggy user-   
   > space.  On the other hand, this has been upstream for over 3 years so   
   > maybe it doesn't make sense now.   
      
   Yeah, I tend to the latter as well (the @net maintainers can speak up if   
   the disagree). But we have one more middle-ground option here maybe the   
   @stable team could do: revert the backports of 1550f3673972c5 and   
   5b22f62724a0a0 from 5.10.y, unless they are strongly needed there.   
      
   > Please let me know whether I (or anyone) should try to implement a   
   > workaround for this in the kernel.   
      
   Ciao, Thorsten   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)