{"vulnerability": "CVE-2024-41010", "sightings": [{"uuid": "7217f361-908d-4286-b65f-655533e8b0c3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41010", "type": "seen", "source": "https://t.me/cvedetector/1058", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-41010 - \"BPF Linux Kernel tcx_entry Use-After-Free Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-41010 \nPublished : July 17, 2024, 7:15 a.m. | 29\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbpf: Fix too early release of tcx_entry  \n  \nPedro Pinto and later independently also Hyunwoo Kim and Wongi Lee reported  \nan issue that the tcx_entry can be released too early leading to a use  \nafter free (UAF) when an active old-style ingress or clsact qdisc with a  \nshared tc block is later replaced by another ingress or clsact instance.  \n  \nEssentially, the sequence to trigger the UAF (one example) can be as follows:  \n  \n  1. A network namespace is created  \n  2. An ingress qdisc is created. This allocates a tcx_entry, and  \n     &tcx_entry->miniq is stored in the qdisc's miniqp->p_miniq. At the  \n     same time, a tcf block with index 1 is created.  \n  3. chain0 is attached to the tcf block. chain0 must be connected to  \n     the block linked to the ingress qdisc to later reach the function  \n     tcf_chain0_head_change_cb_del() which triggers the UAF.  \n  4. Create and graft a clsact qdisc. This causes the ingress qdisc  \n     created in step 1 to be removed, thus freeing the previously linked  \n     tcx_entry:  \n  \n     rtnetlink_rcv_msg()  \n       => tc_modify_qdisc()  \n         => qdisc_create()  \n           => clsact_init() [a]  \n         => qdisc_graft()  \n           => qdisc_destroy()  \n             => __qdisc_destroy()  \n               => ingress_destroy() [b]  \n                 => tcx_entry_free()  \n                   => kfree_rcu() // tcx_entry freed  \n  \n  5. Finally, the network namespace is closed. This registers the  \n     cleanup_net worker, and during the process of releasing the  \n     remaining clsact qdisc, it accesses the tcx_entry that was  \n     already freed in step 4, causing the UAF to occur:  \n  \n     cleanup_net()  \n       => ops_exit_list()  \n         => default_device_exit_batch()  \n           => unregister_netdevice_many()  \n             => unregister_netdevice_many_notify()  \n               => dev_shutdown()  \n                 => qdisc_put()  \n                   => clsact_destroy() [c]  \n                     => tcf_block_put_ext()  \n                       => tcf_chain0_head_change_cb_del()  \n                         => tcf_chain_head_change_item()  \n                           => clsact_chain_head_change()  \n                             => mini_qdisc_pair_swap() // UAF  \n  \nThere are also other variants, the gist is to add an ingress (or clsact)  \nqdisc with a specific shared block, then to replace that qdisc, waiting  \nfor the tcx_entry kfree_rcu() to be executed and subsequently accessing  \nthe current active qdisc's miniq one way or another.  \n  \nThe correct fix is to turn the miniq_active boolean into a counter. What  \ncan be observed, at step 2 above, the counter transitions from 0->1, at  \nstep [a] from 1->2 (in order for the miniq object to remain active during  \nthe replacement), then in [b] from 2->1 and finally [c] 1->0 with the  \neventual release. The reference counter in general ranges from [0,2] and  \nit does not need to be atomic since all access to the counter is protected  \nby the rtnl mutex. With this in place, there is no longer a UAF happening  \nand the tcx_entry is freed at the correct time. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"17 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-17T09:51:32.000000Z"}]}