Linux regression tracking (Thorsten Leemhuis) regressions@leemhuis.info wrote:
On 12.09.23 00:57, Pablo Neira Ayuso wrote:
Userspace nftables v1.0.6 generates incorrect bytecode that hits a new kernel check that rejects adding rules to bound chains. The incorrect bytecode adds the chain binding, attach it to the rule and it adds the rules to the chain binding. I have cherry-picked these three patches for nftables v1.0.6 userspace and your ruleset restores fine. [...]
Hmmmm. Well, this sounds like a kernel regression to me that normally should be dealt with on the kernel level, as users after updating the kernel should never have to update any userspace stuff to continue what they have been doing before the kernel update.
This is a combo of a userspace bug and this new sanity check that rejects the incorrect ordering (adding rules to the already-bound anonymous chain).
nf_tables uses a transaction allor-nothing model, this means that any error that occurs during a transaction has to be reverse/undo all the pending changes. This has caused a myriad of bugs already.
So while this can be theoretically fixed in the kernel I don't see a sane way to do it. Error unwinding / recovery from deeply nested errors is already too complex for my taste.
Can't the kernel somehow detect the incorrect bytecode and do the right thing(tm) somehow?
Theoretically yes, but I don't feel competent enough to do it, just look at all the UaF bugs of the past month.