FKIE_CVE-2026-43244

Vulnerability from fkie_nvd - Published: 2026-05-06 12:16 - Updated: 2026-05-11 14:12
Summary
In the Linux kernel, the following vulnerability has been resolved: kcm: fix zero-frag skb in frag_list on partial sendmsg error Syzkaller reported a warning in kcm_write_msgs() when processing a message with a zero-fragment skb in the frag_list. When kcm_sendmsg() fills MAX_SKB_FRAGS fragments in the current skb, it allocates a new skb (tskb) and links it into the frag_list before copying data. If the copy subsequently fails (e.g. -EFAULT from user memory), tskb remains in the frag_list with zero fragments: head skb (msg being assembled, NOT yet in sk_write_queue) +-----------+ | frags[17] | (MAX_SKB_FRAGS, all filled with data) | frag_list-+--> tskb +-----------+ +----------+ | frags[0] | (empty! copy failed before filling) +----------+ For SOCK_SEQPACKET with partial data already copied, the error path saves this message via partial_message for later completion. For SOCK_SEQPACKET, sock_write_iter() automatically sets MSG_EOR, so a subsequent zero-length write(fd, NULL, 0) completes the message and queues it to sk_write_queue. kcm_write_msgs() then walks the frag_list and hits: WARN_ON(!skb_shinfo(skb)->nr_frags) TCP has a similar pattern where skbs are enqueued before data copy and cleaned up on failure via tcp_remove_empty_skb(). KCM was missing the equivalent cleanup. Fix this by tracking the predecessor skb (frag_prev) when allocating a new frag_list entry. On error, if the tail skb has zero frags, use frag_prev to unlink and free it in O(1) without walking the singly-linked frag_list. frag_prev is safe to dereference because the entire message chain is only held locally (or in kcm->seq_skb) and is not added to sk_write_queue until MSG_EOR, so the send path cannot free it underneath us. Also change the WARN_ON to WARN_ON_ONCE to avoid flooding the log if the condition is somehow hit repeatedly. There are currently no KCM selftests in the kernel tree; a simple reproducer is available at [1]. [1] https://gist.github.com/mrpre/a94d431c757e8d6f168f4dd1a3749daa
Impacted products

{
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "BF0012BC-1AAF-4F0D-B9C8-FC13D91F000E",
              "versionEndExcluding": "6.12.75",
              "versionStartIncluding": "4.6",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "B4B8CDA9-BADF-4CF5-8B3B-702DE8EEA40B",
              "versionEndExcluding": "6.18.16",
              "versionStartIncluding": "6.13",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "373EEEDA-FAA1-4FB4-B6ED-DB4DD99DBE67",
              "versionEndExcluding": "6.19.6",
              "versionStartIncluding": "6.19",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*",
              "matchCriteriaId": "F253B622-8837-4245-BCE5-A7BF8FC76A16",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nkcm: fix zero-frag skb in frag_list on partial sendmsg error\n\nSyzkaller reported a warning in kcm_write_msgs() when processing a\nmessage with a zero-fragment skb in the frag_list.\n\nWhen kcm_sendmsg() fills MAX_SKB_FRAGS fragments in the current skb,\nit allocates a new skb (tskb) and links it into the frag_list before\ncopying data. If the copy subsequently fails (e.g. -EFAULT from\nuser memory), tskb remains in the frag_list with zero fragments:\n\n  head skb (msg being assembled, NOT yet in sk_write_queue)\n  +-----------+\n  | frags[17] |  (MAX_SKB_FRAGS, all filled with data)\n  | frag_list-+--\u003e tskb\n  +-----------+    +----------+\n                   | frags[0] |  (empty! copy failed before filling)\n                   +----------+\n\nFor SOCK_SEQPACKET with partial data already copied, the error path\nsaves this message via partial_message for later completion. For\nSOCK_SEQPACKET, sock_write_iter() automatically sets MSG_EOR, so a\nsubsequent zero-length write(fd, NULL, 0) completes the message and\nqueues it to sk_write_queue. kcm_write_msgs() then walks the\nfrag_list and hits:\n\n  WARN_ON(!skb_shinfo(skb)-\u003enr_frags)\n\nTCP has a similar pattern where skbs are enqueued before data copy\nand cleaned up on failure via tcp_remove_empty_skb(). KCM was\nmissing the equivalent cleanup.\n\nFix this by tracking the predecessor skb (frag_prev) when allocating\na new frag_list entry. On error, if the tail skb has zero frags,\nuse frag_prev to unlink and free it in O(1) without walking the\nsingly-linked frag_list. frag_prev is safe to dereference because\nthe entire message chain is only held locally (or in kcm-\u003eseq_skb)\nand is not added to sk_write_queue until MSG_EOR, so the send path\ncannot free it underneath us.\n\nAlso change the WARN_ON to WARN_ON_ONCE to avoid flooding the log\nif the condition is somehow hit repeatedly.\n\nThere are currently no KCM selftests in the kernel tree; a simple\nreproducer is available at [1].\n\n[1] https://gist.github.com/mrpre/a94d431c757e8d6f168f4dd1a3749daa"
    }
  ],
  "id": "CVE-2026-43244",
  "lastModified": "2026-05-11T14:12:18.633",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 5.5,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 3.6,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ]
  },
  "published": "2026-05-06T12:16:44.873",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/7af58f76e4b404a74c836881a845e6652db8a09f"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/9ea3671d70ee07480d80bebe86696397c4e99fb7"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/b1e3edf688a88c1a3ac41657055d9c136a08cd25"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/ca220141fa8ebae09765a242076b2b77338106b0"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-401"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…
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.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…