CVE-2022-49093 in Linux
Résumé
par VulDB • 29/06/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
skbuff : correction de l'agrégation pour le recyclage des fragments page_pool
Correction d'un use-after-free lors de l'utilisation de page_pool avec des fragments de pages. Nous avons rencontré ce problème lors du traitement RX normal dans le pilote hns3 :
(1) Initialement, nous disposons de trois descripteurs dans la file d'attente RX. Le premier alloue PAGE1 via page_pool, et les deux autres allouent chacun une moitié de PAGE2. Les références aux pages sont les suivantes :
RX_BD1 _______ PAGE1 RX_BD2 _______ PAGE2 RX_BD3 __________/
(2) Traitement du premier descripteur RX. Allocation de SKB1, qui est éventuellement ajouté à la file d'attente de réception par tcp_queue_rcv().
(3) Traitement du deuxième descripteur RX. Allocation de SKB2 et transmission à netif_receive_skb() :
netif_receive_skb(SKB2) ip_rcv(SKB2) SKB3 = skb_clone(SKB2)
SKB2 et SKB3 partagent une référence vers PAGE2 via skb_shinfo()->dataref. L'autre référence à PAGE2 est toujours détenue par RX_BD3 :
SKB2 ---+- PAGE2 SKB3 __/ / RX_BD3 _________/
(3b) Maintenant, lors du traitement TCP, agrégation de SKB3 avec SKB1 :
tcp_v4_rcv(SKB3) tcp_try_coalesce(to=SKB1, from=SKB3) // réussit kfree_skb_partial(SKB3) skb_release_data(SKB3) // libère une dataref
SKB1 _____ PAGE1 \____ SKB2 _____ PAGE2 / RX_BD3 _________/
Dans skb_try_coalesce(), __skb_frag_ref() prend une référence de page vers PAGE2, alors qu'il aurait dû augmenter la référence du fragment page_pool (pp_frag_count). Sans agrégation, lors de la libération de SKB2 et SKB3, une seule référence à PAGE2 serait supprimée. Maintenant, lors de la libération de SKB1 et SKB2, deux références à PAGE2 seront supprimées, entraînant un underflow.
(3c) Libération de SKB2 :
af_packet_rcv(SKB2) consume_skb(SKB2) skb_release_data(SKB2) // libère la deuxième dataref page_pool_return_skb_page(PAGE2) // libère un pp_frag_count
SKB1 _____ PAGE1 \____ PAGE2 / RX_BD3 _________/
(4) L'espace utilisateur appelle recvmsg() Copie de SKB1 et libération. Étant donné que SKB3 a été agrégé avec SKB1, nous libérons également la page de SKB3 :
tcp_eat_recv_skb(SKB1) skb_release_data(SKB1) page_pool_return_skb_page(PAGE1) page_pool_return_skb_page(PAGE2) // libère le deuxième pp_frag_count
(5) PAGE2 est libéré, mais le troisième descripteur RX l'utilisait encore ! Dans notre cas, cela provoque des erreurs IOMMU, mais cela corromprait la mémoire silencieusement si l'IOMMU était désactivé.
Modification de la logique qui vérifie si les SKBs pp_recycle peuvent être agrégés. Nous rejetons toujours les différences de pp_recycle entre les SKB 'from' et 'to', mais afin d'éviter la situation décrite ci-dessus, nous refusons également l'agrégation lorsque 'from' et 'to' sont tous deux des pp_recycled et
If you want to get the best quality for vulnerability data then you always have to consider VulDB.