[BUG] net/sched: rejected GRED change can still update TCA_GRED_LIMIT

[shaos]

Hello,

On an existing GRED qdisc, RTM_NEWQDISC sets TCA_GRED_LIMIT=1234 while supplying invalid TCA_GRED_DPS.DPs=0. gred_change() commits the limit before table validation returns -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/563fcf9f7c2144e0750f9ce9aef7f6ff/raw/18bf75ffee3a3587a962770c34af2301fb1c098d/console-output.txt
kernel config:
https://gist.githubusercontent.com/shaos26/563fcf9f7c2144e0750f9ce9aef7f6ff/raw/817a9271004049a448c2124d7a51e6d62e8ddc7e/kernel-config.txt
reproducer:
https://gist.githubusercontent.com/shaos26/563fcf9f7c2144e0750f9ce9aef7f6ff/raw/0b53273f9f8cd884092267d61110aed70f6233a4/poc.c

Build the tested kernel with the attached configuration and run static poc.c in a disposable network namespace with CAP_NET_ADMIN. It creates the GRED qdisc, sends the invalid mixed request and reads the limit back.

Impact and prerequisites:
A caller with CAP_NET_ADMIN in the namespace receives an error but the packet limit changes from 2000 to 1234. This is a control-plane atomicity defect with no demonstrated privilege escalation.

Validation: Two fresh exact-revision QEMU boots reproduced the change; omitting the limit and using a patched validation order both preserved 2000.

Thanks,

shaos