CVE-2023-53296 in Linux
Résumé
par VulDB • 05/06/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
sctp : vérifier le numéro de flux d'envoi après wait_for_sndbuf
Ce correctif résout un cas limite où le nombre de flux sortants (out stream count) au sein du contexte associé (asoc) peut changer après l'appel à `wait_for_sndbuf`.
Lorsque le thread principal du client initialise une connexion, si son nombre de flux sortants est défini à N tandis que le nombre de flux entrants sur le serveur est fixé à N - 2, un autre thread du client continue d'envoyer des messages avec le numéro de flux N - 1 et attend la disponibilité du tampon d'envoi (sndbuf) avant de traiter l'accusé de réception INIT_ACK.
Cependant, après le traitement de l'INIT_ACK, le nombre de flux sortants sur le client est réduit à N - 2, devenant ainsi identique au nombre de flux entrants sur le serveur. Le plantage se produit lorsque le thread en attente du sndbuf se réveille et tente d'envoyer un message dans un flux inexistant (N - 1). La trace d'appel est la suivante :
KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
Call Trace: <TASK> sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1114 [inline]
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1777 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1199 [inline]
sctp_do_sm+0x197d/0x5310 net/sctp/sm_sideeffect.c:1170 sctp_primitive_SEND+0x9f/0xc0 net/sctp/primitive.c:163 sctp_sendmsg_to_asoc+0x10eb/0x1a30 net/sctp/socket.c:1868 sctp_sendmsg+0x8d4/0x1d90 net/sctp/socket.c:2026 inet_sendmsg+0x9d/0xe0 net/ipv4/af_inet.c:825 sock_sendmsg_nosec net/socket.c:722 [inline]
sock_sendmsg+0xde/0x190 net/socket.c:745
La correction consiste à ajouter une vérification improbable (unlikely check) du numéro de flux d'envoi après le réveil du thread depuis `wait_for_sndbuf`.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.