{"id":"DEBIAN-CVE-2025-38166","details":"In the Linux kernel, the following vulnerability has been resolved:  bpf: fix ktls panic with sockmap  [ 2172.936997] ------------[ cut here ]------------ [ 2172.936999] kernel BUG at lib/iov_iter.c:629! ...... [ 2172.944996] PKRU: 55555554 [ 2172.945155] Call Trace: [ 2172.945299]  \u003cTASK\u003e [ 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 ......  After calling bpf_exec_tx_verdict(), the size of msg_pl-\u003esg may increase, e.g., when the BPF program executes bpf_msg_push_data().  If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes, it will return -ENOSPC and attempt to roll back to the non-zero copy logic. However, during rollback, msg-\u003emsg_iter is reset, but since msg_pl-\u003esg.size has been increased, subsequent executions will exceed the actual size of msg_iter. ''' iov_iter_revert(&msg-\u003emsg_iter, msg_pl-\u003esg.size - orig_size); '''  The changes in this commit are based on the following considerations:  1. When cork_bytes is set, rolling back to non-zero copy logic is pointless and can directly go to zero-copy logic.  2. We can not calculate the correct number of bytes to revert msg_iter.  Assume the original data is \"abcdefgh\" (8 bytes), and after 3 pushes by the BPF program, it becomes 11-byte data: \"abc?de?fgh?\". Then, we set cork_bytes to 6, which means the first 6 bytes have been processed, and the remaining 5 bytes \"?fgh?\" will be cached until the length meets the cork_bytes requirement.  However, some data in \"?fgh?\" is not within 'sg-\u003emsg_iter' (but in msg_pl instead), especially the data \"?\" we pushed.  So it doesn't seem as simple as just reverting through an offset of msg_iter.  3. For non-TLS sockets in tcp_bpf_sendmsg, when a \"cork\" situation occurs, the user-space send() doesn't return an error, and the returned length is the same as the input length parameter, even if some data is cached.  Additionally, I saw that the current non-zero-copy logic for handling corking is written as: ''' line 1177 else if (ret != -EAGAIN) { \tif (ret == -ENOSPC) \t\tret = 0; \tgoto send_end; '''  So it's ok to just return 'copied' without error when a \"cork\" situation occurs.","modified":"2026-09-01T16:06:13.965513921Z","published":"2025-07-03T09:15:32.120Z","upstream":["CVE-2025-38166"],"references":[{"type":"ADVISORY","url":"https://security-tracker.debian.org/tracker/CVE-2025-38166"}],"affected":[{"package":{"name":"linux","ecosystem":"Debian:12","purl":"pkg:deb/debian/linux?arch=source&distro=bookworm"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.1.147-1"}]}],"versions":["6.1.106-1","6.1.106-2","6.1.106-3","6.1.112-1","6.1.115-1","6.1.119-1","6.1.123-1","6.1.124-1","6.1.128-1","6.1.129-1","6.1.133-1","6.1.135-1","6.1.137-1","6.1.139-1","6.1.140-1","6.1.27-1","6.1.37-1","6.1.38-1","6.1.38-2","6.1.38-2~bpo11+1","6.1.38-3","6.1.38-4","6.1.38-4~bpo11+1","6.1.52-1","6.1.55-1","6.1.55-1~bpo11+1","6.1.64-1","6.1.66-1","6.1.67-1","6.1.69-1","6.1.69-1~bpo11+1","6.1.76-1","6.1.76-1~bpo11+1","6.1.82-1","6.1.85-1","6.1.90-1","6.1.90-1~bpo11+1","6.1.94-1","6.1.94-1~bpo11+1","6.1.98-1","6.1.99-1"],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2025-38166.json"}},{"package":{"name":"linux","ecosystem":"Debian:13","purl":"pkg:deb/debian/linux?arch=source&distro=trixie"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.12.35-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2025-38166.json"}},{"package":{"name":"linux","ecosystem":"Debian:14","purl":"pkg:deb/debian/linux?arch=source&distro=forky"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.12.35-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2025-38166.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"}]}