@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