Re: [PATCH net] net/sched: cls_api: fix tp_created race losing existing tcf_proto
Lin Jiapeng <[email protected]>
| Newsgroups | org.kernel.vger.stable,org.kernel.vger.netdev |
|---|---|
| Message-ID | <[email protected]> |
在 2026/8/7 02:38, Jamal Hadi Salim 写道: > Thanks. Please respond to that patch and add a tested-by tag > >> BTW, "TencentOS Corvus AI" found this bug; and the patch was mannualy > > Also add a reported-by tag to the patch response > >> written and validated, so no `assisted-by` tag here. Noted for future >> submissions. > > It does look like there was some human touch to it (other than the > verbose comment) - and is a reasonable patch except you missed one > spot. > I am wondering how you tested it. We had to craft printks to see the issue. > > I was kind of suprised how quickly you found the issue. Victor had > something already based on what Sashiko said but i said to wait until > the first patch made it in. > Does Corvus AI watch what Sashiko comments on? > > cheers, > jamal Thanks for the review! Glad to share our testing approach. For this bug we placed kprobes on tcf_chain_tp_delete_empty, tcf_proto_destroy and the classifiers' change() callbacks, capturing the tp pointer arguments ($argN) and return values. Matching tp pointers across the traced PIDs shows the losing thread calling delete_empty on a tp owned by the other racing thread — right after destroying its own tp_new, which is exactly the signature of tp_created not being reset. On an unpatched kernel we observed 927 such wrongful deletions in 3000 rounds; with this patch applied, zero, and normal filter creation/deletion is unaffected. As for how we found it so quickly: Corvus AI continuously explores bugs and security issues in the Linux kernel and generates reports. Each report ships with a PoC and a QEMU-based reproduction procedure, covering both static audit and dynamic verification; a human then reviews the report and reproduces the result before we post and patch the bugs. cheers, Aohan Mei