Re: [PATCH net] net/sched: cls_api: fix tp_created race losing existing tcf_proto

[Lin Jiapeng <ljp1205831794@gmail.com>]

在 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