CVE-2024-36892

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/slub: evita poner a cero el puntero libre de objetos externos para un solo commit libre 284f17ac13fe ("mm/slub: maneja la liberación masiva y de objetos individuales por separado") divide la liberación de objetos únicos y masivos en dos funciones slab_free() y slab_free_bulk() lo que lleva a slab_free() a llamar a slab_free_hook() directamente en lugar de slab_free_freelist_hook(). Si se establece `init_on_free`, slab_free_hook() pone a cero el objeto. Luego, si se configuran `slub_debug=F` y `CONFIG_SLAB_FREELIST_HARDENED`, la ruta lenta do_slab_free() ejecuta comprobaciones de coherencia de la lista libre e intenta decodificar un freepointer puesto a cero, lo que conduce a una detección de "Freepointer corrupto" en check_object(). Durante la liberación masiva, slab_free_freelist_hook() no se ve afectado ya que siempre establece el puntero libre de sus objetos usando set_freepointer() para mantener su lista libre reconstruida después de `init_on_free`. Para un solo libre, el puntero libre del objeto debe evitarse cuando se almacena fuera del objeto si está configurado "init_on_free". El puntero libre se deja como está, check_object() puede detectar más adelante un valor de puntero no válido debido a un desbordamiento de objetos. Para reproducir, configure `slub_debug=FU init_on_free=1 log_level=7` en la línea de comando de una compilación del kernel con `CONFIG_SLAB_FREELIST_HARDENED=y`. Registro de muestra de dmesg: [10.708715] ============================================ ================================== [10.710323] ERROR kmalloc-rnd-05-32 (Contaminado: GBT) : Freepointer corrupto [10.712695] -------------------------------------------- --------------------------------- [ 10.712695] [ 10.712695] Losa 0xffffd8bdc400d580 objetos=32 usados=4 fp=0xffff9d9a80356f80 flags=0x200000000000a00(workingset|slab|node=0|zone=2) [ 10.716698] Objeto 0xffff9d9a80356600 @offset=1536 fp=0x7ee4f480ce0ecd7c [ 10.716698] [ 10.716698] Bytes b4 9d9a803565f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 10.720703] Objeto ffff9d9a80356600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ [ 10.720703] Objeto ffff9d9a80356610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 10.724696] Relleno ffff9d9a8035666c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 10.724696] Relleno ffff9d9a8035667c: 00 00 00 00 .... [ 10.724696 ] FIX kmalloc-rnd-05-32: Objeto en 0xffff9d9a80356600 no liberado

In the Linux kernel, the following vulnerability has been resolved: mm/slub: avoid zeroing outside-object freepointer for single free Commit 284f17ac13fe ("mm/slub: handle bulk and single object freeing separately") splits single and bulk object freeing in two functions slab_free() and slab_free_bulk() which leads slab_free() to call slab_free_hook() directly instead of slab_free_freelist_hook(). If `init_on_free` is set, slab_free_hook() zeroes the object. Afterward, if `slub_debug=F` and `CONFIG_SLAB_FREELIST_HARDENED` are set, the do_slab_free() slowpath executes freelist consistency checks and try to decode a zeroed freepointer which leads to a "Freepointer corrupt" detection in check_object(). During bulk free, slab_free_freelist_hook() isn't affected as it always sets it objects freepointer using set_freepointer() to maintain its reconstructed freelist after `init_on_free`. For single free, object's freepointer thus needs to be avoided when stored outside the object if `init_on_free` is set. The freepointer left as is, check_object() may later detect an invalid pointer value due to objects overflow. To reproduce, set `slub_debug=FU init_on_free=1 log_level=7` on the command line of a kernel build with `CONFIG_SLAB_FREELIST_HARDENED=y`. dmesg sample log: [ 10.708715] ============================================================================= [ 10.710323] BUG kmalloc-rnd-05-32 (Tainted: G B T ): Freepointer corrupt [ 10.712695] ----------------------------------------------------------------------------- [ 10.712695] [ 10.712695] Slab 0xffffd8bdc400d580 objects=32 used=4 fp=0xffff9d9a80356f80 flags=0x200000000000a00(workingset|slab|node=0|zone=2) [ 10.716698] Object 0xffff9d9a80356600 @offset=1536 fp=0x7ee4f480ce0ecd7c [ 10.716698] [ 10.716698] Bytes b4 ffff9d9a803565f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 10.720703] Object ffff9d9a80356600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 10.720703] Object ffff9d9a80356610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 10.724696] Padding ffff9d9a8035666c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 10.724696] Padding ffff9d9a8035667c: 00 00 00 00 .... [ 10.724696] FIX kmalloc-rnd-05-32: Object at 0xffff9d9a80356600 not freed

Benedict Schlüter, Supraja Sridhara, Andrin Bertschi, and Shweta Shinde discovered that an untrusted hypervisor could inject malicious #VC interrupts and compromise the security guarantees of AMD SEV-SNP. This flaw is known as WeSee. A local attacker in control of the hypervisor could use this to expose sensitive information or possibly execute arbitrary code in the trusted execution environment. Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system.