Descripción
En el kernel de Linux se resolvió la siguiente vulnerabilidad: svcrdma: corregir pcl_for_each_segment para chunks vacíos. Cuando una lista de chunks analizada contiene un chunk cuyo ch_segcount es cero, pcl_for_each_segment calcula su límite superior inclusivo como &chunk->ch_segments[ch_segcount - 1]. ch_segcount es u32, por lo que la resta da la vuelta a 0xFFFFFFFF y el límite queda muy por fuera del arreglo flexible ch_segments. El cuerpo del bucle recorre entonces memoria no relacionada con un paso de sizeof(struct svc_rdma_segment) hasta producir un fallo. Un chunk con segcount cero es alcanzable desde la red: xdr_check_write_chunk() solo rechaza valores de segcount mayores que rc_maxpages, y pcl_alloc_write() enlaza un chunk recién asignado en rc_write_pcl/rc_reply_pcl antes de que se ejecute su bucle de llenado de segmentos, por lo que un Write o Reply chunk que anuncia cero segmentos deja ch_segcount == 0 en la lista. Cuando el transporte ha negociado Send-With-Invalidate, svc_rdma_get_inv_rkey() itera las cuatro PCL con pcl_for_each_segment y desreferencia segment->rs_handle en cada iteración, convirtiendo el subdesbordamiento en una lectura fuera de límites y un general protection fault. xdr_check_write_list / xdr_check_reply_chunk pcl_alloc_write() chunk = pcl_alloc_chunk(...) /* ch_segcount = 0 */ list_add_tail(&chunk->ch_list, &pcl->cl_chunks) /* fill loop iterates zero times for wire segcount 0 */ svc_rdma_get_inv_rkey() pcl_for_each_chunk(rc_write_pcl) pcl_for_each_segment(segment, chunk) pos <= &ch_segments[0u - 1u] /* 0xFFFFFFFF */ segment->rs_handle /* OOB read -> GPF */ La corrección cambia la macro a un límite superior semiabierto que usa ch_segcount directamente. Para ch_segcount == 0, el inicio del bucle es igual al final y se omite el cuerpo; para ch_segcount > 0, el rango de iteración no cambia. Los seis puntos de llamada existentes en net/sunrpc/xprtrdma/svc_rdma_recvfrom.c y net/sunrpc/xprtrdma/svc_rdma_rw.c siguen siendo correctos con el nuevo límite, por lo que no se requieren cambios en los llamadores.
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: 78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 y anteriores a 1e2e3481e39103a386b86be1c33eaef97cbdf16e · 78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 y anteriores a 3a78b841879c2a3243f74edc514236fb2907167f · 78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 y anteriores a 06d0390c37fa6714624af771bd72bbf1a7ed9bb1 · 78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 y anteriores a 9c5a03c3dc505c0295339b0a1b9e4fe36447e482 · 78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 y anteriores a a1c954ca4977a4e6ec73ef92fe48073ec54f9fc8 · 78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 y anteriores a 6d33a7e6bf6c6b293a266a617201285a1ad32c56 · 78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 y anteriores a b7713a784c59515d0aba558c8f5df6a0164dd3a9
- Linux Afectadas: 5.11 No afectadas: 5.15.221 · 6.1.188 · 6.6.157 · 6.12.109 · 6.18.50 · 7.2.4
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/1e2e3481e39103a386b86be1c33eaef97cbdf16e
- Referencia en git.kernel.orggit.kernel.org/stable/c/3a78b841879c2a3243f74edc514236fb2907167f
- Referencia en git.kernel.orggit.kernel.org/stable/c/06d0390c37fa6714624af771bd72bbf1a7ed9bb1
- Referencia en git.kernel.orggit.kernel.org/stable/c/9c5a03c3dc505c0295339b0a1b9e4fe36447e482
- Referencia en git.kernel.orggit.kernel.org/stable/c/a1c954ca4977a4e6ec73ef92fe48073ec54f9fc8
- Referencia en git.kernel.orggit.kernel.org/stable/c/6d33a7e6bf6c6b293a266a617201285a1ad32c56
- Referencia en git.kernel.orggit.kernel.org/stable/c/b7713a784c59515d0aba558c8f5df6a0164dd3a9
Ver el texto original en inglés (CVE.org)
svcrdma: Fix pcl_for_each_segment for empty chunks
In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix pcl_for_each_segment for empty chunks When a parsed chunk list contains a chunk whose ch_segcount is zero, pcl_for_each_segment computes its inclusive upper bound as &chunk->ch_segments[ch_segcount - 1]. ch_segcount is u32, so the subtraction wraps to 0xFFFFFFFF and the bound lands far past the ch_segments flex array. The loop body then walks unrelated memory at sizeof(struct svc_rdma_segment) stride until it faults. A zero-segcount chunk is reachable from the wire: xdr_check_write_chunk() only rejects segcount values greater than rc_maxpages, and pcl_alloc_write() links a freshly allocated chunk onto rc_write_pcl/rc_reply_pcl before its segment-fill loop runs, so a Write or Reply chunk advertising zero segments leaves ch_segcount == 0 on the list. When the transport has negotiated Send-With-Invalidate, svc_rdma_get_inv_rkey() iterates all four PCLs with pcl_for_each_segment and dereferences segment->rs_handle on each iteration, turning the underflow into an out-of-bounds read and a general protection fault. xdr_check_write_list / xdr_check_reply_chunk pcl_alloc_write() chunk = pcl_alloc_chunk(...) /* ch_segcount = 0 */ list_add_tail(&chunk->ch_list, &pcl->cl_chunks) /* fill loop iterates zero times for wire segcount 0 */ svc_rdma_get_inv_rkey() pcl_for_each_chunk(rc_write_pcl) pcl_for_each_segment(segment, chunk) pos <= &ch_segments[0u - 1u] /* 0xFFFFFFFF */ segment->rs_handle /* OOB read -> GPF */ Fix by switching the macro to a half-open upper bound that uses ch_segcount directly. For ch_segcount == 0 the loop start equals the loop end and the body is skipped; for ch_segcount > 0 the iteration range is unchanged. All six existing call sites in net/sunrpc/xprtrdma/svc_rdma_recvfrom.c and net/sunrpc/xprtrdma/svc_rdma_rw.c remain correct under the new bound, so no caller changes are needed.