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] <TASK>
[ 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) {
if (ret == -ENOSPC)
ret = 0;
goto send_end;
'''
So it's ok to just return 'copied' without error when a "cork" situation
occurs.
Security readout for executives and security teams
Plain-English summary
A flaw in the Linux kernel’s interaction between BPF sockmaps and kernel TLS can trigger a kernel panic during message handling. Exploitation requires local access and a specific feature combination, limiting broad exposure. Successful triggering could disrupt affected systems; the supplied CVSS assessment also indicates possible confidentiality and integrity impact, although the technical description primarily demonstrates a crash.
Executive priority
Treat this as a high-priority kernel maintenance issue where the affected feature combination is present, particularly on shared or locally accessible systems. Broad emergency action is not supported by the evidence because exploitation is local, configuration-dependent, and not documented as active. Establish exposure quickly, then patch confirmed systems through normal expedited kernel update procedures.
Technical view
After a BPF transmit verdict changes a scatter-gather message, corking can produce an ENOSPC rollback. The rollback resets the message iterator but uses the enlarged scatter-gather size, allowing iov_iter_revert to exceed the iterator’s actual size and reach a kernel BUG. The resolution changes handling so corked traffic proceeds through the appropriate zero-copy path instead of the unsafe rollback.
Likely exposure
Exposure is most likely on Linux systems using BPF sockmaps together with kernel TLS and permitting a low-privileged local actor to reach the vulnerable path. The record identifies Linux versions including 4.20, 6.1.142, 6.6.94, 6.12.34, 6.15.3, and 6.16, but distribution backports require vendor-specific verification.
Exploitation context
The supplied record has CVSS 7.8 with local access, low complexity, low privileges, and no user interaction. It is not listed as KEV, and no supplied source establishes active exploitation. The described reproducible outcome is a kernel panic; the record’s confidentiality and integrity ratings are not further demonstrated in the supplied technical narrative.
Researcher notes
The unsafe state arises because BPF message mutation increases msg_pl->sg.size while the underlying iterator does not represent all pushed data. Corking then makes an exact iterator rollback impractical. The source bundle lists multiple stable commits, suggesting branch-specific fixes. Exact vulnerable ranges and distro package mappings remain incomplete and should be resolved through upstream and distribution advisories.
Mitigation direction
Apply a vendor-supported kernel update containing the relevant stable fix or backport.
Check distribution advisories because package versions may not match upstream kernel version numbers.
Prioritize systems that use both BPF sockmaps and kernel TLS.
If patching is delayed, obtain supported temporary mitigation guidance from the kernel or distribution vendor.
Validation and detection
Inventory deployed kernel builds and compare them with vendor-fixed package information.
Confirm whether BPF sockmaps and kernel TLS are used on potentially affected hosts.
Verify the installed kernel includes the applicable referenced stable commit or vendor backport.
Review kernel logs for BUG events involving iov_iter_revert or tls_sw_sendmsg.
Retest affected workloads after updating and monitor for recurring kernel panics.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-38166 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
7Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.