CVE-2026-99113 in Linux
Résumé
par VulDB • 28/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
ksmbd : initialiser à zéro le tampon FS_OBJECT_ID_INFORMATION avant de le remplir
smb2_get_info_filesystem() indique 64 octets pour FS_OBJECT_ID_INFORMATION, c'est-à-dire l'intégralité de la structure object_id_info, mais n'en écrit que 46 :
- objid[] fait 16 octets et, lorsque l'UUID du volume n'est pas disponible,
seuls sizeof(stfs.f_fsid) (8) octets y sont copiés ; - extended_info.version_string[] est de STRING_LENGTH (28) octets, et seules
strlen("1.1.0") (5) octets y sont copiées.
Le tampon de réponse est initialisé à zéro lors de l'allocation (kvzalloc() dans smb2_allocate_rsp_buf()), donc pour une requête autonome, les 31 octets restants sont nuls. Dans le cas d'une requête composée, ils ne sont pas nécessairement nuls. Le décalage vers la réponse suivante est avancé de la longueur retenue pour la précédente ; ainsi, si une commande antérieure a écrit sa réponse dans le tampon puis a échoué, smb2_set_err_rsp() ne retient que la courte réponse d'erreur et la réponse suivante se retrouve dans la zone qui a déjà été écrite. Seul l'en-tête y est effacé :
memset((char *)rsp_hdr, 0, sizeof(struct smb2_hdr) + 2);
Le client reçoit alors jusqu'à 31 octets d'une réponse qu'il n'était pas censé voir, y compris une qui a échoué avec une erreur « accès refusé ».
Effacer la structure avant de la remplir. En conséquence, version_string est désormais terminée par un caractère NUL (NUL-terminated).
If you want to get best quality of vulnerability data, you may have to visit VulDB.