CVE-2025-38166

{"id": "CVE-2025-38166", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.5, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 1.8}]}, "published": "2025-07-03T09:15:32.120", "references": [{"url": "https://git.kernel.org/stable/c/2e36a81d388ec9c3f78b6223f7eda2088cd40adb", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/328cac3f9f8ae394748485e769a527518a9137c8", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/54a3ecaeeeae8176da8badbd7d72af1017032c39", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/57fbbe29e86042bbaa31c1a30d2afa16c427e3f7", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/603943f022a7fe5cc83ca7005faf34798fb7853f", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html", "tags": ["Third Party Advisory"], "source": "af854a3a-2127-422b-91ae-364da2661108"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "NVD-CWE-noinfo"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: fix ktls panic with sockmap\n\n[ 2172.936997] ------------[ cut here ]------------\n[ 2172.936999] kernel BUG at lib/iov_iter.c:629!\n......\n[ 2172.944996] PKRU: 55555554\n[ 2172.945155] Call Trace:\n[ 2172.945299] <TASK>\n[ 2172.945428] ? die+0x36/0x90\n[ 2172.945601] ? do_trap+0xdd/0x100\n[ 2172.945795] ? iov_iter_revert+0x178/0x180\n[ 2172.946031] ? iov_iter_revert+0x178/0x180\n[ 2172.946267] ? do_error_trap+0x7d/0x110\n[ 2172.946499] ? iov_iter_revert+0x178/0x180\n[ 2172.946736] ? exc_invalid_op+0x50/0x70\n[ 2172.946961] ? iov_iter_revert+0x178/0x180\n[ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20\n[ 2172.947446] ? iov_iter_revert+0x178/0x180\n[ 2172.947683] ? iov_iter_revert+0x5c/0x180\n[ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840\n[ 2172.948206] tls_sw_sendmsg+0x52/0x80\n[ 2172.948420] ? inet_sendmsg+0x1f/0x70\n[ 2172.948634] __sys_sendto+0x1cd/0x200\n[ 2172.948848] ? find_held_lock+0x2b/0x80\n[ 2172.949072] ? syscall_trace_enter+0x140/0x270\n[ 2172.949330] ? __lock_release.isra.0+0x5e/0x170\n[ 2172.949595] ? find_held_lock+0x2b/0x80\n[ 2172.949817] ? syscall_trace_enter+0x140/0x270\n[ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190\n[ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0\n[ 2172.951036] __x64_sys_sendto+0x24/0x30\n[ 2172.951382] do_syscall_64+0x90/0x170\n......\n\nAfter calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase,\ne.g., when the BPF program executes bpf_msg_push_data().\n\nIf the BPF program sets cork_bytes and sg.size is smaller than cork_bytes,\nit will return -ENOSPC and attempt to roll back to the non-zero copy\nlogic. However, during rollback, msg->msg_iter is reset, but since\nmsg_pl->sg.size has been increased, subsequent executions will exceed the\nactual size of msg_iter.\n'''\niov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size);\n'''\n\nThe changes in this commit are based on the following considerations:\n\n1. When cork_bytes is set, rolling back to non-zero copy logic is\npointless and can directly go to zero-copy logic.\n\n2. We can not calculate the correct number of bytes to revert msg_iter.\n\nAssume the original data is \"abcdefgh\" (8 bytes), and after 3 pushes\nby the BPF program, it becomes 11-byte data: \"abc?de?fgh?\".\nThen, we set cork_bytes to 6, which means the first 6 bytes have been\nprocessed, and the remaining 5 bytes \"?fgh?\" will be cached until the\nlength meets the cork_bytes requirement.\n\nHowever, some data in \"?fgh?\" is not within 'sg->msg_iter'\n(but in msg_pl instead), especially the data \"?\" we pushed.\n\nSo it doesn't seem as simple as just reverting through an offset of\nmsg_iter.\n\n3. For non-TLS sockets in tcp_bpf_sendmsg, when a \"cork\" situation occurs,\nthe user-space send() doesn't return an error, and the returned length is\nthe same as the input length parameter, even if some data is cached.\n\nAdditionally, I saw that the current non-zero-copy logic for handling\ncorking is written as:\n'''\nline 1177\nelse if (ret != -EAGAIN) {\n\tif (ret == -ENOSPC)\n\t\tret = 0;\n\tgoto send_end;\n'''\n\nSo it's ok to just return 'copied' without error when a \"cork\" situation\noccurs."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corregir p\u00e1nico ktls con sockmap [ 2172.936997] ------------[ cortar aqu\u00ed ]------------ [ 2172.936999] ERROR del kernel en lib/iov_iter.c:629! ...... [ 2172.944996] PKRU: 55555554 [ 2172.945155] Rastreo de llamadas: [ 2172.945299] [ 2172.945428] ? die+0x36/0x90 [ 2172.945601] ? do_trap+0xdd/0x100 [ 2172.945795] ? iov_iter_revert+0x178/0x180 [ 2172.946031] ? iov_iter_revert+0x178/0x180 [ 2172.946267] ? do_error_trap+0x7d/0x110 [ 2172.946499] ? iov_iter_revert+0x178/0x180 [ 2172.946736] ? exc_invalid_op+0x50/0x70 [ 2172.946961] ? iov_iter_revert+0x178/0x180 [ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20 [ 2172.947446] ? iov_iter_revert+0x178/0x180 [ 2172.947683] ? iov_iter_revert+0x5c/0x180 [ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840 [ 2172.948206] tls_sw_sendmsg+0x52/0x80 [ 2172.948420] ? inet_sendmsg+0x1f/0x70 [ 2172.948634] __sys_sendto+0x1cd/0x200 [ 2172.948848] ? find_held_lock+0x2b/0x80 [ 2172.949072] ? syscall_trace_enter+0x140/0x270 [ 2172.949330] ? __lock_release.isra.0+0x5e/0x170 [ 2172.949595] ? find_held_lock+0x2b/0x80 [ 2172.949817] ? syscall_trace_enter+0x140/0x270 [ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190 [ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0 [ 2172.951036] __x64_sys_sendto+0x24/0x30 [ 2172.951382] do_syscall_64+0x90/0x170 ...... Despu\u00e9s de llamar a bpf_exec_tx_verdict(), el tama\u00f1o de msg_pl-&gt;sg puede aumentar, por ejemplo, cuando el programa BPF ejecuta bpf_msg_push_data(). Si el programa BPF define cork_bytes y sg.size es menor que cork_bytes, devolver\u00e1 -ENOSPC e intentar\u00e1 revertir a la l\u00f3gica de copia no nula. Sin embargo, durante la reversi\u00f3n, msg-&gt;msg_iter se restablece, pero como se ha aumentado msg_pl-&gt;sg.size, las ejecuciones posteriores superar\u00e1n el tama\u00f1o real de msg_iter. ''' iov_iter_revert(&amp;msg-&gt;msg_iter, msg_pl-&gt;sg.size - orig_size); ''' Los cambios en esta confirmaci\u00f3n se basan en las siguientes consideraciones: 1. Cuando se establece cork_bytes, revertir a la l\u00f3gica de copia no nula no tiene sentido y se puede pasar directamente a la l\u00f3gica de copia cero. 2. No podemos calcular el n\u00famero correcto de bytes para revertir msg_iter. Supongamos que los datos originales son \"abcdefgh\" (8 bytes) y, tras 3 intentos del programa BPF, se convierten en datos de 11 bytes: \"abc?de?fgh?\". Luego, configuramos cork_bytes en 6, lo que significa que los primeros 6 bytes se han procesado y los 5 bytes restantes de \"?fgh?\" se almacenar\u00e1n en cach\u00e9 hasta que la longitud cumpla con el requisito de cork_bytes. Sin embargo, algunos datos en \"?fgh?\" no est\u00e1n dentro de 'sg-&gt;msg_iter' (sino en msg_pl), especialmente los datos \"?\" que enviamos. Por lo tanto, no parece tan sencillo como revertir a trav\u00e9s de un desplazamiento de msg_iter. 3. Para sockets sin TLS en tcp_bpf_sendmsg, cuando se produce una situaci\u00f3n de \"cork\", la funci\u00f3n send() en el espacio de usuario no devuelve un error y la longitud devuelta es la misma que el par\u00e1metro de longitud de entrada, incluso si algunos datos est\u00e1n almacenados en cach\u00e9. Adem\u00e1s, observ\u00e9 que la l\u00f3gica actual de copia distinta de cero para gestionar el cork se escribe as\u00ed: ''' l\u00ednea 1177 else if (ret != -EAGAIN) { if (ret == -ENOSPC) ret = 0; goto send_end; ''' Por lo tanto, est\u00e1 bien simplemente devolver 'copiado' sin error cuando ocurre una situaci\u00f3n de \"corcho\"."}], "lastModified": "2025-12-18T20:51:59.933", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "99E6724B-C244-433B-ABF6-9D1CDB08578E", "versionEndExcluding": "6.1.142", "versionStartIncluding": "4.20"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "304E3F01-7D7A-4908-994E-7F95C5C00B06", "versionEndExcluding": "6.6.94", "versionStartIncluding": "6.2"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "4FFA54AA-CDFE-4591-BD07-72813D0948F4", "versionEndExcluding": "6.12.34", "versionStartIncluding": "6.7"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "0541C761-BD5E-4C1A-8432-83B375D7EB92", "versionEndExcluding": "6.15.3", "versionStartIncluding": "6.13"}], "operator": "OR"}]}, {"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "FA6FEEC2-9F11-4643-8827-749718254FED"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}