[BUG] net/sched: failed fq change can still update packet limits

[BUG] net/sched: failed fq change can still update packet limits

[shaos]

Hello,

An RTM_NEWQDISC request for an existing fq qdisc sets valid PLIMIT=5555 and FLOW_PLIMIT=6666 together with an invalid BUCKETS_LOG=100. The operation returns -EINVAL after fq_change() has already committed both limits.

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/990ab5ed350cb27e983ddd0848c760f9/raw/1668f34550b5cb0135f7fb73eae5a6b52e0751fd/console-output.txt
kernel config:
https://gist.githubusercontent.com/shaos26/990ab5ed350cb27e983ddd0848c760f9/raw/35a9dbfe64eb6405e86bb0c268e36a4d7238568a/kernel-config.txt
reproducer:
https://gist.githubusercontent.com/shaos26/990ab5ed350cb27e983ddd0848c760f9/raw/81a61b72ddf5329959cab7c32597b66cf3630e5d/poc.c

Build the tested kernel with the attached configuration, compile poc.c statically and run it in a disposable guest/network namespace with CAP_NET_ADMIN. The program submits the invalid mixed request and reads the live fq options back.

Impact and prerequisites:
A caller with CAP_NET_ADMIN in the qdisc network namespace sees the request fail while two qdisc options change. The same valid limits can be applied by a successful request, so this is misleading error semantics/configuration drift, not a security-boundary crossing.

Validation: Two fresh QEMU runs reproduced plimit 10000->5555 and flow_plimit 100->6666 despite -EINVAL. Invalid-only and patched-kernel controls retained the original values.

Thanks,

shaos