CVE-2026-90414 in Linux
Resumen
por VulDB • 2026-09-18
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
IB/isert: rechazar PDUs que declaren más datos de los recibidos
isert_recv_done() pasa cada PDU recibido a los controladores de opcode sin mirar nunca wc->byte_len, el número de bytes que el HCA colocó realmente en el descriptor de recepción. Los controladores luego copian esa cantidad de bytes - la longitud del segmento de datos declarada por el iniciador en el BHS (ntoh24(hdr->dlength), a través de unsol_data_len / imm_data_len derivados) - fuera del descriptor de tamaño fijo:
isert_handle_iscsi_dataout(): sg_copy_from_buffer(sg_start, sg_nents, isert_get_data(rx_desc), unsol_data_len); isert_handle_scsi_cmd(): sg_copy_from_buffer(cmd->se_cmd.t_data_sg, sg_nents, isert_get_data(rx_desc), imm_data_len);
Dado que la longitud declarada nunca se verifica contra wc->byte_len, un iniciador puede declarar un segmento de datos más grande que los bytes que realmente envió (y más grande que el descriptor) y provocar una lectura fuera de límites del búfer de recepción.
Ningún código anterior a isert cierra esta puerta:
- __iscsit_check_dataout_hdr() limita la carga útil entrante contra conn_ops->MaxXmitDataSegmentLength (MXDSL), un parámetro de transmisión, utilizado aquí para la verificación entrante. - iscsi_set_connection_parameters() establece ops->MaxXmitDataSegmentLength = ops->TargetRecvDataSegmentLength; y TARGETRECVDATASEGMENTLENGTH está ausente en la lista min()-clamp en iscsi_check_acceptor_state(), por lo que el valor declarado por el iniciador se adopta literalmente (rango de tipo 512..16777215). El iniciador efectivamente eleva su propio límite. - isert nunca ajusta al alza el valor negociado a su propio descriptor de recepción fijo (ISER_RX_SIZE, 9216 bytes), por lo que la limitación del núcleo del objetivo y el tamaño del descriptor no están relacionados.
La ruta imm_data_len == data_len es más que una sobrelectura: aliasa el descriptor de recepción mediante sg_set_buf() y se lo pasa al backend como fuente de datos para la escritura SCSI, por lo que una longitud declarada en exceso provoca que los contenidos del heap posteriores al descriptor se escriban a través del backend hacia el almacenamiento subyacente. El backend es la víctima de la scatterlist sobredimensionada que le entrega isert, no la causa; no se demostró ninguna lectura posterior de los bytes escritos.
Disparador: después de completar el inicio de sesión (fase completa de características), un iniciador que ha declarado una TargetRecvDataSegmentLength grande y una FirstBurstLength que permite datos no solicitados/inmediatos envía una PDU cuya longitud declarada del segmento de datos excede lo recibido. Con KASAN:
BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 Read of size 4096 at addr ffff888109720800 by task kworker/1:0H/25 Workqueue: ib-comp-wq ib_cq_poll_work Call Trace: sg_copy_buffer+0x150/0x1c0 isert_recv_done+0xba6/0x2390 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150
isert_recv_done+0xba6 se resuelve en isert_handle_iscsi_dataout() (ib_isert.c:1160), integrado a través de isert_rx_opcode().
Validar wc->byte_len contra el encuadre en isert_recv_done() antes de que la PDU llegue a cualquier controlador, y restablecer la conexión si es corta. Dado que la prueba compara sin restar la longitud del encabezado, también rechaza PDUs más cortas que los encabezados iSER e iSCSI, lo cual de otro modo se analizaría fuera de contenidos obsoletos del descriptor. El controlador de inicio de sesión rechaza PDUs más cortas que ISER_HEADERS_LEN (commit 29e7b925ae6d ("IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN")) pero tampoco limita la longitud declarada; eso se corrige en el siguiente parche. Los controladores de datos no tenían ninguna verificación de longitud.
isert lee el segmento de datos desde un desplazamiento fijo: isert_get_data() devuelve el encabezado iSER más ISER_HEADERS_LEN y no realiza ajustes para una AHS. Por lo tanto, los bytes que tocan los controladores son exactamente [ISER_HEADERS_LEN, ISER_HEADERS_LEN + dlength), y comparar esa suma contra wc->byte_len limita precisamente la región que se lee. Un término AHS solo haría la prueba más estricta sin limitar nada más
---truncado---
If you want to get best quality of vulnerability data, you may have to visit VulDB.