{
  "threat_severity" : "Moderate",
  "public_date" : "2025-07-03T00:00:00Z",
  "bugzilla" : {
    "description" : "kernel: bpf: fix ktls panic with sockmap",
    "id" : "2376065",
    "url" : "https://bugzilla.redhat.com/show_bug.cgi?id=2376065"
  },
  "cvss3" : {
    "cvss3_base_score" : "5.5",
    "cvss3_scoring_vector" : "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
    "status" : "verified"
  },
  "cwe" : "CWE-131",
  "details" : [ "In the Linux kernel, the following vulnerability has been resolved:\nbpf: fix ktls panic with sockmap\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......\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().\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'''\nThe changes in this commit are based on the following considerations:\n1. When cork_bytes is set, rolling back to non-zero copy logic is\npointless and can directly go to zero-copy logic.\n2. We can not calculate the correct number of bytes to revert msg_iter.\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.\nHowever, some data in \"?fgh?\" is not within 'sg->msg_iter'\n(but in msg_pl instead), especially the data \"?\" we pushed.\nSo it doesn't seem as simple as just reverting through an offset of\nmsg_iter.\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.\nAdditionally, I saw that the current non-zero-copy logic for handling\ncorking is written as:\n'''\nline 1177\nelse if (ret != -EAGAIN) {\nif (ret == -ENOSPC)\nret = 0;\ngoto send_end;\n'''\nSo it's ok to just return 'copied' without error when a \"cork\" situation\noccurs." ],
  "affected_release" : [ {
    "product_name" : "Red Hat Enterprise Linux 10",
    "release_date" : "2026-05-19T00:00:00Z",
    "advisory" : "RHSA-2026:18134",
    "cpe" : "cpe:/o:redhat:enterprise_linux:10.2",
    "package" : "kernel-0:6.12.0-211.7.1.el10_2"
  }, {
    "product_name" : "Red Hat Enterprise Linux 9",
    "release_date" : "2026-05-19T00:00:00Z",
    "advisory" : "RHSA-2026:18587",
    "cpe" : "cpe:/a:redhat:enterprise_linux:9",
    "package" : "kernel-0:5.14.0-687.5.1.el9_8"
  }, {
    "product_name" : "Red Hat Enterprise Linux 9",
    "release_date" : "2026-05-19T00:00:00Z",
    "advisory" : "RHSA-2026:18587",
    "cpe" : "cpe:/o:redhat:enterprise_linux:9",
    "package" : "kernel-0:5.14.0-687.5.1.el9_8"
  } ],
  "package_state" : [ {
    "product_name" : "Red Hat Enterprise Linux 6",
    "fix_state" : "Not affected",
    "package_name" : "kernel",
    "cpe" : "cpe:/o:redhat:enterprise_linux:6"
  }, {
    "product_name" : "Red Hat Enterprise Linux 7",
    "fix_state" : "Not affected",
    "package_name" : "kernel",
    "cpe" : "cpe:/o:redhat:enterprise_linux:7"
  }, {
    "product_name" : "Red Hat Enterprise Linux 7",
    "fix_state" : "Not affected",
    "package_name" : "kernel-rt",
    "cpe" : "cpe:/o:redhat:enterprise_linux:7"
  }, {
    "product_name" : "Red Hat Enterprise Linux 8",
    "fix_state" : "Fix deferred",
    "package_name" : "kernel",
    "cpe" : "cpe:/o:redhat:enterprise_linux:8"
  }, {
    "product_name" : "Red Hat Enterprise Linux 8",
    "fix_state" : "Fix deferred",
    "package_name" : "kernel-rt",
    "cpe" : "cpe:/o:redhat:enterprise_linux:8"
  }, {
    "product_name" : "Red Hat Enterprise Linux 9",
    "fix_state" : "Fix deferred",
    "package_name" : "kernel-rt",
    "cpe" : "cpe:/o:redhat:enterprise_linux:9"
  } ],
  "references" : [ "https://www.cve.org/CVERecord?id=CVE-2025-38166\nhttps://nvd.nist.gov/vuln/detail/CVE-2025-38166\nhttps://lore.kernel.org/linux-cve-announce/2025070341-CVE-2025-38166-3dc8@gregkh/T" ],
  "name" : "CVE-2025-38166",
  "csaw" : false
}