@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
