On Mon, 2024-07-01 at 23:52 +0200, Pablo Neira Ayuso wrote:
On Mon, Jul 01, 2024 at 11:48:51PM +0200, Pablo Neira Ayuso wrote:
On Mon, Jul 01, 2024 at 10:51:17PM +0200, Ben Hutchings wrote:
On Thu, 2024-06-13 at 13:33 +0200, Greg Kroah-Hartman wrote:
4.19-stable review patch. If anyone has any objections, please let me know.
From: Pablo Neira Ayuso pablo@netfilter.org
commit c9e6978e2725a7d4b6cd23b2facd3f11422c0643 upstream.
[...]
This turns out to cause a regression for nftables user-space versions older than v0.9.3, specifically before:
commit a4ec053812610400b7a9e6c060d8b7589dedd5b1 Author: Pablo Neira Ayuso pablo@netfilter.org Date: Wed Oct 9 11:54:32 2019 +0200 segtree: always close interval in non-anonymous sets
This is really fixing up userspace as the commit describes, otherwise incremental updates are not possible on a set/map.
Should nft_set_rbtree detect and fix-up the bad set messages that nftables user-space used to send?
Problem is that a non-anonymous set really needs close intervals, otherwise incremental updates on it are not possible.
It should be possible to backport a fix for such nftables version.
I can see Debian 10 (Buster, oldoldstable) is using 0.9.0 but it was discontinued in june 2022? But who is using such an old userspace version?
Oh, I misread, it is still supported in oldoldstable in Debian.
It is out of support in Debian from today. But Freexian will maintain a derivative of it (with selective updates, including a newer kernel branch) for some time to come.
Then, userspace really needs this fix, because incremental updates on a set are not really possible.
I can take a look and send a backport of this for nftables 0.9.0.
Thank you! I already tried cherry-picking just that commit, and that seemed to fix the issue, but I didn't test anything else and I'm not at all familiar with the code.
Ben.