Blue Goat CyberBlue Goat CyberSMMedical Device Cybersecurity
    K
    Goat Feed · KEV

    CISA KEV: Linux Kernel CVE-2026-53362 (CVSS 3.1 7.8 HIGH) - Kernel Unspecified Vulnerability

    In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 ("ipv6: avoid partial copy for zc"). Before commit ce650a166335 ("udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.

    Back to the daily feed
    KEV
    critical

    BGC Risk Score

    Blue Goat Cyber MedTech rubric v1.0 · methodology

    6.9
    of 10
    notable
    CVSS technical
    40% · +3.1

    3.1 base 7.8 · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

    Patient safety
    35% · +1.8

    Delay of care

    Exploit maturity
    15% · +1.5

    On CISA KEV (in-the-wild)

    MedTech exposure
    10% · +0.5

    5/10 network-reachable signals

    How we got to 6.9

    1. 1
      CVSS technical severity (40%)

      Industry-standard exploitability + impact score. We prefer CVSS 4.0 and fall back to 3.1 per the FDA's Feb 2026 premarket cybersecurity guidance. Missing CVSS scores get a neutral 4.0 so unknown vulns are not over- or under-rated.

      3.1 base 7.8 × 40% = +3.12
    2. 2
      Patient safety impact (35%)

      What happens to a patient if this vuln is exploited on a connected device. Auto-inferred from headline, dek, tags, and device class against a curated MedTech keyword library (pacemaker, infusion pump, EHR, PACS, etc.).

      Delay of care → 5 × 35% = +1.75
    3. 3
      Exploit maturity (15%)

      Is anyone actually using this in attacks? KEV listing > weaponized exploit > public PoC > none. KEV alone forces tier=critical regardless of CVSS.

      On CISA KEV (in-the-wild) → 10 × 15% = +1.50
    4. 4
      MedTech exposure (10%)

      How likely this affects clinical operations: presence in our MedTech feed (+4 baseline), network-reachable signals (+3), known device-class tags (+2), identified MedTech vendor (+1).

      Exposure 5/10 × 10% = +0.50

    Tier cutoffs: Critical ≥ 8.5 · High 7.0–8.4 · Notable 4.0–6.9 · Info < 4.0. Full methodology, weights, and changelog at /goatfeed/risk-rubric.

    CVE: CVE-2026-53362

    CVSS 3.1: 7.8 (HIGH) - `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`

    Weakness: CWE-787

    Vendor / product: Linux Kernel

    KEV added: 2026-08-27 · Federal due date: 2026-08-30

    BGC-RS: 6.9 (notable) · CVSS 3.1 base 7.8 · patient-safety: delay-of-care · exploit: kev · MedTech exposure 5/10 · methodology

    Vulnerability

    In the Linux kernel, the following vulnerability has been resolved:

    ipv6: account for fraggap on the paged allocation path

    In __ip6_append_data(), when the paged-allocation branch is taken

    (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are

    computed as

    alloclen = fragheaderlen + transhdrlen;

    pagedlen = datalen - transhdrlen;

    datalen already includes fraggap (datalen = length + fraggap). When

    fraggap is non-zero, this is not the first skb and transhdrlen is zero.

    The fraggap bytes carried over from the previous skb are copied just past

    the fragment headers in the new skb's linear area. The linear area is

    therefore undersized by fraggap bytes while pagedlen is overstated by the

    same amount, and the copy writes past skb->end into the trailing

    skb_shared_info.

    An unprivileged user can trigger this via a UDPv6 socket using

    MSG_MORE together with MSG_SPLICE_PAGES.

    The bad accounting was introduced by commit 773ba4fe9104 ("ipv6:

    avoid partial copy for zc"). Before commit ce650a166335 ("udp6: Fix

    __ip6_append_data()'s handling of MSG_SPLICE_PAGES"), the negative

    copy value caused -EINVAL to be returned. That later commit allowed

    MSG_SPLICE_PAGES to proceed in this case, making the corruption

    triggerable.

    The non-paged branch sets alloclen to fraglen, which already accounts

    for fraggap because datalen does. Bring the paged branch in line by

    adding fraggap to alloclen and subtracting it from pagedlen.

    After this adjustment, copy no longer collapses to -fraggap on the

    paged path, so remove the stale comment describing that old arithmetic.

    Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES

    case, remove the MSG_SPLICE_PAGES exception from the negative copy check.

    Required action

    Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.

    Citations
    #kev#cve#linux
    Need help acting on this?

    Talk to Blue Goat Cyber

    Penetration testing, SBOM, threat modeling, and 524B submission support for MedTech.