CVE-2023-52828 in Linuxinformation

Résumé

par VulDB • 20/05/2026

Dans le noyau Linux, la vulnérabilité suivante a été corrigée :

bpf : Détecter IP == ksym.end dans le cadre d'un programme BPF

Maintenant que la fonction kfunc bpf_throw est la première instruction d'appel à disposer de sémantiques noreturn au sein du vérificateur (verifier), cela déclenche également l'élimination du code mort de manière inédite. D'une part, toute instruction suivant un appel à bpf_throw ne sera jamais marquée comme « vue ». D'autre part, si une chaîne d'appels (callchain) finit par provoquer un throw, toutes les instructions situées après l'instruction d'appel vers le sous-programme (subprog) qui finit par effectuer un throw dans les appelants ne seront également jamais marquées comme « vues ».

La solution tentante pour corriger ce problème consisterait à émettre des instructions 'int3' supplémentaires qui augmentent la jited_len d'un programme, et à s'assurer qu'à l'exécution, lorsque le programme effectue un throw, nous pouvons en découvrir les limites même si l'instruction d'appel à bpf_throw (ou aux sous-programmes qui effectuent toujours un throw) est émise en tant qu'instruction finale du programme.

Un exemple d'un tel programme serait le suivant :

do_something(): ... r0 = 0 exit

foo(): r1 = 0 call bpf_throw r0 = 0 exit

bar(cond): if r1 != 0 goto pc+2 call do_something exit call foo r0 = 0 // Jamais vu par le vérificateur exit //

main(ctx): r1 = ... call bar r0 = 0 exit

Ici, si nous finissons par effectuer un throw, la pile d'appels (stacktrace) serait la suivante :

bpf_throw foo bar main

Dans bar, la dernière instruction émise sera l'appel à foo, par conséquent, l'adresse de retour sera l'instruction suivante (que le JIT émet sous forme de int3 sur x86). Cela finira par se situer en dehors de la jited_len du programme, de sorte que lors du dépilement (unwinding), nous ne parviendrons pas à identifier l'adresse de retour comme appartenant à un programme quelconque, ce qui entraînera un panic en raison du dépilement peu fiable des programmes BPF, un scénario que nous ne prévoyions jamais.

Pour remédier à ce cas, faire en sorte que bpf_prog_ksym_find traite IP == ksym.end comme faisant partie du programme BPF, afin que is_bpf_text_address retourne true lorsque ce cas se produit, et que nous puissions effectuer un dépilement fiable lorsque la dernière instruction finit par être une instruction d'appel.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Sources

Do you know our Splunk app?

Download it now for free!