CVE-2025-38166 (GCVE-0-2025-38166)

Vulnerability from cvelistv5 – Published: 2025-07-03 08:36 – Updated: 2026-08-05 11:59
VLAI
Title
bpf: fix ktls panic with sockmap
Summary
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.
Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Assigner
References
Impacted products
Vendor Product Version
Linux Linux Affected: d3b18ad31f93d0b6bae105c679018a1ba7daa9ca , < 328cac3f9f8ae394748485e769a527518a9137c8 (git)
Affected: d3b18ad31f93d0b6bae105c679018a1ba7daa9ca , < 2e36a81d388ec9c3f78b6223f7eda2088cd40adb (git)
Affected: d3b18ad31f93d0b6bae105c679018a1ba7daa9ca , < 57fbbe29e86042bbaa31c1a30d2afa16c427e3f7 (git)
Affected: d3b18ad31f93d0b6bae105c679018a1ba7daa9ca , < 603943f022a7fe5cc83ca7005faf34798fb7853f (git)
Affected: d3b18ad31f93d0b6bae105c679018a1ba7daa9ca , < 54a3ecaeeeae8176da8badbd7d72af1017032c39 (git)
Create a notification for this product.
Linux Linux Affected: 4.20
Unaffected: 0 , < 4.20 (semver)
Unaffected: 6.1.142 , ≤ 6.1.* (semver)
Unaffected: 6.6.94 , ≤ 6.6.* (semver)
Unaffected: 6.12.34 , ≤ 6.12.* (semver)
Unaffected: 6.15.3 , ≤ 6.15.* (semver)
Unaffected: 6.16 , ≤ * (original_commit_for_fix)
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2025-11-03T17:34:55.864Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "net/tls/tls_sw.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "328cac3f9f8ae394748485e769a527518a9137c8",
              "status": "affected",
              "version": "d3b18ad31f93d0b6bae105c679018a1ba7daa9ca",
              "versionType": "git"
            },
            {
              "lessThan": "2e36a81d388ec9c3f78b6223f7eda2088cd40adb",
              "status": "affected",
              "version": "d3b18ad31f93d0b6bae105c679018a1ba7daa9ca",
              "versionType": "git"
            },
            {
              "lessThan": "57fbbe29e86042bbaa31c1a30d2afa16c427e3f7",
              "status": "affected",
              "version": "d3b18ad31f93d0b6bae105c679018a1ba7daa9ca",
              "versionType": "git"
            },
            {
              "lessThan": "603943f022a7fe5cc83ca7005faf34798fb7853f",
              "status": "affected",
              "version": "d3b18ad31f93d0b6bae105c679018a1ba7daa9ca",
              "versionType": "git"
            },
            {
              "lessThan": "54a3ecaeeeae8176da8badbd7d72af1017032c39",
              "status": "affected",
              "version": "d3b18ad31f93d0b6bae105c679018a1ba7daa9ca",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "net/tls/tls_sw.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.20"
            },
            {
              "lessThan": "4.20",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.142",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.94",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.34",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.15.*",
              "status": "unaffected",
              "version": "6.15.3",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.16",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.142",
                  "versionStartIncluding": "4.20",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.94",
                  "versionStartIncluding": "4.20",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.34",
                  "versionStartIncluding": "4.20",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.15.3",
                  "versionStartIncluding": "4.20",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.16",
                  "versionStartIncluding": "4.20",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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]  \u003cTASK\u003e\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-\u003esg 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-\u003emsg_iter is reset, but since\nmsg_pl-\u003esg.size has been increased, subsequent executions will exceed the\nactual size of msg_iter.\n\u0027\u0027\u0027\niov_iter_revert(\u0026msg-\u003emsg_iter, msg_pl-\u003esg.size - orig_size);\n\u0027\u0027\u0027\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 \u0027sg-\u003emsg_iter\u0027\n(but in msg_pl instead), especially the data \"?\" we pushed.\n\nSo it doesn\u0027t 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\u0027t 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\u0027\u0027\u0027\nline 1177\nelse if (ret != -EAGAIN) {\n\tif (ret == -ENOSPC)\n\t\tret = 0;\n\tgoto send_end;\n\u0027\u0027\u0027\n\nSo it\u0027s ok to just return \u0027copied\u0027 without error when a \"cork\" situation\noccurs."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The trigger is a local `sendmsg()`/`sendto()` syscall on a kTLS socket enrolled in a sockmap, and the data driving the bug is the calling process\u0027s own send buffer plus the sk_msg BPF verdict \u2014 not data received from a remote peer. This is the kTLS transmit path combined with BPF/sockmap, both of which are locally reachable only.\nAC:L - Exploitation is fully deterministic \u2014 no race, no memory-layout grooming, no timing window; the attacker simply issues a `send()` whose length falls below the program\u0027s `cork_bytes` threshold and the `BUG()` fires every time. The attacker additionally chooses ITER_UBUF vs ITER_IOVEC by controlling `nr_segs`, selecting between the guaranteed panic and the out-of-bounds iterator walk.\nPR:L - Enabling kTLS TX requires no capability whatsoever (net/tls contains no `capable()` checks), and in the standard sockmap deployment the `sk_msg` program is installed by the platform/service mesh with sockets auto-enrolled on connect, so an ordinary unprivileged local user needs only a socket and a `send()` call. Where the attacker supplies the BPF program, `bpf_token_capable()` also grants `CAP_BPF`/`CAP_NET_ADMIN` inside a user namespace via a delegated BPF token.\nUI:N - The attacker performs every step themselves \u2014 create socket, enable kTLS, call send(). No action by any other user or administrator is needed at exploitation time.\nS:U - The corruption and the crash are confined to the kernel\u0027s own memory and the attacking task\u0027s socket state; no hypervisor, IOMMU, or sandbox boundary is crossed.\nC:H - With \u22652 iovecs, `iov_iter_revert()` walks backwards off the front of `iovstack[]` in an unbounded loop, reading kernel-stack qwords as `iov_len` and leaving `i-\u003e__iov` pointing at out-of-bounds kernel memory adjacent to the attacker-seeded `sockaddr_storage`; `i-\u003ecount` is simultaneously inflated past the end of the user buffer, and the corrupted iterator is then used for further copies. This unbounded OOB kernel read plus live-iterator corruption is a disclosure primitive.\nI:H - The faulty revert writes an out-of-bounds pointer, inflated `nr_segs`, and an `iov_offset` derived from out-of-bounds kernel memory into a live kernel iterator whose neighbouring stack contents the attacker controls via `msg_name`, and the `sg.size`/`sk_mem_charge` accounting diverges from reality. Memory-safety corruption of this nature is scored High.\nA:H - The common single-buffer case hits a guaranteed `BUG()` at lib/iov_iter.c:629 while holding both `tls_ctx-\u003etx_lock` and the socket lock, so the killed task self-deadlocks in `tls_sk_proto_close()` during exit \u2014 an unkillable D-state task with a permanently wedged socket and leaked memory. On systems with `panic_on_oops` it is an immediate full system panic, and it is trivially repeatable."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T11:59:59.787Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/328cac3f9f8ae394748485e769a527518a9137c8"
        },
        {
          "url": "https://git.kernel.org/stable/c/2e36a81d388ec9c3f78b6223f7eda2088cd40adb"
        },
        {
          "url": "https://git.kernel.org/stable/c/57fbbe29e86042bbaa31c1a30d2afa16c427e3f7"
        },
        {
          "url": "https://git.kernel.org/stable/c/603943f022a7fe5cc83ca7005faf34798fb7853f"
        },
        {
          "url": "https://git.kernel.org/stable/c/54a3ecaeeeae8176da8badbd7d72af1017032c39"
        }
      ],
      "title": "bpf: fix ktls panic with sockmap",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-38166",
    "datePublished": "2025-07-03T08:36:06.372Z",
    "dateReserved": "2025-04-16T04:51:23.991Z",
    "dateUpdated": "2026-08-05T11:59:59.787Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2025-38166",
      "date": "2026-08-05",
      "epss": "0.00157",
      "percentile": "0.05333"
    },
    "microsoft_vex": {
      "current_release_date": "2026-03-31T14:56:16.000Z",
      "cve": "CVE-2025-38166",
      "id": "msrc_CVE-2025-38166",
      "initial_release_date": "2025-07-02T00:00:00.000Z",
      "product_status:fixed": "2",
      "product_status:known_affected": "5",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "bpf: fix ktls panic with sockmap",
      "url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2025-38166.json",
      "version": "5"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-38166\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-07-03T09:15:32.120\",\"lastModified\":\"2026-07-30T06:22:56.437\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"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]  \u003cTASK\u003e\\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-\u003esg 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-\u003emsg_iter is reset, but since\\nmsg_pl-\u003esg.size has been increased, subsequent executions will exceed the\\nactual size of msg_iter.\\n\u0027\u0027\u0027\\niov_iter_revert(\u0026msg-\u003emsg_iter, msg_pl-\u003esg.size - orig_size);\\n\u0027\u0027\u0027\\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 \u0027sg-\u003emsg_iter\u0027\\n(but in msg_pl instead), especially the data \\\"?\\\" we pushed.\\n\\nSo it doesn\u0027t 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\u0027t 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\u0027\u0027\u0027\\nline 1177\\nelse if (ret != -EAGAIN) {\\n\\tif (ret == -ENOSPC)\\n\\t\\tret = 0;\\n\\tgoto send_end;\\n\u0027\u0027\u0027\\n\\nSo it\u0027s ok to just return \u0027copied\u0027 without error when a \\\"cork\\\" situation\\noccurs.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corregir p\u00e1nico ktls con sockmap [ 2172.936997] ------------[ cortar aqu\u00ed ]------------ [ 2172.936999] ERROR del kernel en lib/iov_iter.c:629! ...... [ 2172.944996] PKRU: 55555554 [ 2172.945155] Rastreo de llamadas: [ 2172.945299]  [ 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 ...... Despu\u00e9s de llamar a bpf_exec_tx_verdict(), el tama\u00f1o de msg_pl-\u0026gt;sg puede aumentar, por ejemplo, cuando el programa BPF ejecuta bpf_msg_push_data(). Si el programa BPF define cork_bytes y sg.size es menor que cork_bytes, devolver\u00e1 -ENOSPC e intentar\u00e1 revertir a la l\u00f3gica de copia no nula. Sin embargo, durante la reversi\u00f3n, msg-\u0026gt;msg_iter se restablece, pero como se ha aumentado msg_pl-\u0026gt;sg.size, las ejecuciones posteriores superar\u00e1n el tama\u00f1o real de msg_iter. \u0027\u0027\u0027 iov_iter_revert(\u0026amp;msg-\u0026gt;msg_iter, msg_pl-\u0026gt;sg.size - orig_size); \u0027\u0027\u0027 Los cambios en esta confirmaci\u00f3n se basan en las siguientes consideraciones: 1. Cuando se establece cork_bytes, revertir a la l\u00f3gica de copia no nula no tiene sentido y se puede pasar directamente a la l\u00f3gica de copia cero. 2. No podemos calcular el n\u00famero correcto de bytes para revertir msg_iter. Supongamos que los datos originales son \\\"abcdefgh\\\" (8 bytes) y, tras 3 intentos del programa BPF, se convierten en datos de 11 bytes: \\\"abc?de?fgh?\\\". Luego, configuramos cork_bytes en 6, lo que significa que los primeros 6 bytes se han procesado y los 5 bytes restantes de \\\"?fgh?\\\" se almacenar\u00e1n en cach\u00e9 hasta que la longitud cumpla con el requisito de cork_bytes. Sin embargo, algunos datos en \\\"?fgh?\\\" no est\u00e1n dentro de \u0027sg-\u0026gt;msg_iter\u0027 (sino en msg_pl), especialmente los datos \\\"?\\\" que enviamos. Por lo tanto, no parece tan sencillo como revertir a trav\u00e9s de un desplazamiento de msg_iter. 3. Para sockets sin TLS en tcp_bpf_sendmsg, cuando se produce una situaci\u00f3n de \\\"cork\\\", la funci\u00f3n send() en el espacio de usuario no devuelve un error y la longitud devuelta es la misma que el par\u00e1metro de longitud de entrada, incluso si algunos datos est\u00e1n almacenados en cach\u00e9. Adem\u00e1s, observ\u00e9 que la l\u00f3gica actual de copia distinta de cero para gestionar el cork se escribe as\u00ed: \u0027\u0027\u0027 l\u00ednea 1177 else if (ret != -EAGAIN) { if (ret == -ENOSPC) ret = 0; goto send_end; \u0027\u0027\u0027 Por lo tanto, est\u00e1 bien simplemente devolver \u0027copiado\u0027 sin error cuando ocurre una situaci\u00f3n de \\\"corcho\\\".\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"net/tls/tls_sw.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"d3b18ad31f93d0b6bae105c679018a1ba7daa9ca\",\"lessThan\":\"328cac3f9f8ae394748485e769a527518a9137c8\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"d3b18ad31f93d0b6bae105c679018a1ba7daa9ca\",\"lessThan\":\"2e36a81d388ec9c3f78b6223f7eda2088cd40adb\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"d3b18ad31f93d0b6bae105c679018a1ba7daa9ca\",\"lessThan\":\"57fbbe29e86042bbaa31c1a30d2afa16c427e3f7\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"d3b18ad31f93d0b6bae105c679018a1ba7daa9ca\",\"lessThan\":\"603943f022a7fe5cc83ca7005faf34798fb7853f\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"d3b18ad31f93d0b6bae105c679018a1ba7daa9ca\",\"lessThan\":\"54a3ecaeeeae8176da8badbd7d72af1017032c39\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"net/tls/tls_sw.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"4.20\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"4.20\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.1.142\",\"lessThanOrEqual\":\"6.1.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.6.94\",\"lessThanOrEqual\":\"6.6.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.12.34\",\"lessThanOrEqual\":\"6.12.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.15.3\",\"lessThanOrEqual\":\"6.15.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.16\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\",\"baseScore\":7.8,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":5.9},{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"NVD-CWE-noinfo\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"4.20\",\"versionEndExcluding\":\"6.1.142\",\"matchCriteriaId\":\"99E6724B-C244-433B-ABF6-9D1CDB08578E\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.2\",\"versionEndExcluding\":\"6.6.94\",\"matchCriteriaId\":\"304E3F01-7D7A-4908-994E-7F95C5C00B06\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.7\",\"versionEndExcluding\":\"6.12.34\",\"matchCriteriaId\":\"4FFA54AA-CDFE-4591-BD07-72813D0948F4\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.13\",\"versionEndExcluding\":\"6.15.3\",\"matchCriteriaId\":\"0541C761-BD5E-4C1A-8432-83B375D7EB92\"}]}]},{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:*\",\"matchCriteriaId\":\"FA6FEEC2-9F11-4643-8827-749718254FED\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/2e36a81d388ec9c3f78b6223f7eda2088cd40adb\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/328cac3f9f8ae394748485e769a527518a9137c8\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/54a3ecaeeeae8176da8badbd7d72af1017032c39\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/57fbbe29e86042bbaa31c1a30d2afa16c427e3f7\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/603943f022a7fe5cc83ca7005faf34798fb7853f\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Third Party Advisory\"]}]}}",
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-07-30T09:14:25+00:00",
      "cve": "CVE-2025-38166",
      "id": "CVE-2025-38166",
      "initial_release_date": "2025-07-03T00:00:00+00:00",
      "product_status:fixed": "612",
      "product_status:known_affected": "70",
      "product_status:known_not_affected": "42",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: bpf: fix ktls panic with sockmap",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-38166.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-07-17T13:11:17Z",
      "cve": "CVE-2025-38166",
      "id": "CVE-2025-38166",
      "initial_release_date": "2025-07-04T14:37:56Z",
      "product_status:known_affected": "639",
      "product_status:known_not_affected": "52",
      "product_status:recommended": "430",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2025-38166",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2025-38166.json",
      "version": "27"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.