[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"repo-stars":3,"vuln-DEBIAN-CVE-2025-38166":6},{"stargazers_count":4,"fetched_at":5},7,"2026-06-04T20:55:29.923Z",{"id":7,"descriptions":8,"cisa":9,"weaknesses":10,"exploits":11,"aliases":12,"duplicate_of":9,"upstream":13,"downstream":16,"duplicates":21,"related":22,"reserved_at":9,"published_at":23,"modified_at":24,"state":9,"summary":25,"references_raw":27,"kevs":34,"epss":9,"epss_history":35,"metrics":36,"affected":43},"DEBIAN-CVE-2025-38166","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> [ 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->sg 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->msg_iter is reset, but since msg_pl->sg.size has been increased, subsequent executions will exceed the actual size of msg_iter. ''' iov_iter_revert(&msg->msg_iter, msg_pl->sg.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->msg_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.",null,[],[],[],[14],{"_key":15},"CVE-2025-38166",[17,19],{"_key":18},"DLA-4328-1",{"_key":20},"DSA-5973-1",[],[],"2025-07-03T09:15:32.120Z","2026-04-28T20:29:53.440637Z",{"cisa_kev":26,"cisa_ransomware":26,"cisa_vendor":9,"epss_severity":9,"epss_score":9,"severity":9,"severity_score":9,"severity_version":9,"severity_source":9,"severity_vector":9,"severity_status":9},false,[28],{"url":29,"sources":30,"tags":32},"https://security-tracker.debian.org/tracker/CVE-2025-38166",[31],"osv_debian",[33],"Advisory",[],[],[37],{"source":31,"cvss_v2_0":9,"cvss_v3_0":9,"cvss_v3_1":38,"cvss_v4_0":9},{"baseScore":39,"baseSeverity":9,"vectorString":40,"impactScore":41,"exploitabilityScore":42},5.5,"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",6,4.6,[44,62],{"ecosystem":45,"name":46,"vendor":47,"product":46,"cpe_part":9,"purl_type":48,"purl_namespace":47,"purl_name":46,"source":9,"versions":49},"Debian","linux","debian","deb",[50,54,58,61],{"version":51,"is_range":52,"range_type":53,"version_start":9,"version_start_type":9,"version_end":9,"version_end_type":9,"fixed_in":9},"all",true,"ecosystem",{"version":55,"is_range":52,"range_type":53,"version_start":9,"version_start_type":9,"version_end":56,"version_end_type":57,"fixed_in":9},"lt6_1_147_1","6.1.147-1","excluding",{"version":59,"is_range":52,"range_type":53,"version_start":9,"version_start_type":9,"version_end":60,"version_end_type":57,"fixed_in":9},"lt6_12_35_1","6.12.35-1",{"version":59,"is_range":52,"range_type":53,"version_start":9,"version_start_type":9,"version_end":60,"version_end_type":57,"fixed_in":9},{"ecosystem":45,"name":63,"vendor":47,"product":63,"cpe_part":9,"purl_type":48,"purl_namespace":47,"purl_name":63,"source":9,"versions":64},"linux-6.1",[65],{"version":66,"is_range":52,"range_type":53,"version_start":9,"version_start_type":9,"version_end":67,"version_end_type":57,"fixed_in":9},"lt6_1_153_1~deb11u1","6.1.153-1~deb11u1"]