CVE-2024-43873

In the Linux kernel, the following vulnerability has been resolved: vhost/vsock: always initialize seqpacket_allow There are two issues around seqpacket_allow: 1. seqpacket_allow is not initialized when socket is created. Thus if features are never set, it will be read uninitialized. 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared, then seqpacket_allow will not be cleared appropriately (existing apps I know about don't usually do this but it's legal and there's no way to be sure no one relies on this). To fix: - initialize seqpacket_allow after allocation - set it unconditionally in set_features

In the Linux kernel, the following vulnerability has been resolved: vhost/vsock: always initialize seqpacket_allow There are two issues around seqpacket_allow: 1. seqpacket_allow is not initialized when socket is created. Thus if features are never set, it will be read uninitialized. 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared, then seqpacket_allow will not be cleared appropriately (existing apps I know about don't usually do this but it's legal and there's no way to be sure no one relies on this). To fix: - initialize seqpacket_allow after allocation - set it unconditionally in set_features

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vhost/vsock: inicializar siempre seqpacket_allow Hay dos problemas relacionados con seqpacket_allow: 1. seqpacket_allow no se inicializa cuando se crea el socket. Por lo tanto, si las funciones nunca se configuran, se leerá sin inicializar. 2. Si VIRTIO_VSOCK_F_SEQPACKET está configurado y luego borrado, entonces seqpacket_allow no se borrará apropiadamente (las aplicaciones existentes que conozco generalmente no hacen esto, pero es legal y no hay forma de estar seguro de que nadie confíe en esto). Para solucionarlo: - inicializar seqpacket_allow después de la asignación - configurarlo incondicionalmente en set_features