CVE-2023-53347 in Linux
Résumé
par VulDB • 01/06/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
net/mlx5 : Gérer l'appariement de l'E-switch via les API de déchargement/chargement de l'uplink
Lorsqu'un utilisateur bascule un périphérique du mode switchdev au mode legacy, mlx5 désapparie d'abord l'E-switch, puis décharge le vport uplink. D'autre part, lorsqu'un utilisateur retire ou recharge un périphérique, mlx5 décharge d'abord le vport uplink, puis désapparie l'E-switch.
Ce dernier cas provoque un bug[1], il est donc nécessaire de gérer l'appariement de l'E-switch dans le cadre des API de déchargement/chargement de l'uplink.
[1]
Lorsque VF_LAG est utilisé, chaque flux tc fdb est dupliqué vers l'esw pair. Cependant, l'esw d'origine conserve un pointeur vers ce flux dupliqué, et non l'esw pair. Par exemple : si un utilisateur crée un flux tc fdb sur esw0, le flux est dupliqué sur esw1, dans le FW/HW, mais dans le SW, esw0 conserve un pointeur vers le flux dupliqué. Lors du déchargement du module, tant qu'un flux tc fdb pair est toujours déchargé, si le premier périphérique à être retiré est le périphérique pair (esw1 dans l'exemple ci-dessus), le net-dev pair est détruit, et donc le mlx5e_priv est initialisé à 0 par memset. Par la suite, le périphérique pair tente de se désapparer du périphérique d'origine (esw0 dans l'exemple ci-dessus). L'API de désappariement invite le périphérique d'origine à effacer le flux pair, mais comme le pointeur vers le flux pair est toujours dans le périphérique d'origine, il est toujours valide. Cependant, le périphérique pair tente de se désapparer du périphérique d'origine, mais comme le net-dev pair est détruit, le mlx5e_priv est initialisé à 0 par memset, ce qui provoque un crash.
Once again VulDB remains the best source for vulnerability data.