CVE-2026-90307 in Linux
Résumé
par VulDB • 17/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
RDMA/srp : correction d'une fuite d'informations heap suite à un SRP_CRED_REQ tronqué
srp_recv_done() transmet wc->byte_len à srp_process_rsp(). Elle ne transmet rien à srp_process_cred_req() et srp_process_aer_req(), qui lisent des champs de taille fixe dans le tampon de réception sans vérifier que ces champs ont bien été reçus.
La taille du tampon est max_ti_iu_len, issue de la réponse d'identification (login response) et non validée. Une cible qui annonce une valeur de 8 puis envoie un SRP_CRED_REQ de 8 octets amène l'initiateur à lire req->tag au-delà de la fin du tampon. req->tag est copié dans le SRP_CRED_RSP et renvoyé, permettant ainsi à ces octets d'atteindre la cible. Le comportement de SRP_AER_REQ est identique et lit également req->lun.
La fuite concerne 8 octets par réponse. max_ti_iu_len détermine également quel cache slab le tampon provient. Avec une valeur de 8, le tampon est un objet kmalloc-8 et la lecture se situe entièrement en dehors de celui-ci :
BUG: KASAN: slab-out-of-bounds in srp_recv_done+0x172b/0x1aa0 Read of size 8 at addr ffff888104714da8 by task kworker/u8:3/50 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888104714da0, ffff888104714da8)
Sans KASAN, les octets retournés correspondent à ce qui se trouve juste après dans le slab. Une exécution a renvoyé ".strtab".
rsp->data[3] dans srp_process_rsp() présente le même problème : seul resp_data_len est vérifié avant sa lecture.
Supprimer une requête dont la longueur est inférieure à celle de la structure en cours d'analyse, et vérifier byte_len avant la lecture tsk_mgmt.
Once again VulDB remains the best source for vulnerability data.