CVE-2026-43244

In the Linux kernel, the following vulnerability has been resolved: kcm: fix zero-frag skb in frag_list on partial sendmsg error Syzkaller reported a warning in kcm_write_msgs() when processing a message with a zero-fragment skb in the frag_list. When kcm_sendmsg() fills MAX_SKB_FRAGS fragments in the current skb, it allocates a new skb (tskb) and links it into the frag_list before copying data. If the copy subsequently fails (e.g. -EFAULT from user memory), tskb remains in the frag_list with zero fragments: head skb (msg being assembled, NOT yet in sk_write_queue) +-----------+ | frags[17] | (MAX_SKB_FRAGS, all filled with data) | frag_list-+--> tskb +-----------+ +----------+ | frags[0] | (empty! copy failed before filling) +----------+ For SOCK_SEQPACKET with partial data already copied, the error path saves this message via partial_message for later completion. For SOCK_SEQPACKET, sock_write_iter() automatically sets MSG_EOR, so a subsequent zero-length write(fd, NULL, 0) completes the message and queues it to sk_write_queue. kcm_write_msgs() then walks the frag_list and hits: WARN_ON(!skb_shinfo(skb)->nr_frags) TCP has a similar pattern where skbs are enqueued before data copy and cleaned up on failure via tcp_remove_empty_skb(). KCM was missing the equivalent cleanup. Fix this by tracking the predecessor skb (frag_prev) when allocating a new frag_list entry. On error, if the tail skb has zero frags, use frag_prev to unlink and free it in O(1) without walking the singly-linked frag_list. frag_prev is safe to dereference because the entire message chain is only held locally (or in kcm->seq_skb) and is not added to sk_write_queue until MSG_EOR, so the send path cannot free it underneath us. Also change the WARN_ON to WARN_ON_ONCE to avoid flooding the log if the condition is somehow hit repeatedly. There are currently no KCM selftests in the kernel tree; a simple reproducer is available at [1]. [1] https://gist.github.com/mrpre/a94d431c757e8d6f168f4dd1a3749daa
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*

History

11 Nov 2026, 20:10

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: kcm: corrige skb de cero fragmentos en frag_list en error parcial de sendmsg Syzkaller informó una advertencia en kcm_write_msgs() al procesar un mensaje con un skb de cero fragmentos en la frag_list. Cuando kcm_sendmsg() llena fragmentos MAX_SKB_FRAGS en el skb actual, asigna un nuevo skb (tskb) y lo enlaza en la frag_list antes de copiar datos. Si la copia falla posteriormente (por ejemplo, -EFAULT de la memoria de usuario), tskb permanece en la frag_list con cero fragmentos: skb de cabecera (mensaje en ensamblaje, AÚN NO en sk_write_queue) +-----------+ | frags[17] | (MAX_SKB_FRAGS, todos llenos de datos) | frag_list-+ - tskb +-----------+ +----------+ | frags[0] | (¡vacío! la copia falló antes de llenarse) +----------+ Para SOCK_SEQPACKET con datos parciales ya copiados, la ruta de error guarda este mensaje a través de partial_message para su posterior finalización. Para SOCK_SEQPACKET, sock_write_iter() establece automáticamente MSG_EOR, por lo que una escritura posterior de longitud cero write(fd, NULL, 0) completa el mensaje y lo encola en sk_write_queue. kcm_write_msgs() luego recorre la frag_list y encuentra: WARN_ON(!skb_shinfo(skb) -> nr_frags) TCP tiene un patrón similar donde los skbs se encolan antes de la copia de datos y se limpian en caso de fallo a través de tcp_remove_empty_skb(). A KCM le faltaba la limpieza equivalente. Solucione esto rastreando el skb predecesor (frag_prev) al asignar una nueva entrada de frag_list. En caso de error, si el skb de cola tiene cero fragmentos, use frag_prev para desenlazarlo y liberarlo en O(1) sin recorrer la frag_list de enlace simple. Es seguro desreferenciar frag_prev porque toda la cadena de mensajes solo se mantiene localmente (o en kcm -> seq_skb) y no se añade a sk_write_queue hasta MSG_EOR, por lo que la ruta de envío no puede liberarlo por debajo de nosotros. También cambie el WARN_ON a WARN_ON_ONCE para evitar inundar el registro si la condición se cumple repetidamente de alguna manera. Actualmente no hay KCM selftests en el árbol del kernel; un reproductor simple está disponible en [1]. [1] https://gist.github.com/mrpre/a94d431c757e8d6f168f4dd1a3749daa

30 Oct 2026, 13:18

Type Values Removed Values Added
References
  • () https://git.kernel.org/stable/c/d6dcbcc8d630d14e9651fe93a9386b35f4dcfd56 -

21 Oct 2026, 13:18

Type Values Removed Values Added
References
  • () https://git.kernel.org/stable/c/6f129a251c2795ba55dd5cc1fdf7e0af3098d848 -

Information

Published : 2026-05-06 12:16

Updated : 2026-11-11 20:10


NVD link : CVE-2026-43244

Mitre link : CVE-2026-43244

CVE.ORG link : CVE-2026-43244


JSON object : View

Products Affected

linux

  • linux_kernel
CWE
CWE-401

Missing Release of Memory after Effective Lifetime