{"cve":"CVE-2025-38166","nvd":{"published":"2025-07-03T09:15:32.120","modified":"2026-10-15T22:18:31.583","status":"Modified","description":"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.","cvss_v4":null,"cvss_v3":{"version":"3.1","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","score":5.5},"cwes":[],"references":["https://git.kernel.org/stable/c/2e36a81d388ec9c3f78b6223f7eda2088cd40adb","https://git.kernel.org/stable/c/328cac3f9f8ae394748485e769a527518a9137c8","https://git.kernel.org/stable/c/54a3ecaeeeae8176da8badbd7d72af1017032c39","https://git.kernel.org/stable/c/57fbbe29e86042bbaa31c1a30d2afa16c427e3f7","https://git.kernel.org/stable/c/603943f022a7fe5cc83ca7005faf34798fb7853f"],"products":["debian:debian_linux","linux:linux_kernel"],"source":"nvd","synced_at":"2026-10-19T22:04:28.436527499+00:00"},"epss":{"cve":"CVE-2025-38166","score":0.00199,"percentile":0.09577,"date":"2026-10-25"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}