Descripción
En el kernel de Linux se resolvió la siguiente vulnerabilidad: nvme-tcp: no aceptar C2HData basándose solo en blk_rq_payload_bytes(). El commit 25e5cb780e62 ("nvme-tcp: fix possible crash in write_zeroes processing") estableció que blk_rq_payload_bytes() no debe leerse sin verificar primero blk_rq_nr_phys_segments(), y registró el resultado en nvme_tcp_setup_cmd_pdu() como req->data_len. El lado de recepción quedó sin cambios. Ambos difieren para REQ_OP_WRITE_ZEROES, que no tiene segmentos físicos pero tiene un blk_rq_bytes() distinto de cero, por lo que la configuración deja req->iter sin modificar mientras la verificación de recepción deja pasar un C2HData y nvme_tcp_recv_data() copia en lo que haya dejado allí el comando anterior con ese tag. El área privada del controlador solo se pone a cero cuando se asigna el conjunto de tags. Se reprodujo con un target de prueba que deja un iterador residual en un tag y luego envía un C2HData para un comando WRITE_ZEROES con el mismo tag: BUG: KASAN: wild-memory-access in _copy_to_iter+0x642/0x1330 Write of size 512 at addr ffe728c2175dfa81 by task kworker/0:1H/103 CPU: 0 UID: 0 PID: 103 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: nvme_tcp_wq nvme_tcp_io_work Call Trace: <TASK> dump_stack_lvl+0x53/0x70 kasan_report+0xce/0x100 ? _copy_to_iter+0x642/0x1330 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x642/0x1330 ? __pfx_sock_has_perm+0x10/0x10 ? worker_thread+0x45b/0xd10 ? __pfx__copy_to_iter+0x10/0x10 ? _raw_spin_lock_bh+0x83/0xe0 ? __pfx__raw_spin_lock_bh+0x10/0x10 __skb_datagram_iter+0xf3/0x820 ? __pfx_simple_copy_to_iter+0x10/0x10 ? __asan_memcpy+0x3c/0x60 ? skb_copy_bits+0x58d/0x830 skb_copy_datagram_iter+0x37/0x120 nvme_tcp_recv_skb+0xa07/0x4320 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 __tcp_read_sock+0x1ab/0x810 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 ? __pfx_lock_sock_nested+0x10/0x10 ? __pfx___tcp_read_sock+0x10/0x10 nvme_tcp_try_recv+0x152/0x1e0 ? __pfx_nvme_tcp_try_recv+0x10/0x10 ? __pfx_mutex_unlock+0x10/0x10 nvme_tcp_io_work+0x1e4/0x6c0 ? __schedule+0x181a/0x49f0 ? __pfx_nvme_tcp_io_work+0x10/0x10 process_one_work+0x633/0x1030 La corrección mantiene la verificación de blk_rq_payload_bytes() y le agrega req->data_len. La verificación anterior es la que rechaza un C2HData que nombra un tag que ya no está en curso, porque blk_update_request() pone a cero rq->__data_len al completarse; req->data_len y req->curr_bio son privados del controlador y sobreviven a la finalización, por lo que no pueden reemplazarla. La configuración inicializa el iterador solo cuando tanto req->curr_bio como req->data_len están establecidos, por lo que la verificación ahora comprueba esos mismos dos valores.
Qué hacer
Revisa si usas el producto afectado y en qué versión, y aplica la actualización o la mitigación que indique el aviso del fabricante. CISA no ha confirmado que se esté explotando; si eso cambia, esta ficha pasa a «explotada» y te avisamos en el boletín.
Versiones afectadas
- Linux Afectadas: 25e5cb780e62bde432b401f312bb847edc78b432 y anteriores a 32ea8ce96b9bd797c59c351ce490ffd97adaa8c0 · 25e5cb780e62bde432b401f312bb847edc78b432 y anteriores a dd8906bb8f8d5bf1c9f861e1382c82b87bfe7cab · 25e5cb780e62bde432b401f312bb847edc78b432 y anteriores a 7ed0b61bbc145988be292c4d3ec580aebd8d2bcd · 25e5cb780e62bde432b401f312bb847edc78b432 y anteriores a b96e1ff75e5c0ad6e077ac002b1d30b0a2b49528 · 25e5cb780e62bde432b401f312bb847edc78b432 y anteriores a b36161701cb366f416afdcf70771d432a7c74753 · 25e5cb780e62bde432b401f312bb847edc78b432 y anteriores a 6a01b58263108eaf9869bb6f82f07709240c6589 · 25e5cb780e62bde432b401f312bb847edc78b432 y anteriores a 641ad3a30ba560f0a9a610376c568d7b75d2a2aa · 25e5cb780e62bde432b401f312bb847edc78b432 y anteriores a 3a4aa9e6ad3e35f8e24d5eaf38ee4d437075fb36 · f507ae6e33cbe56c4e3fe000434fc0ecc263d098 · b1458c16f4e26e87492e58e4d24a1873bd09232a
- Linux Afectadas: 5.7 No afectadas: 5.10.270 · 5.15.221 · 6.1.188 · 6.6.157 · 6.12.109 · 6.18.50
Según el registro de la vulnerabilidad en CVE.org, tal como lo publicó el fabricante. Confirma tu versión exacta en el aviso del fabricante.
Referencias
- Referencia en git.kernel.orggit.kernel.org/stable/c/32ea8ce96b9bd797c59c351ce490ffd97adaa8c0
- Referencia en git.kernel.orggit.kernel.org/stable/c/dd8906bb8f8d5bf1c9f861e1382c82b87bfe7cab
- Referencia en git.kernel.orggit.kernel.org/stable/c/7ed0b61bbc145988be292c4d3ec580aebd8d2bcd
- Referencia en git.kernel.orggit.kernel.org/stable/c/b96e1ff75e5c0ad6e077ac002b1d30b0a2b49528
- Referencia en git.kernel.orggit.kernel.org/stable/c/b36161701cb366f416afdcf70771d432a7c74753
- Referencia en git.kernel.orggit.kernel.org/stable/c/6a01b58263108eaf9869bb6f82f07709240c6589
- Referencia en git.kernel.orggit.kernel.org/stable/c/641ad3a30ba560f0a9a610376c568d7b75d2a2aa
- Referencia en git.kernel.orggit.kernel.org/stable/c/3a4aa9e6ad3e35f8e24d5eaf38ee4d437075fb36
Ver el texto original en inglés (CVE.org)
nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone
In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone Commit 25e5cb780e62 ("nvme-tcp: fix possible crash in write_zeroes processing") established that blk_rq_payload_bytes() must not be read without first checking blk_rq_nr_phys_segments(), and recorded the result in nvme_tcp_setup_cmd_pdu() as req->data_len. The receive side was left as it was. The two differ for REQ_OP_WRITE_ZEROES, which has no physical segments but a non-zero blk_rq_bytes(), so setup leaves req->iter untouched while the receive gate lets a C2HData through and nvme_tcp_recv_data() copies into whatever the previous command on that tag left there. The driver-private area is zeroed only when the tag set is allocated. Reproduced with a test target that leaves a residual iterator on a tag and then sends a C2HData for a WRITE_ZEROES command on the same tag: BUG: KASAN: wild-memory-access in _copy_to_iter+0x642/0x1330 Write of size 512 at addr ffe728c2175dfa81 by task kworker/0:1H/103 CPU: 0 UID: 0 PID: 103 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: nvme_tcp_wq nvme_tcp_io_work Call Trace: <TASK> dump_stack_lvl+0x53/0x70 kasan_report+0xce/0x100 ? _copy_to_iter+0x642/0x1330 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x642/0x1330 ? __pfx_sock_has_perm+0x10/0x10 ? worker_thread+0x45b/0xd10 ? __pfx__copy_to_iter+0x10/0x10 ? _raw_spin_lock_bh+0x83/0xe0 ? __pfx__raw_spin_lock_bh+0x10/0x10 __skb_datagram_iter+0xf3/0x820 ? __pfx_simple_copy_to_iter+0x10/0x10 ? __asan_memcpy+0x3c/0x60 ? skb_copy_bits+0x58d/0x830 skb_copy_datagram_iter+0x37/0x120 nvme_tcp_recv_skb+0xa07/0x4320 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 __tcp_read_sock+0x1ab/0x810 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 ? __pfx_lock_sock_nested+0x10/0x10 ? __pfx___tcp_read_sock+0x10/0x10 nvme_tcp_try_recv+0x152/0x1e0 ? __pfx_nvme_tcp_try_recv+0x10/0x10 ? __pfx_mutex_unlock+0x10/0x10 nvme_tcp_io_work+0x1e4/0x6c0 ? __schedule+0x181a/0x49f0 ? __pfx_nvme_tcp_io_work+0x10/0x10 process_one_work+0x633/0x1030 Keep the blk_rq_payload_bytes() test and add req->data_len to it. The old test is what rejects a C2HData naming a tag that is no longer in flight, because blk_update_request() zeroes rq->__data_len on completion; req->data_len and req->curr_bio are driver-private and survive completion, so they cannot stand in for it. Setup initialises the iterator only when both req->curr_bio and req->data_len are set, so the gate now tests the same two.