[BUG] net/sched: failed fq_pie flow change still commits the new limit

[BUG] net/sched: failed fq_pie flow change still commits the new limit

[shaos]

Hello,

Create fq_pie with limit=10240 and flows=1024, then request limit=123 together with flows=0. fq_pie_change() publishes the new limit before rejecting the immutable flows request with -EINVAL.

HEAD commit:    c03c1a14507dfaf8b856c2608f9ac216021fc222
git tree:       30fd2ef82912c26cf3a58ad0ba6afc375fa851ac
source version: Linux 7.3.0, local master
compiler:       gcc 11.4.0, GNU ld 2.38

console output:
https://gist.githubusercontent.com/shaos26/76c412e475cb36c49649b9825e807ff5/raw/ae794ca3a9b896c8e195876de08f79b82f67c5f9/console-output.txt
kernel config:
https://gist.githubusercontent.com/shaos26/76c412e475cb36c49649b9825e807ff5/raw/6ea0e3da68f1e239d565c64f7906d0f9c73bf784/kernel-config.txt
reproducer:
https://gist.githubusercontent.com/shaos26/76c412e475cb36c49649b9825e807ff5/raw/3a875172daae5e614f50f4ec313e3dbb85893d1d/poc.c

Build the tested kernel with the attached configuration; compile poc.c statically and run it in a disposable network namespace with CAP_NET_ADMIN. It creates fq_pie, submits both the invalid mixed request and the close controls, and dumps the resulting limit.

Impact and prerequisites:
The failed rtnetlink update changes live qdisc state for a caller with CAP_NET_ADMIN in that namespace. The same limit can be applied directly with a valid request, so the impact is control-plane inconsistency rather than privilege escalation.

Validation: Two independent fresh QEMU boots reproduced the limit change after -EINVAL. Invalid-flows-only and valid-limit-only controls behaved as expected.

Thanks,

shaos