Vulnerabilidad en kernel de Linux (CVE-2024-54191)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: iso: Corregir bloqueo circular en iso_conn_big_sync Esto corrige la advertencia de dependencia de bloqueo circular a continuación, al reelaborar iso_sock_recvmsg, para garantizar que el bloqueo del socket siempre se libere antes de llamar a una función que bloquea hdev. [ 561.670344] ========================================================= [ 561.670346] ADVERTENCIA: posible dependencia de bloqueo circular detectada [ 561.670349] 6.12.0-rc6+ #26 No contaminado [ 561.670351] ------------------------------------------------------ [ 561.670353] iso-tester/3289 está intentando adquirir bloqueo: [ 561.670355] ffff88811f600078 (&hdev->lock){+.+.}-{3:3}, en: iso_conn_big_sync+0x73/0x260 [bluetooth] [ 561.670405] pero la tarea ya tiene el bloqueo: [ 561.670407] ffff88815af58258 (sk_lock-AF_BLUETOOTH){+.+.}-{0:0}, en: iso_sock_recvmsg+0xbf/0x500 [bluetooth] [ 561.670450] cuyo bloqueo ya depende del nuevo bloqueo. [ 561.670452] la cadena de dependencia existente (en orden inverso) es: [ 561.670453] -> #2 (sk_lock-AF_BLUETOOTH){+.+.}-{0:0}: [ 561.670458] lock_acquire+0x7c/0xc0 [ 561.670463] lock_sock_nested+0x3b/0xf0 [ 561.670467] bt_accept_dequeue+0x1a5/0x4d0 [bluetooth] [ 561.670510] iso_sock_accept+0x271/0x830 [bluetooth] [ 561.670547] do_accept+0x3dd/0x610 [ 561.670550] __sys_accept4+0xd8/0x170 [ 561.670553] __x64_sys_accept+0x74/0xc0 [ 561.670556] x64_sys_call+0x17d6/0x25f0 [ 561.670559] hacer_syscall_64+0x87/0x150 [ 561.670563] entrada_SYSCALL_64_after_hwframe+0x76/0x7e [ 561.670567] -> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}: [ 561.670571] bloqueo_adquirir+0x7c/0xc0 [ 561.670574] lock_sock_nested+0x3b/0xf0 [ 561.670577] iso_sock_listen+0x2de/0xf30 [bluetooth] [ 561.670617] __sys_listen_socket+0xef/0x130 [ 561.670620] __x64_sys_listen+0xe1/0x190 [ 561.670623] x64_sys_call+0x2517/0x25f0 [ 561.670626] hacer_syscall_64+0x87/0x150 [ 561.670629] entrada_SYSCALL_64_después_de_hwframe+0x76/0x7e [ 561.670632] -> #0 (&hdev->lock){+.+.}-{3:3}: [ 561.670636] __lock_acquire+0x32ad/0x6ab0 [ 561.670639] lock_acquire.part.0+0x118/0x360 [ 561.670642] lock_acquire+0x7c/0xc0 [ 561.670644] __mutex_lock+0x18d/0x12f0 [ 561.670647] mutex_lock_nested+0x1b/0x30 [ 561.670651] iso_conn_big_sync+0x73/0x260 [bluetooth] [ 561.670687] iso_sock_recvmsg+0x3e9/0x500 [bluetooth] [561.670722] sock_recvmsg+0x1d5/0x240 [561.670725] sock_read_iter+0x27d/0x470 [561.670727] vfs_read+0x9a0/0xd30 [561.670731] ksys_read+0x1a8/0x250 [561.670733] __x64_sys_read+0x72/0xc0 [561.670736] x64_sys_call+0x1b12/0x25f0 [561.670738] do_syscall_64+0x87/0x150 [ 561.670741] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 561.670744] otra información que podría ayudarnos a depurar esto: [ 561.670745] La cadena existe de: &hdev->lock --> sk_lock-AF_BLUETOOTH-BTPROTO_ISO --> sk_lock-AF_BLUETOOTH [ 561.670751] Posible escenario de bloqueo inseguro: [ 561.670753] CPU0 CPU1 [ 561.670754] ---- ---- [ 561.670756] lock(sk_lock-AF_BLUETOOTH); [ 561.670758] bloqueo(sk_lock AF_BLUETOOTH-BTPROTO_ISO); [ 561.670761] bloqueo(sk_lock-AF_BLUETOOTH); [ 561.670764] bloqueo(&hdev->lock); [ 561.670767] *** BLOQUEO INTERMEDIO ***