Vulnerability-Lookup

CVE-2026-72157 (GCVE-0-2026-72157)

Vulnerability from cvelistv5 – Published: 2026-08-15 05:53 – Updated: 2026-08-23 12:46

Title

net: thunderbolt: Fix frags[] overflow by bounding frame_count

Summary

In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Fix frags[] overflow by bounding frame_count tbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The first frame goes into the skb linear area and every further frame is added as a page fragment. skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, page, hdr_size, frame_size, TBNET_RX_PAGE_SIZE - hdr_size); A packet of frame_count frames therefore ends up with frame_count - 1 fragments. tbnet_check_frame() only bounds the peer supplied frame_count to TBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A peer that sends a packet of 19 or more small frames pushes nr_frags past MAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()->frags[] and corrupts memory after the shared info. Tighten the start of packet bound to MAX_SKB_FRAGS + 1 so a packet can never produce more fragments than frags[] can hold. This matches the recent skb frags overflow fixes in other receive paths, for example f0813bcd2d9d ("net: wwan: t7xx: fix potential skb->frags overflow in RX path") and 600dc40554dc ("net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()").

Severity

8.8 (High)


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

Assigner

Linux mitre root

References

8 references

URL	Tags
https://git.kernel.org/stable/c/f96b3b35c622d565e…
https://git.kernel.org/stable/c/6262f51e09d8dc8b0…
https://git.kernel.org/stable/c/569ba39b2d12995a2…
https://git.kernel.org/stable/c/2b3b4e5ff5a58ad32…
https://git.kernel.org/stable/c/e27beb4536cbf1d59…
https://git.kernel.org/stable/c/e5824d5b841d99a2b…
https://git.kernel.org/stable/c/fe6b606fbf0c3beb9…
https://git.kernel.org/stable/c/55d9895f89970501f…

Impacted products

2 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e , < f96b3b35c622d565eff2438993e028d280163f5c (git) Affected: e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e , < 6262f51e09d8dc8b07599a9e4f03bd3989d13fff (git) Affected: e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e , < 569ba39b2d12995a29dc158e5b4de6e449278f30 (git) Affected: e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e , < 2b3b4e5ff5a58ad32817824b0310e63908b12052 (git) Affected: e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e , < e27beb4536cbf1d59e2d8c2840e87d972aba906f (git) Affected: e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e , < e5824d5b841d99a2bcdd4e2c256643293bbc22c1 (git) Affected: e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e , < fe6b606fbf0c3beb94ccf17fcf31d8c2138264e3 (git) Affected: e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e , < 55d9895f89970501fe126d1026b586b04a224c27 (git)	guessed
Linux	Linux	Affected: 4.15 Unaffected: 0 , < 4.15 (semver) Unaffected: 5.10.266 , ≤ 5.10.* (semver) Unaffected: 5.15.217 , ≤ 5.15.* (semver) Unaffected: 6.1.184 , ≤ 6.1.* (semver) Unaffected: 6.6.145 , ≤ 6.6.* (semver) Unaffected: 6.12.97 , ≤ 6.12.* (semver) Unaffected: 6.18.40 , ≤ 6.18.* (semver) Unaffected: 7.1.5 , ≤ 7.1.* (semver) Unaffected: 7.2 , ≤ * (original_commit_for_fix)	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/thunderbolt/main.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "f96b3b35c622d565eff2438993e028d280163f5c",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "6262f51e09d8dc8b07599a9e4f03bd3989d13fff",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "569ba39b2d12995a29dc158e5b4de6e449278f30",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "2b3b4e5ff5a58ad32817824b0310e63908b12052",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "e27beb4536cbf1d59e2d8c2840e87d972aba906f",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "e5824d5b841d99a2bcdd4e2c256643293bbc22c1",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "fe6b606fbf0c3beb94ccf17fcf31d8c2138264e3",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "55d9895f89970501fe126d1026b586b04a224c27",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/thunderbolt/main.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.15"
            },
            {
              "lessThan": "4.15",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.266",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.217",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.184",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.145",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.97",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.40",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.1.*",
              "status": "unaffected",
              "version": "7.1.5",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.266",
                  "versionStartIncluding": "4.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.217",
                  "versionStartIncluding": "4.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.184",
                  "versionStartIncluding": "4.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.145",
                  "versionStartIncluding": "4.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.97",
                  "versionStartIncluding": "4.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.40",
                  "versionStartIncluding": "4.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.1.5",
                  "versionStartIncluding": "4.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2",
                  "versionStartIncluding": "4.15",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: thunderbolt: Fix frags[] overflow by bounding frame_count\n\ntbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The\nfirst frame goes into the skb linear area and every further frame is added as\na page fragment.\n\n\tskb_add_rx_frag(skb, skb_shinfo(skb)-\u003enr_frags,\n\t\t\tpage, hdr_size, frame_size,\n\t\t\tTBNET_RX_PAGE_SIZE - hdr_size);\n\nA packet of frame_count frames therefore ends up with frame_count - 1\nfragments. tbnet_check_frame() only bounds the peer supplied frame_count to\nTBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A\npeer that sends a packet of 19 or more small frames pushes nr_frags past\nMAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()-\u003efrags[] and\ncorrupts memory after the shared info.\n\nTighten the start of packet bound to MAX_SKB_FRAGS + 1 so a packet can never\nproduce more fragments than frags[] can hold. This matches the recent skb\nfrags overflow fixes in other receive paths, for example f0813bcd2d9d (\"net:\nwwan: t7xx: fix potential skb-\u003efrags overflow in RX path\") and 600dc40554dc\n(\"net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()\")."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 8.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:A - The flaw is triggered by malicious ThunderboltIP frames sent from a peer on the same direct Thunderbolt/USB4 link; exploitation is not Internet-routable but is reachable from an adjacent connected host, dock, or peripheral without local syscall access.\nAC:L - An adjacent peer can reliably trigger the overflow by sending a start-of-packet header with frame_count of 19-64 and delivering the matching small frames; no races or attacker-uncontrollable heap layout are required.\nPR:N - The attacker needs no account, capability, or privilege on the victim OS; a malicious Thunderbolt/USB4 peer that completes XDomain ThunderboltIP login can send the crafted RX frames directly over the established DMA path.\nUI:N - Once a ThunderboltIP session is active, which is common with docks, direct laptop-to-laptop links, and shared workstations, triggering the bug requires no further victim action beyond the existing link.\nS:U - Memory corruption occurs in the kernel Thunderbolt network driver during skb reassembly and does not by itself cross a VM, container, or IOMMU security boundary.\nC:H - skb_add_rx_frag() writes past skb_shinfo()-\u003efrags[], corrupting adjacent kernel memory; such out-of-bounds skb metadata corruption is reasonably leverageable for information disclosure as well as further exploitation.\nI:H - The overflow is an attacker-controlled out-of-bounds write of skb fragment descriptors beyond MAX_SKB_FRAGS, which can corrupt heap/skb metadata and be developed into arbitrary kernel memory modification or code execution.\nA:H - Corrupting memory past skb_shared_info can cause kernel oopses, panics, or unstable behavior during RX processing, and repeated malicious packets can deny service on affected systems."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-23T12:46:55.998Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/f96b3b35c622d565eff2438993e028d280163f5c"
        },
        {
          "url": "https://git.kernel.org/stable/c/6262f51e09d8dc8b07599a9e4f03bd3989d13fff"
        },
        {
          "url": "https://git.kernel.org/stable/c/569ba39b2d12995a29dc158e5b4de6e449278f30"
        },
        {
          "url": "https://git.kernel.org/stable/c/2b3b4e5ff5a58ad32817824b0310e63908b12052"
        },
        {
          "url": "https://git.kernel.org/stable/c/e27beb4536cbf1d59e2d8c2840e87d972aba906f"
        },
        {
          "url": "https://git.kernel.org/stable/c/e5824d5b841d99a2bcdd4e2c256643293bbc22c1"
        },
        {
          "url": "https://git.kernel.org/stable/c/fe6b606fbf0c3beb94ccf17fcf31d8c2138264e3"
        },
        {
          "url": "https://git.kernel.org/stable/c/55d9895f89970501fe126d1026b586b04a224c27"
        }
      ],
      "title": "net: thunderbolt: Fix frags[] overflow by bounding frame_count",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-72157",
    "datePublished": "2026-08-15T05:53:26.718Z",
    "dateReserved": "2026-08-09T03:40:39.909Z",
    "dateUpdated": "2026-08-23T12:46:55.998Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-72157",
      "date": "2026-09-21",
      "epss": "0.00345",
      "percentile": "0.27998"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "drivers/net/thunderbolt/main.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "f96b3b35c622d565eff2438993e028d280163f5c",
                    "status": "affected",
                    "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "6262f51e09d8dc8b07599a9e4f03bd3989d13fff",
                    "status": "affected",
                    "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "569ba39b2d12995a29dc158e5b4de6e449278f30",
                    "status": "affected",
                    "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "2b3b4e5ff5a58ad32817824b0310e63908b12052",
                    "status": "affected",
                    "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "e27beb4536cbf1d59e2d8c2840e87d972aba906f",
                    "status": "affected",
                    "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "e5824d5b841d99a2bcdd4e2c256643293bbc22c1",
                    "status": "affected",
                    "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "fe6b606fbf0c3beb94ccf17fcf31d8c2138264e3",
                    "status": "affected",
                    "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "55d9895f89970501fe126d1026b586b04a224c27",
                    "status": "affected",
                    "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "drivers/net/thunderbolt/main.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "4.15"
                  },
                  {
                    "lessThan": "4.15",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.10.*",
                    "status": "unaffected",
                    "version": "5.10.266",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.15.*",
                    "status": "unaffected",
                    "version": "5.15.217",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.1.*",
                    "status": "unaffected",
                    "version": "6.1.184",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.6.*",
                    "status": "unaffected",
                    "version": "6.6.145",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.12.*",
                    "status": "unaffected",
                    "version": "6.12.97",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.18.*",
                    "status": "unaffected",
                    "version": "6.18.40",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "7.1.*",
                    "status": "unaffected",
                    "version": "7.1.5",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "7.2",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: thunderbolt: Fix frags[] overflow by bounding frame_count\n\ntbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The\nfirst frame goes into the skb linear area and every further frame is added as\na page fragment.\n\n\tskb_add_rx_frag(skb, skb_shinfo(skb)-\u003enr_frags,\n\t\t\tpage, hdr_size, frame_size,\n\t\t\tTBNET_RX_PAGE_SIZE - hdr_size);\n\nA packet of frame_count frames therefore ends up with frame_count - 1\nfragments. tbnet_check_frame() only bounds the peer supplied frame_count to\nTBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A\npeer that sends a packet of 19 or more small frames pushes nr_frags past\nMAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()-\u003efrags[] and\ncorrupts memory after the shared info.\n\nTighten the start of packet bound to MAX_SKB_FRAGS + 1 so a packet can never\nproduce more fragments than frags[] can hold. This matches the recent skb\nfrags overflow fixes in other receive paths, for example f0813bcd2d9d (\"net:\nwwan: t7xx: fix potential skb-\u003efrags overflow in RX path\") and 600dc40554dc\n(\"net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()\")."
          }
        ],
        "id": "CVE-2026-72157",
        "lastModified": "2026-08-23T13:16:40.970",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "ADJACENT_NETWORK",
                "availabilityImpact": "HIGH",
                "baseScore": 8.8,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "NONE",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 2.8,
              "impactScore": 5.9,
              "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
              "type": "Secondary"
            }
          ]
        },
        "published": "2026-08-15T06:21:33.497",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/2b3b4e5ff5a58ad32817824b0310e63908b12052"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/55d9895f89970501fe126d1026b586b04a224c27"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/569ba39b2d12995a29dc158e5b4de6e449278f30"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/6262f51e09d8dc8b07599a9e4f03bd3989d13fff"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/e27beb4536cbf1d59e2d8c2840e87d972aba906f"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/e5824d5b841d99a2bcdd4e2c256643293bbc22c1"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/f96b3b35c622d565eff2438993e028d280163f5c"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/fe6b606fbf0c3beb94ccf17fcf31d8c2138264e3"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Received"
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-08-18T14:32:24+00:00",
      "cve": "CVE-2026-72157",
      "id": "CVE-2026-72157",
      "initial_release_date": "2026-08-15T00:00:00+00:00",
      "product_status:known_affected": "232",
      "product_status:known_not_affected": "42",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: net: thunderbolt: Fix frags[] overflow by bounding frame_count",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-72157.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "important",
      "current_release_date": "2026-08-31T13:29:53Z",
      "cve": "CVE-2026-72157",
      "id": "CVE-2026-72157",
      "initial_release_date": "2026-08-31T13:29:53Z",
      "product_status:known_affected": "261",
      "product_status:known_not_affected": "101",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2026-72157",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2026-72157.json",
      "version": "2"
    }
  }
}

BELL-CVE-2026-72157 (CVE-2026-72157)

Vulnerability from osv_bellsoft – Published: 2026-08-18 06:06 – Updated: 2026-08-18 06:25 – Source website

Severity

8.8 (High)


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

References

URL

Type

https://docs.bell-sw.com/security/cves/CVE-2026-72157

ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Alpaquita:23",
        "name": "linux-lts",
        "purl": "pkg:apk/alpaquita/linux-lts?arch=source\u0026distro=23"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.1.182-r0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Alpaquita:25",
        "name": "linux-lts",
        "purl": "pkg:apk/alpaquita/linux-lts?arch=source\u0026distro=25"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.12.95-r0"
            },
            {
              "fixed": "6.12.103-r0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Alpaquita:stream",
        "name": "linux-lts",
        "purl": "pkg:apk/alpaquita/linux-lts?arch=source\u0026distro=stream"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.18.38-r0"
            },
            {
              "fixed": "6.18.43-r0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "id": "BELL-CVE-2026-72157",
  "modified": "2026-08-18T06:25:11.782373Z",
  "published": "2026-08-18T06:06:21.230278Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://docs.bell-sw.com/security/cves/CVE-2026-72157"
    }
  ],
  "schema_version": "1.7.4",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-72157"
  ]
}

CERTFR-2026-AVI-1163

Vulnerability from certfr_avis - Published: 2026-09-11 - Updated: 2026-09-11

De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Certaines d'entre elles permettent à un attaquant de provoquer une élévation de privilèges, une atteinte à la confidentialité des données et un déni de service.

Solutions

Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).

Impacted products

	Vendor	Product	Description
	Debian	Debian	Debian LTS 12 bookworm versions antérieures à 6.1.187-1

References

Title

Publication Time

FKIE_CVE-2026-72157

Vulnerability from fkie_nvd - Published: 2026-08-15 06:21 - Updated: 2026-08-23 13:16

Severity

8.8 (High) - CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Summary

References

	URL	Tags
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/2b3b4e5ff5a58ad32817824b0310e63908b12052
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/55d9895f89970501fe126d1026b586b04a224c27
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/569ba39b2d12995a29dc158e5b4de6e449278f30
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/6262f51e09d8dc8b07599a9e4f03bd3989d13fff
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/e27beb4536cbf1d59e2d8c2840e87d972aba906f
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/e5824d5b841d99a2bcdd4e2c256643293bbc22c1
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/f96b3b35c622d565eff2438993e028d280163f5c
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/fe6b606fbf0c3beb94ccf17fcf31d8c2138264e3

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/thunderbolt/main.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "f96b3b35c622d565eff2438993e028d280163f5c",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "6262f51e09d8dc8b07599a9e4f03bd3989d13fff",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "569ba39b2d12995a29dc158e5b4de6e449278f30",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "2b3b4e5ff5a58ad32817824b0310e63908b12052",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "e27beb4536cbf1d59e2d8c2840e87d972aba906f",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "e5824d5b841d99a2bcdd4e2c256643293bbc22c1",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "fe6b606fbf0c3beb94ccf17fcf31d8c2138264e3",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "55d9895f89970501fe126d1026b586b04a224c27",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/thunderbolt/main.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.15"
            },
            {
              "lessThan": "4.15",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.266",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.217",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.184",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.145",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.97",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.40",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.1.*",
              "status": "unaffected",
              "version": "7.1.5",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: thunderbolt: Fix frags[] overflow by bounding frame_count\n\ntbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The\nfirst frame goes into the skb linear area and every further frame is added as\na page fragment.\n\n\tskb_add_rx_frag(skb, skb_shinfo(skb)-\u003enr_frags,\n\t\t\tpage, hdr_size, frame_size,\n\t\t\tTBNET_RX_PAGE_SIZE - hdr_size);\n\nA packet of frame_count frames therefore ends up with frame_count - 1\nfragments. tbnet_check_frame() only bounds the peer supplied frame_count to\nTBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A\npeer that sends a packet of 19 or more small frames pushes nr_frags past\nMAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()-\u003efrags[] and\ncorrupts memory after the shared info.\n\nTighten the start of packet bound to MAX_SKB_FRAGS + 1 so a packet can never\nproduce more fragments than frags[] can hold. This matches the recent skb\nfrags overflow fixes in other receive paths, for example f0813bcd2d9d (\"net:\nwwan: t7xx: fix potential skb-\u003efrags overflow in RX path\") and 600dc40554dc\n(\"net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()\")."
    }
  ],
  "id": "CVE-2026-72157",
  "lastModified": "2026-08-23T13:16:40.970",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "ADJACENT_NETWORK",
          "availabilityImpact": "HIGH",
          "baseScore": 8.8,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 5.9,
        "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-08-15T06:21:33.497",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/2b3b4e5ff5a58ad32817824b0310e63908b12052"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/55d9895f89970501fe126d1026b586b04a224c27"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/569ba39b2d12995a29dc158e5b4de6e449278f30"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/6262f51e09d8dc8b07599a9e4f03bd3989d13fff"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/e27beb4536cbf1d59e2d8c2840e87d972aba906f"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/e5824d5b841d99a2bcdd4e2c256643293bbc22c1"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/f96b3b35c622d565eff2438993e028d280163f5c"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/fe6b606fbf0c3beb94ccf17fcf31d8c2138264e3"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Received"
}

GHSA-8F5R-C72F-67G5

Vulnerability from github – Published: 2026-08-15 06:32 – Updated: 2026-08-23 15:33

Details

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

net: thunderbolt: Fix frags[] overflow by bounding frame_count

tbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The first frame goes into the skb linear area and every further frame is added as a page fragment.

skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
        page, hdr_size, frame_size,
        TBNET_RX_PAGE_SIZE - hdr_size);

A packet of frame_count frames therefore ends up with frame_count - 1 fragments. tbnet_check_frame() only bounds the peer supplied frame_count to TBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A peer that sends a packet of 19 or more small frames pushes nr_frags past MAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()->frags[] and corrupts memory after the shared info.

Tighten the start of packet bound to MAX_SKB_FRAGS + 1 so a packet can never produce more fragments than frags[] can hold. This matches the recent skb frags overflow fixes in other receive paths, for example f0813bcd2d9d ("net: wwan: t7xx: fix potential skb->frags overflow in RX path") and 600dc40554dc ("net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()").

Severity

8.8 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-72157"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-15T06:21:33Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: thunderbolt: Fix frags[] overflow by bounding frame_count\n\ntbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The\nfirst frame goes into the skb linear area and every further frame is added as\na page fragment.\n\n\tskb_add_rx_frag(skb, skb_shinfo(skb)-\u003enr_frags,\n\t\t\tpage, hdr_size, frame_size,\n\t\t\tTBNET_RX_PAGE_SIZE - hdr_size);\n\nA packet of frame_count frames therefore ends up with frame_count - 1\nfragments. tbnet_check_frame() only bounds the peer supplied frame_count to\nTBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A\npeer that sends a packet of 19 or more small frames pushes nr_frags past\nMAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()-\u003efrags[] and\ncorrupts memory after the shared info.\n\nTighten the start of packet bound to MAX_SKB_FRAGS + 1 so a packet can never\nproduce more fragments than frags[] can hold. This matches the recent skb\nfrags overflow fixes in other receive paths, for example f0813bcd2d9d (\"net:\nwwan: t7xx: fix potential skb-\u003efrags overflow in RX path\") and 600dc40554dc\n(\"net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()\").",
  "id": "GHSA-8f5r-c72f-67g5",
  "modified": "2026-08-23T15:33:00Z",
  "published": "2026-08-15T06:32:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72157"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2b3b4e5ff5a58ad32817824b0310e63908b12052"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/55d9895f89970501fe126d1026b586b04a224c27"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/569ba39b2d12995a29dc158e5b4de6e449278f30"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6262f51e09d8dc8b07599a9e4f03bd3989d13fff"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e27beb4536cbf1d59e2d8c2840e87d972aba906f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e5824d5b841d99a2bcdd4e2c256643293bbc22c1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f96b3b35c622d565eff2438993e028d280163f5c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fe6b606fbf0c3beb94ccf17fcf31d8c2138264e3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

OESA-2026-3703 (CVE-2025-37979)

Vulnerability from osv_openeuler – Published: 2026-09-05 15:04 – Updated: 2026-09-05 15:04 – Source website

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ASoC: qcom: Fix sc7280 lpass potential buffer overflow

Case values introduced in commit 5f78e1fb7a3e ("ASoC: qcom: Add driver support for audioreach solution") cause out of bounds access in arrays of sc7280 driver data (e.g. in case of RX_CODEC_DMA_RX_0 in sc7280_snd_hw_params()).

Redefine LPASS_MAX_PORTS to consider the maximum possible port id for q6dsp as sc7280 driver utilizes some of those values.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37979)

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

net: usb: asix_devices: Fix PHY address mask in MDIO bus initialization

Syzbot reported shift-out-of-bounds exception on MDIO bus initialization.

The PHY address should be masked to 5 bits (0-31). Without this mask, invalid PHY addresses could be used, potentially causing issues with MDIO bus operations.

Fix this by masking the PHY address with 0x1f (31 decimal) to ensure it stays within the valid range.(CVE-2025-38736)

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

crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl

When page reassignment was added to af_alg_pull_tsgl the original loop wasn't updated so it may try to reassign one more page than necessary.

Add the check to the reassignment so that this does not happen.

Also update the comment which still refers to the obsolete offset argument.(CVE-2026-43078)

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

crypto: algif_aead - snapshot IV for async AEAD requests

AF_ALG AEAD AIO requests currently use the socket-wide IV buffer during request processing. For async requests, later socket activity can update that shared state before the original request has fully completed, which can lead to inconsistent IV handling.

Snapshot the IV into per-request storage when preparing the AEAD request, so in-flight operations no longer depend on mutable socket state.(CVE-2026-46028)

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

xfrm: esp: restore combined single-frag length gate

The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len.

Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len.

Restore this combined-length page gate for both IPv4 and IPv6.(CVE-2026-63912)

In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation. __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head, causing the previously obtained IP header pointer to become a dangling pointer, leading to a use-after-free vulnerability.(CVE-2026-68476)

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

ipvs: fix more places with wrong ipv6 transport offsets

Sashiko reports for more incorrect IPv6 transport offsets.

The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers.

Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.(CVE-2026-68477)

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

ipvs: use parsed transport offset in SCTP state lookup

set_sctp_state() reads the SCTP chunk header again in order to drive the IPVS SCTP state table. For IPv6 it computes the offset with sizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from ip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped extension headers and found the real transport header.

This makes the state machine read from the wrong offset for IPv6 SCTP packets that carry extension headers. For example, an INIT packet with an 8-byte destination options header can be scheduled correctly by sctp_conn_schedule(), but set_sctp_state() reads the first byte of the SCTP verification tag as a DATA chunk type. The connection then moves from NONE to ESTABLISHED instead of INIT1, gets the longer established timeout, and updates the active/inactive destination counters incorrectly. This happens even though the SCTP handshake has not completed.

Use the parsed transport offset passed down from ip_vs_set_state() for the SCTP chunk-header lookup. For IPv4 and IPv6 packets without extension headers this preserves the existing offset.(CVE-2026-72021)

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

ieee802154: admin-gate legacy LLSEC dump operations

In net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table builds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV, LLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which sets no .flags, so generic netlink runs them ungated. The modern nl802154 family admin-gates the equivalent reads via NL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM.

Any local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve the "802.15.4 MAC" family and dump LLSEC_LIST_KEY on any wpan netdev that has an LLSEC key installed; the dump handler writes the raw 16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied verbatim from struct ieee802154_llsec_key.key) into the reply. Recovering the AES key compromises 802.15.4 LLSEC link confidentiality and authenticity, since LLSEC uses CCM* and the same key authenticates and encrypts frames.

Impact: any local uid with no capabilities can read the raw 16-byte AES-128 LLSEC key from the kernel keytable on any wpan netdev that has an administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY dump on the legacy IEEE802154_NL generic-netlink family.

Introduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but setting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump entries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the modern nl802154 family exposes their equivalents to unprivileged readers by design (NL802154_CMD_GET_WPAN_PHY and NL802154_CMD_GET_INTERFACE carry "can be retrieved by unprivileged users" annotations).(CVE-2026-72049)

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

net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink

ip6gre_changelink() and ip6erspan_changelink() operate on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.

Gate both ops on rtnl_dev_link_net_capable() at their top, before any attribute is parsed.(CVE-2026-72052)

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

net: ipip: require CAP_NET_ADMIN in the device netns for changelink

ipip_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.

Gate ipip_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.(CVE-2026-72053)

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

net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink

vti_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.

Gate vti_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.(CVE-2026-72054)

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

net: sit: require CAP_NET_ADMIN in the device netns for changelink

ipip6_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.

Gate ipip6_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. sit was the one tunnel type not covered by the recent series that added this check to the other changelink() handlers.(CVE-2026-72061)

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

net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete

When an offloaded MACsec RX SC is deleted, macsec_del_rxsc_ctx() freed the per-SC metadata_dst with metadata_dst_free(), which kfree()s the object unconditionally and ignores the dst reference count. The RX datapath in mlx5e_macsec_offload_handle_rx_skb() looks up the SC under rcu_read_lock() via xa_load(), takes a reference with dst_hold() and attaches the dst to the skb with skb_dst_set(). A reader that already obtained the rx_sc pointer can race with the delete path and operate on freed memory.

Fix the owner side by dropping the reference with dst_release() instead of freeing unconditionally, and convert the RX datapath to dst_hold_safe() so a reader racing the SC delete cannot attach a dst whose last reference was just dropped; only attach it when a reference was actually taken.

mlx5e_macsec_add_rxsc() also published sc_xarray_element via xa_alloc() before rx_sc->md_dst was allocated and initialised, so a datapath reader that looked the SC up by fs_id could observe rx_sc with md_dst still NULL or, on weakly-ordered architectures, a non-NULL md_dst pointer whose contents were not yet visible. NULL-check the xa_load() result and md_dst on the datapath, and reorder add_rxsc() so the xa_alloc() publish happens only after md_dst is fully initialised; the xarray RCU publish then pairs with the rcu_read_lock()/xa_load() in the datapath.

Note: macsec_del_rxsc_ctx() also kfree()s rx_sc->sc_xarray_element without an RCU grace period while the same datapath reads it under rcu_read_lock(); that is a separate pre-existing issue left to a follow-up patch.

Found by 0sec automated security-research tooling (https://0sec.ai).(CVE-2026-72072)

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

nvmet-rdma: handle inline data with a nonzero offset

nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page:

sg-&gt;offset = off;
sg-&gt;length = min_t(int, len, PAGE_SIZE - off);

When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes "PAGE_SIZE - off" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist.

Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).(CVE-2026-72129)

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

tpm: Make the TPM character devices non-seekable

The TPM character devices expose a sequential command/response interface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE enabled.

After a command leaves a response pending, pread(fd, buf, 16, 0x1400) passes 0x1400 as off to tpm_common_read(). The transfer length is bounded by response_length, but the offset is used unchecked when forming data_buffer + off. A sufficiently large offset therefore causes an out-of-bounds heap read through copy_to_user() and, if the copy succeeds, an out-of-bounds zero-write through the following memset().

Positional I/O does not provide coherent semantics for this interface. An arbitrary pread offset cannot represent how much of a response has been consumed sequentially. The write callback always stores a command at the start of data_buffer, while pwrite() does not update file->f_pos and can leave the sequential read cursor stale.

Call nonseekable_open() from both open handlers. This removes FMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to fail with -ESPIPE before reaching the TPM callbacks, and explicitly marks the files non-seekable. Normal read() and write() continue to use the existing sequential f_pos cursor, leaving the response state machine unchanged.

Tested on Linux 6.12 with KASAN and a swtpm TPM2 device:

sequential partial reads returned the complete response
pread() and preadv() with offset 0x1400 returned -ESPIPE
pwrite() and pwritev() with offset zero returned -ESPIPE
the pending response remained intact after the rejected operations
a subsequent normal command/response cycle completed normally
no KASAN report was produced.(CVE-2026-72135)

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

xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink

xfrmi_changelink() operates on at most two netns, dev_net(dev) and the interface link netns xi->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in xi->net can rewrite an interface that lives in xi->net.

Gate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.(CVE-2026-72136)

In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Fix frags[] overflow by bounding frame_count. tbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The first frame goes into the skb linear area and every further frame is added as a page fragment. A packet of frame_count frames therefore ends up with frame_count - 1 fragments. tbnet_check_frame() only bounds the peer supplied frame_count to TBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A peer that sends a packet of 19 or more small frames pushes nr_frags past MAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()->frags[] and corrupts memory after the shared info.(CVE-2026-72157)

In the Linux kernel, the following vulnerability has been resolved: mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE. If DAX memory is hotplugged into an unoccupied subsection of an early section, section_activate() reuses the unoptimized boot memmap. However, compound_nr_pages() still assumes that vmemmap optimization is in effect and initializes only the reduced number of struct pages. As a result, the remaining tail struct pages are left uninitialized, which can later lead to unexpected behavior or crashes. Fix this by treating early sections as unoptimized when calculating how many struct pages to initialize.(CVE-2026-72172)

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

SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing

xdr_buf_to_bvec() writes a bio_vec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it.

rq_bvec, the array passed by nfsd_vfs_write(), is allocated to exactly rq_maxpages entries with no slack. The OOB store can land in adjacent slab memory; the bv_len and bv_offset fields written there are derived from client-supplied RPC payload sizes.

Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.(CVE-2026-72217)

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

sunrpc: wait for in-flight TLS handshake callback when cancel loses race

When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed.

The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result.

If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue.

If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed.

Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed to fire because handshake_complete() invokes svc_tcp_handshake_done() unconditionally once it has set HANDSHAKE_F_REQ_COMPLETED.(CVE-2026-72221)

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

sunrpc: pin svc_xprt across the asynchronous TLS handshake callback

svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of().

Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done.

The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry.

Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all().

cel: rewrote commit message to describe the actual change

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

batman-adv: retrieve ethhdr after potential skb realloc on RX

pskb_may_pull() in batadv_interface_rx() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free.

This was done correctly for the VLAN header but missed for the ethernet header which is later used for the TT and AP isolation handling.(CVE-2026-72235)

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

KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers

kvm_io_bus_get_dev() returns a device that is only matched by the address, and nothing else. This can cause a lifetime issue if the matched device is not the expected type, as by the time the caller can introspect the object, it might be gone (the srcu lock having been dropped).

Given that there is only a single user of this helper, the simplest option is to move the locking responsibility to the caller, which can keep the srcu lock held for as long as it wants.

Note that this aligns with other kvm_io_bus*() helpers, which already require the srcu lock to be held by the callers.(CVE-2026-72282)

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check. smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.input_buffer_length directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copy_to_user() then reads from io_rsp + OutputOffset, outside the response buffer, leading to an out-of-bounds read.(CVE-2026-72310)

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

dm era: fix NULL pointer dereference in metadata_open()

metadata_open() returns NULL when kzalloc_obj() fails, but the caller era_ctr() only checks IS_ERR(md). Since IS_ERR(NULL) returns false, the NULL pointer is treated as a valid result and later assigned to era->md, leading to a NULL pointer dereference when the metadata is accessed.

Fix this by returning ERR_PTR(-ENOMEM) on allocation failure, consistent with dm-cache-metadata.c, dm-thin-metadata.c, and dm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the same pattern.(CVE-2026-72316)

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

SUNRPC: pin upper rpc_clnt across the TLS connect_worker

The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt.

The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported.

Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one.

The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.(CVE-2026-72317)

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

cifs: validate DFS referral string offsets

parse_dfs_referrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server.

Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative max_len is then passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds.

Validate each string offset before deriving the string pointer.(CVE-2026-72318)

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

ipvs: ensure inner headers in ICMP errors are in headroom

Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG().

Also, add more checks for the length of the inner headers.(CVE-2026-72319)

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

net/tls: Consume empty data records in tls_sw_read_sock()

A peer may send a zero-length TLS application_data record; TLS 1.3 explicitly permits these as a traffic-analysis countermeasure (RFC 8446, Section 5.1). After decryption such a record has full_len == 0. tls_sw_read_sock() hands it to the read_actor, which has no payload to consume and returns zero. The loop treats a zero return as backpressure (used <= 0), requeues the skb at the head of rx_list, and stops. rx_list is serviced head-first on the next call, so the empty record is dequeued, fails the same way, and is requeued again; every later record on the connection is blocked behind it.

tls_sw_recvmsg() does not stall on this: a zero-length data record copies nothing and falls through to consume_skb(). Mirror that in the read_sock() path by recognizing an empty data record before the actor runs, consuming it, and continuing.(CVE-2026-72330)

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

qede: fix off-by-one in BD ring consumption on build_skb failure

qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption.

Commit 4e910dbe3650 ("qede: confirm skb is allocated before using") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable.

Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.(CVE-2026-72339)

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

net/mlx5e: Fix HV VHCA stats agent registration race

mlx5e_hv_vhca_stats_create() registers the stats agent through mlx5_hv_vhca_agent_create(). The helper publishes the agent in hv_vhca->agents[type] under agents_lock and immediately schedules an asynchronous control invalidation on the HV VHCA workqueue before returning to mlx5e.

The asynchronous invalidation invokes the control agent's invalidate callback, which reads the hypervisor control block and forwards the command to mlx5e_hv_vhca_stats_control(). That callback may either:

call cancel_delayed_work_sync(&priv->stats_agent.work), or
call queue_delayed_work(priv->wq, &sagent->work, sagent->delay).

However, the delayed_work and priv->stats_agent.agent are only initialized after mlx5_hv_vhca_agent_create() returns to mlx5e:

agent = mlx5_hv_vhca_agent_create(...);   /* publish + invalidate */
...
priv-&gt;stats_agent.agent = agent;          /* too late */
INIT_DELAYED_WORK(&amp;priv-&gt;stats_agent.work, ...); /* too late */

If the asynchronous control path runs before the two assignments above, it can:

Operate on an uninitialized delayed_work whose timer.function is NULL. queue_delayed_work() calls add_timer() unconditionally, so when the timer expires the timer softirq invokes a NULL function pointer.
Re-initialize the timer later through INIT_DELAYED_WORK() while the timer is already enqueued in the timer wheel, corrupting the hlist (entry.pprev cleared while the previous bucket node still points at this entry).
When the worker eventually runs, mlx5e_hv_vhca_stats_work() reads sagent->agent (NULL) and dereferences it inside mlx5_hv_vhca_agent_write().

Fix this by:

Initializing priv->stats_agent.work before invoking mlx5_hv_vhca_agent_create(), so the work is always in a valid state when the control callback observes it.
Adding a struct mlx5_hv_vhca_agent *ctx_update out-parameter to mlx5_hv_vhca_agent_create(). The helper writes the agent pointer to ctx_update before publishing into hv_vhca->agents[] and triggering the agents_update flow, so any callback subsequently invoked from that flow already sees a valid priv->stats_agent.agent. This avoids having the control callback participate in agent initialization.

While at it, access priv->stats_agent.agent with READ_ONCE()/WRITE_ONCE() for the cross-CPU access with the worker, and clear priv->stats_agent.buf on the agent_create() failure path.(CVE-2026-72342)

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

bridge: stp: Fix a potential use-after-free when deleting a bridge

The three STP timers are not supposed to be armed while the bridge is administratively down. They are synchronously deactivated when the bridge is put administratively down and the various call sites check for 'IFF_UP' before arming them.

This check is missing from br_topology_change_detection() and it is possible to engineer a situation in which the topology change timer is armed while the bridge is administratively down, resulting in a use-after-free [1] when the bridge is deleted.

Fix by adding the missing check and for good measures synchronously shutdown the three timers when the bridge is deleted.

[1] ODEBUG: free active (active state 0) object: ffff88811662b9b0 object type: timer_list hint: br_topology_change_timer_expired (net/bridge/br_stp_timer.c:120) WARNING: lib/debugobjects.c:629 at debug_print_object+0x1bc/0x450, CPU#9: ip/359(CVE-2026-72389)

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

seg6: validate SRH length before reading fixed fields

seg6_validate_srh() reads fixed SRH fields such as srh->type and srh->hdrlen before checking that the supplied length covers the fixed struct ipv6_sr_hdr fields.

The BPF SEG6 encap path reaches this with a BPF program-supplied pointer and length: bpf_lwt_push_encap() and the SEG6 local BPF END_B6 and END_B6_ENCAP actions call bpf_push_seg6_encap(), which forwards the length to seg6_validate_srh() with no minimum-size guard. A 2-byte SEG6 encap header can therefore make the validator read srh->type at offset 2 beyond the caller-supplied buffer.

Reject lengths shorter than the fixed SRH at the top of seg6_validate_srh(), before any field is read. This fixes the BPF helper path and keeps the common validator robust.(CVE-2026-72400)

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

ice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()

Resetting all VFs causes resource leak on VFs with FDIR filters enabled as CTRL VSIs are only invalidated and not freed. Fix by using ice_vf_ctrl_vsi_release() instead of ice_vf_ctrl_invalidate_vsi() which aligns behavior with the ice_reset_vf() function.

Reproduction: echo 1 > /sys/class/net/$pf/device/sriov_numvfs ethtool -N $vf flow-type ether proto 0x9000 action 0 echo 1 > /sys/class/net/$pf/device/reset(CVE-2026-72425)

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

xfrm: validate selector family and prefixlen during match

syzbot reported a shift-out-of-bounds in xfrm_selector_match() due to AF_UNSPEC selector with large prefixlen (e.g. 128) matched against IPv4 flow (when XFRM_STATE_AF_UNSPEC is set).

Fix this by:

Rejecting mismatched families in xfrm_selector_match.
Returning false in addr4_match if prefixlen > 32.
Returning false in addr_match if prefixlen > 128 (prevents overflow).(CVE-2026-72450)

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

apparmor: aa_label_alloc use aa_label_free on alloc failure

aa_label_alloc() allocates a secid before allocating or taking the label proxy. If the later proxy step fails, the error path only freed the label memory, leaking any resources initialized by aa_label_init().

Use aa_label_free() on the failure path so partially initialized labels release their secid and other label resources before the backing memory is freed.(CVE-2026-72459)

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

apparmor: check label build before no_new_privs test

aa_change_profile() builds a replacement label with fn_label_build_in_scope() before the no_new_privs subset check. The build helper can fail and return NULL or an ERR_PTR, but the result was passed to aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL() check.

Reuse the existing target-label build failure handling immediately after the build. This preserves the current audit handling while preventing the subset helper from dereferencing an invalid label.(CVE-2026-72460)

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

xprtrdma: Repost Receive buffers for malformed replies

rpcrdma_wc_receive() decrements the transport's Receive count for every completion before it dispatches a successful Receive to rpcrdma_reply_handler(). The handler must post a replacement Receive WR before returning unless ownership of the rep has moved elsewhere, as on the backchannel path.

Commit 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC senders and posting Receives") moved the Receive refill out of rpcrdma_wc_receive(), where it had run ahead of every reply, into rpcrdma_reply_handler() so that the responder's credit grant could be parsed before reposting. The bad-version and short-reply exits never reach that refill: they recycle the rep and return without calling rpcrdma_post_recvs().

A remote peer can therefore drain the client's posted Receive queue by sending a sustained stream of replies that are shorter than the fixed transport header or that carry an unrecognized RPC/RDMA version. Each such reply consumes one posted Receive without replacing it. Once the queue empties, the peer's next Send finds no posted Receive and the transport stalls until reconnect.

Route both malformed-reply exits through the shared repost tail after recycling the rep, refilling against buf->rb_credits, the most recent accepted credit grant. Neither exit updates the congestion window, so RPCs admitted under the previous grant remain in flight awaiting replies. A smaller refill target would let a stream of malformed replies ratchet the posted Receive count down to the batch floor while the congestion window still admits rb_credits RPCs; a burst of valid replies to those RPCs could then overrun the posted Receives, and because the client connects with rnr_retry_count of zero, a single RNR NAK terminates the connection. Refilling against rb_credits also restores the target that applied to malformed replies before commit 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC senders and posting Receives") when rpcrdma_post_recvs() computed it from rb_credits internally. rb_credits is at least one from connection establishment onward, so the repost path always keeps Receives posted.(CVE-2026-72464)

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

xprtrdma: Fix bcall rep leak and unbounded peek

rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue.

First, the speculative peek

p = xdr_inline_decode(xdr, 0);
/* five p++ reads follow */

asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call.

Second, after the post-peek

p = xdr_inline_decode(xdr, 3 * sizeof(*p));
if (unlikely(!p))
        return true;

the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path:

rpcrdma_reply_handler()
  if (rpcrdma_is_bcall(r_xprt, rep))
          return;        /* bare return, skips out_post */
  ...
out_post:
  rpcrdma_post_recvs(r_xprt, credits + ...);

Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs.

Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).(CVE-2026-72466)

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

xprtrdma: Decouple req recycling from RPC completion

rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer.

Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off.

The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry.

Three invariants follow:

Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot.
The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs.
The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied.

Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected.

Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released.

The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.(CVE-2026-72473)

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

power: supply: core: fix supplied_from allocations

If dts property power-supplies has multiple values, then accessing to psy->supplied_from[i-1] in __power_supply_populate_supplied_from will overrun supplied_from array.(CVE-2026-74271)

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

tipc: require net admin for TIPCv2 netlink mutators

TIPCv2 registers mutating generic-netlink operations without admin permission flags. Generic netlink only checks CAP_NET_ADMIN when an operation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local unprivileged process can currently change TIPC state through commands such as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and bearer enable/disable.

The legacy TIPC netlink API already checks netlink_net_capable(..., CAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators the equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which maps to the same namespace-aware CAP_NET_ADMIN check that netlink_net_capable() performs, so the behaviour matches the legacy path and keeps working for CAP_NET_ADMIN holders in a non-initial user namespace (containers).

A QEMU/KASAN repro run as uid/gid 65534 with zero effective capabilities previously succeeded in changing the network id and node identity, setting and flushing key material, and enabling/disabling a UDP bearer. With this patch applied the same operations fail with -EPERM.(CVE-2026-74283)

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

sctp: validate embedded address parameter length

sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter.

Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter.

Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds.

This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.(CVE-2026-74287)

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

bpf: Tighten cgroup storage cookie checks for prog arrays

The fix in commit abad3d0bad72 ("bpf: Fix oob access in cgroup local storage") is still incomplete. The prog-array compatibility check treats a program with no cgroup storage as compatible with any stored storage cookie. This allows a storage-less program to bridge a tail call chain between an entry program and a storage-using callee even though cgroup local storage at runtime still follows the caller's context, that is, A -> B(no storage) -> C(storage) path.

Requiring exact cookie equality would break the legitimate case of a storage-less leaf program being tail called from a storage-using one. Instead, only accept a zero storage cookie if the program cannot perform tail calls itself. This keeps A -> B(no storage) working while rejecting the A -> B(no storage) -> C(storage) bridge.(CVE-2026-74305)

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

RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path

For non-SRQ QPs, the responder reads WQE fields directly from the shared queue buffer mapped into userspace. This allows a malicious user to modify fields like num_sge or sge entries while the kernel is processing the WQE, leading to out-of-bounds reads in rxe_resp_check_length() and copy_data().

Introduce get_recv_wqe() that validates num_sge and copies the WQE to a kernel-local buffer before processing, matching the approach already used for SRQ WQEs in get_srq_wqe(). The srq_wqe buffer is reused since SRQ and non-SRQ paths are mutually exclusive per QP.(CVE-2026-74377)

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

RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe

get_srq_wqe() reads wqe->dma.num_sge from the shared receive queue buffer, which is mapped into userspace. It validates num_sge against max_sge, but then re-reads the same field to calculate the memcpy size. A concurrent userspace thread can modify num_sge between validation and use, causing a heap buffer overflow when copying the WQE into qp->resp.srq_wqe.

Read num_sge into a local variable and use it for both the bounds check and the size calculation.(CVE-2026-74378)

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

RDMA/srpt: fix integer overflow in immediate data length check

imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one().

Use check_add_overflow() to detect wrapping before the comparison.(CVE-2026-74394)

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

IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier

mlx5_ib_alloc_transport_domain() allocates a transport domain and then may fail in mlx5_ib_enable_lb(). In that case, the allocated TD is leaked.

Fix this by deallocating the TD when mlx5_ib_enable_lb() returns an error. Also return 0 explicitly in the no-loopback-capability success branch, and move dev->lb.mutex initialization to mlx5_ib_stage_init_init().(CVE-2026-74397)

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

ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD

addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list).

addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry:

general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40

Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.(CVE-2026-74398)

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

vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().

udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running.

Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().(CVE-2026-74406)

Severity

9.8 (Critical)


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

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-37979	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38736	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43078	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46028	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-63912	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-68476	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-68477	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72021	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72049	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72052	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72053	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72054	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72061	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72072	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72129	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72135	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72136	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72157	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72172	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72217	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72221	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72222	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72235	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72282	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72310	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72316	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72317	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72318	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72319	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72330	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72339	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72342	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72389	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72400	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72425	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72450	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72459	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72460	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72464	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72466	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72473	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-74271	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-74283	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-74287	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-74305	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-74377	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-74378	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-74394	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-74397	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-74398	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-74406	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
          "kernel-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
          "kernel-debuginfo-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
          "kernel-debugsource-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
          "kernel-devel-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
          "kernel-headers-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
          "kernel-source-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
          "kernel-tools-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
          "kernel-tools-devel-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
          "perf-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
          "perf-debuginfo-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
          "python3-perf-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-145.1.24.161.oe2403sp1.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
          "kernel-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
          "kernel-debuginfo-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
          "kernel-debugsource-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
          "kernel-devel-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
          "kernel-headers-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
          "kernel-source-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
          "kernel-tools-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
          "kernel-tools-devel-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
          "perf-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
          "perf-debuginfo-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
          "python3-perf-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS-SP1",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-145.1.24.161.oe2403sp1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: qcom: Fix sc7280 lpass potential buffer overflow\n\nCase values introduced in commit\n5f78e1fb7a3e (\u0026quot;ASoC: qcom: Add driver support for audioreach solution\u0026quot;)\ncause out of bounds access in arrays of sc7280 driver data (e.g. in case\nof RX_CODEC_DMA_RX_0 in sc7280_snd_hw_params()).\n\nRedefine LPASS_MAX_PORTS to consider the maximum possible port id for\nq6dsp as sc7280 driver utilizes some of those values.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37979)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: asix_devices: Fix PHY address mask in MDIO bus initialization\n\nSyzbot reported shift-out-of-bounds exception on MDIO bus initialization.\n\nThe PHY address should be masked to 5 bits (0-31). Without this\nmask, invalid PHY addresses could be used, potentially causing issues\nwith MDIO bus operations.\n\nFix this by masking the PHY address with 0x1f (31 decimal) to ensure\nit stays within the valid range.(CVE-2025-38736)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl\n\nWhen page reassignment was added to af_alg_pull_tsgl the original\nloop wasn\u0026apos;t updated so it may try to reassign one more page than\nnecessary.\n\nAdd the check to the reassignment so that this does not happen.\n\nAlso update the comment which still refers to the obsolete offset\nargument.(CVE-2026-43078)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_aead - snapshot IV for async AEAD requests\n\nAF_ALG AEAD AIO requests currently use the socket-wide IV buffer during\nrequest processing.  For async requests, later socket activity can\nupdate that shared state before the original request has fully\ncompleted, which can lead to inconsistent IV handling.\n\nSnapshot the IV into per-request storage when preparing the AEAD\nrequest, so in-flight operations no longer depend on mutable socket\nstate.(CVE-2026-46028)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: esp: restore combined single-frag length gate\n\nThe ESP out-of-place fast path appends the trailer in esp_output_head()\nbefore esp_output_tail() allocates the destination page frag. The\nhead-side gate currently checks skb-\u0026gt;data_len and tailen separately, but\nthe tail code allocates a single destination frag from the combined\npost-trailer skb-\u0026gt;data_len.\n\nReject the page-frag fast path when the combined aligned length exceeds a\npage. Otherwise skb_page_frag_refill() may fall back to a single page while\nthe destination sg still spans the combined skb-\u0026gt;data_len.\n\nRestore this combined-length page gate for both IPv4 and IPv6.(CVE-2026-63912)\n\nIn the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation. __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb-\u0026gt;head, causing the previously obtained IP header pointer to become a dangling pointer, leading to a use-after-free vulnerability.(CVE-2026-68476)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix more places with wrong ipv6 transport offsets\n\nSashiko reports for more incorrect IPv6 transport offsets.\n\nThe app code for TCP was assuming IPv4 network header\neven after the ipvsh argument was provided. This can\ncause problems with apps over IPv6. As for the only\nofficial app in the kernel tree (FTP) this problem is\nharmless because we use Netfilter to mangle the FTP\nports and we do not adjust the TCP seq numbers.\n\nAlso, provide correct offset of the ICMPV6 header in\nip_vs_out_icmp_v6() for correct checksum checks when\nthe IPv6 packet has extension headers.(CVE-2026-68477)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: use parsed transport offset in SCTP state lookup\n\nset_sctp_state() reads the SCTP chunk header again in order to drive the\nIPVS SCTP state table. For IPv6 it computes the offset with\nsizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from\nip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped\nextension headers and found the real transport header.\n\nThis makes the state machine read from the wrong offset for IPv6 SCTP\npackets that carry extension headers. For example, an INIT packet with an\n8-byte destination options header can be scheduled correctly by\nsctp_conn_schedule(), but set_sctp_state() reads the first byte of the\nSCTP verification tag as a DATA chunk type. The connection then moves\nfrom NONE to ESTABLISHED instead of INIT1, gets the longer established\ntimeout, and updates the active/inactive destination counters\nincorrectly. This happens even though the SCTP handshake has not\ncompleted.\n\nUse the parsed transport offset passed down from ip_vs_set_state() for\nthe SCTP chunk-header lookup. For IPv4 and IPv6 packets without\nextension headers this preserves the existing offset.(CVE-2026-72021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nieee802154: admin-gate legacy LLSEC dump operations\n\nIn net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table\nbuilds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV,\nLLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which\nsets no .flags, so generic netlink runs them ungated. The modern\nnl802154 family admin-gates the equivalent reads via\nNL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM.\n\nAny local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve\nthe \u0026quot;802.15.4 MAC\u0026quot; family and dump LLSEC_LIST_KEY on any wpan netdev\nthat has an LLSEC key installed; the dump handler writes the raw\n16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied\nverbatim from struct ieee802154_llsec_key.key) into the reply.\nRecovering the AES key compromises 802.15.4 LLSEC link confidentiality\nand authenticity, since LLSEC uses CCM* and the same key authenticates\nand encrypts frames.\n\nImpact: any local uid with no capabilities can read the raw 16-byte\nAES-128 LLSEC key from the kernel keytable on any wpan netdev that has\nan administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY\ndump on the legacy IEEE802154_NL generic-netlink family.\n\nIntroduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but\nsetting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump\nentries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the\nmodern nl802154 family exposes their equivalents to unprivileged\nreaders by design (NL802154_CMD_GET_WPAN_PHY and\nNL802154_CMD_GET_INTERFACE carry \u0026quot;can be retrieved by unprivileged\nusers\u0026quot; annotations).(CVE-2026-72049)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink\n\nip6gre_changelink() and ip6erspan_changelink() operate on at most two\nnetns, dev_net(dev) and the tunnel link netns t-\u0026gt;net. They differ once\nthe device is created in or moved to a netns other than the one the\nrequest runs in. The rtnl changelink path checks CAP_NET_ADMIN only\nagainst dev_net(dev), so a caller privileged there but not in t-\u0026gt;net can\nrewrite a tunnel that lives in t-\u0026gt;net.\n\nGate both ops on rtnl_dev_link_net_capable() at their top, before any\nattribute is parsed.(CVE-2026-72052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipip: require CAP_NET_ADMIN in the device netns for changelink\n\nipip_changelink() operates on at most two netns, dev_net(dev) and the\ntunnel link netns t-\u0026gt;net. They differ once the device is created in or\nmoved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in t-\u0026gt;net can rewrite a tunnel that\nlives in t-\u0026gt;net.\n\nGate ipip_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed.(CVE-2026-72053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ip_vti: require CAP_NET_ADMIN in the device netns for changelink\n\nvti_changelink() operates on at most two netns, dev_net(dev) and the\ntunnel link netns t-\u0026gt;net. They differ once the device is created in or\nmoved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in t-\u0026gt;net can rewrite a tunnel that\nlives in t-\u0026gt;net.\n\nGate vti_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed.(CVE-2026-72054)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: sit: require CAP_NET_ADMIN in the device netns for changelink\n\nipip6_changelink() operates on at most two netns, dev_net(dev) and the\ntunnel link netns t-\u0026gt;net. They differ once the device is created in or\nmoved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in t-\u0026gt;net can rewrite a tunnel that\nlives in t-\u0026gt;net.\n\nGate ipip6_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed. sit was the one tunnel type not covered\nby the recent series that added this check to the other changelink()\nhandlers.(CVE-2026-72061)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete\n\nWhen an offloaded MACsec RX SC is deleted, macsec_del_rxsc_ctx() freed\nthe per-SC metadata_dst with metadata_dst_free(), which kfree()s the\nobject unconditionally and ignores the dst reference count. The RX\ndatapath in mlx5e_macsec_offload_handle_rx_skb() looks up the SC under\nrcu_read_lock() via xa_load(), takes a reference with dst_hold() and\nattaches the dst to the skb with skb_dst_set(). A reader that already\nobtained the rx_sc pointer can race with the delete path and operate on\nfreed memory.\n\nFix the owner side by dropping the reference with dst_release() instead\nof freeing unconditionally, and convert the RX datapath to\ndst_hold_safe() so a reader racing the SC delete cannot attach a dst\nwhose last reference was just dropped; only attach it when a reference\nwas actually taken.\n\nmlx5e_macsec_add_rxsc() also published sc_xarray_element via xa_alloc()\nbefore rx_sc-\u0026gt;md_dst was allocated and initialised, so a datapath reader\nthat looked the SC up by fs_id could observe rx_sc with md_dst still\nNULL or, on weakly-ordered architectures, a non-NULL md_dst pointer\nwhose contents were not yet visible. NULL-check the xa_load() result and\nmd_dst on the datapath, and reorder add_rxsc() so the xa_alloc() publish\nhappens only after md_dst is fully initialised; the xarray RCU publish\nthen pairs with the rcu_read_lock()/xa_load() in the datapath.\n\nNote: macsec_del_rxsc_ctx() also kfree()s rx_sc-\u0026gt;sc_xarray_element\nwithout an RCU grace period while the same datapath reads it under\nrcu_read_lock(); that is a separate pre-existing issue left to a\nfollow-up patch.\n\nFound by 0sec automated security-research tooling (https://0sec.ai).(CVE-2026-72072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-rdma: handle inline data with a nonzero offset\n\nnvmet_rdma_use_inline_sg() maps the host-controlled inline data offset\ninto the per-command inline scatterlist.  The bounds check admits any\noffset with off + len \u0026lt;= inline_data_size, but the mapping still assumes\nthe data begins in the first inline page:\n\n\tsg-\u0026gt;offset = off;\n\tsg-\u0026gt;length = min_t(int, len, PAGE_SIZE - off);\n\nWhen a port is configured with inline_data_size \u0026gt; PAGE_SIZE (settable up\nto max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size]\nmakes \u0026quot;PAGE_SIZE - off\u0026quot; underflow, so sg-\u0026gt;length is set to ~4 GiB and\nthe block backend reads far past the first inline page.  num_pages(len)\nalso ignores the offset, so an in-bounds offset whose [off, off+len)\nspan crosses a page boundary under-counts the scatterlist.\n\nMap the offset properly: split it into a page index and an in-page\noffset, start the scatterlist at that page, and size the page count from\npage_off + len.  Because the request scatterlist may now start at\ninline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL\nidentity test in nvmet_rdma_release_rsp() to a range test; otherwise the\npersistent inline scatterlist is mistaken for an allocated one and\nnvmet_req_free_sgls() frees an inline page (and warns in\nfree_large_kmalloc()).(CVE-2026-72129)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntpm: Make the TPM character devices non-seekable\n\nThe TPM character devices expose a sequential command/response\ninterface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE\nenabled.\n\nAfter a command leaves a response pending, pread(fd, buf, 16, 0x1400)\npasses 0x1400 as *off to tpm_common_read(). The transfer length is\nbounded by response_length, but the offset is used unchecked when\nforming data_buffer + *off. A sufficiently large offset therefore causes\nan out-of-bounds heap read through copy_to_user() and, if the copy\nsucceeds, an out-of-bounds zero-write through the following memset().\n\nPositional I/O does not provide coherent semantics for this interface.\nAn arbitrary pread offset cannot represent how much of a response has\nbeen consumed sequentially. The write callback always stores a command\nat the start of data_buffer, while pwrite() does not update file-\u0026gt;f_pos\nand can leave the sequential read cursor stale.\n\nCall nonseekable_open() from both open handlers. This removes\nFMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to\nfail with -ESPIPE before reaching the TPM callbacks, and explicitly\nmarks the files non-seekable. Normal read() and write() continue to use\nthe existing sequential f_pos cursor, leaving the response state machine\nunchanged.\n\nTested on Linux 6.12 with KASAN and a swtpm TPM2 device:\n\n - sequential partial reads returned the complete response\n - pread() and preadv() with offset 0x1400 returned -ESPIPE\n - pwrite() and pwritev() with offset zero returned -ESPIPE\n - the pending response remained intact after the rejected operations\n - a subsequent normal command/response cycle completed normally\n - no KASAN report was produced.(CVE-2026-72135)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink\n\nxfrmi_changelink() operates on at most two netns, dev_net(dev) and the\ninterface link netns xi-\u0026gt;net. They differ once the device is created in\nor moved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in xi-\u0026gt;net can rewrite an interface that\nlives in xi-\u0026gt;net.\n\nGate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed.(CVE-2026-72136)\n\nIn the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Fix frags[] overflow by bounding frame_count. tbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The first frame goes into the skb linear area and every further frame is added as a page fragment. A packet of frame_count frames therefore ends up with frame_count - 1 fragments. tbnet_check_frame() only bounds the peer supplied frame_count to TBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A peer that sends a packet of 19 or more small frames pushes nr_frags past MAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()-\u0026gt;frags[] and corrupts memory after the shared info.(CVE-2026-72157)\n\nIn the Linux kernel, the following vulnerability has been resolved: mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE. If DAX memory is hotplugged into an unoccupied subsection of an early section, section_activate() reuses the unoptimized boot memmap. However, compound_nr_pages() still assumes that vmemmap optimization is in effect and initializes only the reduced number of struct pages. As a result, the remaining tail struct pages are left uninitialized, which can later lead to unexpected behavior or crashes. Fix this by treating early sections as unoptimized when calculating how many struct pages to initialize.(CVE-2026-72172)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: Bound-check xdr_buf_to_bvec() stores before writing\n\nxdr_buf_to_bvec() writes a bio_vec into the caller\u0026apos;s array before\ntesting whether that slot is in range, and the head branch performs\nthe store with no check at all. When the caller\u0026apos;s budget is exactly\nused up, the next store lands one element past the end of the array.\nThe overflow label returns count - 1, which masks the surplus store\nbut cannot undo it.\n\nrq_bvec, the array passed by nfsd_vfs_write(), is allocated to\nexactly rq_maxpages entries with no slack. The OOB store can land in\nadjacent slab memory; the bv_len and bv_offset fields written there\nare derived from client-supplied RPC payload sizes.\n\nMove the in-range check ahead of the store in the head, page-loop,\nand tail branches. With the check at the top of each sequence, count\nis incremented only after a successful store, so the overflow label\ncan return count directly.(CVE-2026-72217)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: wait for in-flight TLS handshake callback when cancel loses race\n\nWhen wait_for_completion_interruptible_timeout() in\nsvc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and\ntls_handshake_cancel() then returns false, handshake_complete() has\nwon the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and\nis about to invoke svc_tcp_handshake_done(), but the callback\u0026apos;s\nside effects on xpt_flags and on svsk-\u0026gt;sk_handshake_done have not\nyet committed.\n\nThe current code reads xpt_flags immediately to decide whether the\nsession succeeded. Two races result.\n\nIf the callback has executed set_bit(XPT_TLS_SESSION) but not yet\nclear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session,\nenqueues the transport, and returns. svc_xprt_received() then\nclears XPT_BUSY, a worker thread picks the transport up, the\ndispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set,\nand xpo_handshake is invoked a second time. That svc_tcp_handshake()\ncalls init_completion(\u0026amp;svsk-\u0026gt;sk_handshake_done) while the original\ncallback concurrently calls complete_all() on it, corrupting the\nembedded swait_queue.\n\nIf the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet\nentered svc_tcp_handshake_done(), svc_tcp_handshake() reads\nXPT_TLS_SESSION as clear and tears the connection down even though\nthe handshake is about to succeed.\n\nWait for the callback to commit before inspecting xpt_flags. The\ncompletion is guaranteed to fire because handshake_complete()\ninvokes svc_tcp_handshake_done() unconditionally once it has set\nHANDSHAKE_F_REQ_COMPLETED.(CVE-2026-72221)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: pin svc_xprt across the asynchronous TLS handshake callback\n\nsvc_tcp_handshake() stores the raw svc_xprt pointer in\ntls_handshake_args.ta_data and submits the request through\ntls_server_hello_x509(). The handshake core takes only\nsock_hold(req-\u0026gt;hr_sk); nothing references the embedding struct\nsvc_sock that svc_tcp_handshake_done() reaches via container_of().\n\nTwo close races leave the in-flight callback writing through a freed\nsvc_sock. svc_sock_free() calls tls_handshake_cancel() and discards\nits return value: a false return means handshake_complete() has\nalready set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have\nfinished, yet svc_sock_free() proceeds to kfree(svsk). The\ncancel-loser fall-through inside svc_tcp_handshake() itself produces\nthe same window: when wait_for_completion_interruptible_timeout()\nreturns \u0026lt;= 0 (timeout or signal) and tls_handshake_cancel() returns\nfalse, the function does not drain, returns, and svc_handle_xprt()\ncalls svc_xprt_received(), which clears XPT_BUSY and can drop the\nlast reference. A concurrent close then runs svc_sock_free() while\nsvc_tcp_handshake_done() is still updating xpt_flags and walking\nsvsk-\u0026gt;sk_handshake_done.\n\nThe corruption surfaces as set_bit/clear_bit RMW into the freed\nxpt_flags slab slot and as complete_all() walking and writing the\nfreed wait_queue_head_t list embedded in sk_handshake_done -- a\nslab-corruption primitive, not a benign read. The path is reachable\non any TLS-enabled NFS server whenever a connection close overlaps\nthe tlshd downcall delivery window; the interruptible wait means\nsignal delivery suffices, not just SVC_HANDSHAKE_TO expiry.\n\nTake svc_xprt_get(xprt) immediately before tls_server_hello_x509()\nso the in-flight callback owns its own reference. Release it on the\ntwo edges where the callback is guaranteed not to fire -- submission\nfailure from tls_server_hello_x509() and a successful\ntls_handshake_cancel() -- and at the tail of\nsvc_tcp_handshake_done() after complete_all().\n\n[cel: rewrote commit message to describe the actual change](CVE-2026-72222)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: retrieve ethhdr after potential skb realloc on RX\n\npskb_may_pull() in batadv_interface_rx() could reallocate the buffer behind\nthe skb. Variables which were pointing to the old buffer need to be\nreassigned to avoid an use-after-free.\n\nThis was done correctly for the VLAN header but missed for the ethernet\nheader which is later used for the TT and AP isolation handling.(CVE-2026-72235)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Move kvm_io_bus_get_dev() locking responsibilities to callers\n\nkvm_io_bus_get_dev() returns a device that is only matched by the\naddress, and nothing else. This can cause a lifetime issue if\nthe matched device is not the expected type, as by the time\nthe caller can introspect the object, it might be gone (the srcu\nlock having been dropped).\n\nGiven that there is only a single user of this helper, the simplest\noption is to move the locking responsibility to the caller, which\ncan keep the srcu lock held for as long as it wants.\n\nNote that this aligns with other kvm_io_bus*() helpers, which\nalready require the srcu lock to be held by the callers.(CVE-2026-72282)\n\nIn the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check. smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.input_buffer_length directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copy_to_user() then reads from io_rsp + OutputOffset, outside the response buffer, leading to an out-of-bounds read.(CVE-2026-72310)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm era: fix NULL pointer dereference in metadata_open()\n\nmetadata_open() returns NULL when kzalloc_obj() fails, but the\ncaller era_ctr() only checks IS_ERR(md).  Since IS_ERR(NULL)\nreturns false, the NULL pointer is treated as a valid result\nand later assigned to era-\u0026gt;md, leading to a NULL pointer\ndereference when the metadata is accessed.\n\nFix this by returning ERR_PTR(-ENOMEM) on allocation failure,\nconsistent with dm-cache-metadata.c, dm-thin-metadata.c, and\ndm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the\nsame pattern.(CVE-2026-72316)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: pin upper rpc_clnt across the TLS connect_worker\n\nThe TLS connect path has a use-after-free: nothing pins the\nupper rpc_clnt across the delayed connect_worker. xs_connect()\nstores task-\u0026gt;tk_client in sock_xprt::clnt as a raw pointer\nand queues the worker; for TLS-secured transports that worker\nis xs_tcp_tls_setup_socket(), which reads several fields out\nof the saved pointer (cl_timeout, cl_program, cl_prog,\ncl_vers, cl_cred, cl_stats) to construct the args for the\ninner handshake rpc_clnt.\n\nThe xprt does not reference the rpc_clnt; the rpc_clnt\nreferences the xprt. xs_destroy() does cancel the\nconnect_worker, but it runs only when the xprt\u0026apos;s refcount\ndrops to zero, which cannot happen until the rpc_clnt\nreleases its cl_xprt reference in rpc_free_client_work().\nWhen a TLS handshake fails fatally (for example, an mTLS\nmount whose client cert does not match the server), the\nconnecting task is woken with -EACCES and exits, the mount\ncaller invokes rpc_shutdown_client(), and the upper rpc_clnt\nis freed before the queued connect_worker fires.\nxs_tcp_tls_setup_socket() then dereferences the freed clnt,\nproducing the refcount_t underflow Michael Nemanov reported.\n\nTake a reference on the upper rpc_clnt in xs_connect() for\nTLS transports via a new rpc_hold_client() helper, and drop\nit in the connect_worker\u0026apos;s exit path with rpc_release_client().\nThe xprt_lock_connect() / xprt_unlock_connect() pairing\nalready serialises xs_connect() with xs_tcp_tls_setup_socket(),\nso the take and release are balanced one-for-one.\n\nThe non-TLS connect worker (xs_tcp_setup_socket) never reads\nsock_xprt::clnt, so leave that path alone and avoid the\nclnt-holds-xprt-holds-clnt cycle that would otherwise prevent\nxprt destruction.(CVE-2026-72317)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: validate DFS referral string offsets\n\nparse_dfs_referrals() validates that the response header and referral\narray fit in the received buffer, but each referral also contains string\noffsets supplied by the server.\n\nThose offsets are used to compute the DfsPath and NetworkAddress string\npointers without checking whether they still point inside the response\nbuffer. A malformed referral can therefore make the computed pointer\nexceed the end of the buffer. The resulting negative max_len is then\npassed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it\nto kstrndup() as a size_t, allowing strnlen() to read out of bounds.\n\nValidate each string offset before deriving the string pointer.(CVE-2026-72318)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: ensure inner headers in ICMP errors are in headroom\n\nSashiko points out that after stripping the outer headers\nwith pskb_pull() we should ensure the inner IP headers\nin ICMP errors from tunnels are present in the skb headroom\nfor functions like ipv4_update_pmtu(), icmp_send() and\nIP_VS_DBG().\n\nAlso, add more checks for the length of the inner headers.(CVE-2026-72319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/tls: Consume empty data records in tls_sw_read_sock()\n\nA peer may send a zero-length TLS application_data record; TLS 1.3\nexplicitly permits these as a traffic-analysis countermeasure (RFC\n8446, Section 5.1). After decryption such a record has full_len ==\n0. tls_sw_read_sock() hands it to the read_actor, which has no\npayload to consume and returns zero. The loop treats a zero return\nas backpressure (used \u0026lt;= 0), requeues the skb at the head of\nrx_list, and stops. rx_list is serviced head-first on the next\ncall, so the empty record is dequeued, fails the same way, and is\nrequeued again; every later record on the connection is blocked\nbehind it.\n\ntls_sw_recvmsg() does not stall on this: a zero-length data record\ncopies nothing and falls through to consume_skb(). Mirror that in\nthe read_sock() path by recognizing an empty data record before\nthe actor runs, consuming it, and continuing.(CVE-2026-72330)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqede: fix off-by-one in BD ring consumption on build_skb failure\n\nqede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a\nNULL return from qede_build_skb(). When it returns NULL under memory\npressure, the functions still consume a BD from the ring before\nreturning NULL. The callers then recycle additional BDs, resulting in\none extra BD being consumed (off-by-one). This desynchronizes the BD\nring, which can corrupt DMA page reference counts and lead to SLUB\nfreelist corruption.\n\nCommit 4e910dbe3650 (\u0026quot;qede: confirm skb is allocated before using\u0026quot;)\nadded a NULL check inside qede_build_skb() to prevent a NULL pointer\ndereference, but did not address the missing NULL checks in the\ncallers, making this off-by-one reachable.\n\nFix this by adding NULL checks for the return value of\nqede_build_skb() in both qede_rx_build_skb() and\nqede_tpa_rx_build_skb(), returning NULL immediately before any BD ring\nmanipulation.(CVE-2026-72339)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix HV VHCA stats agent registration race\n\nmlx5e_hv_vhca_stats_create() registers the stats agent through\nmlx5_hv_vhca_agent_create(). The helper publishes the agent in\nhv_vhca-\u0026gt;agents[type] under agents_lock and immediately schedules an\nasynchronous control invalidation on the HV VHCA workqueue before\nreturning to mlx5e.\n\nThe asynchronous invalidation invokes the control agent\u0026apos;s invalidate\ncallback, which reads the hypervisor control block and forwards the\ncommand to mlx5e_hv_vhca_stats_control(). That callback may either:\n\n  - call cancel_delayed_work_sync(\u0026amp;priv-\u0026gt;stats_agent.work), or\n  - call queue_delayed_work(priv-\u0026gt;wq, \u0026amp;sagent-\u0026gt;work, sagent-\u0026gt;delay).\n\nHowever, the delayed_work and priv-\u0026gt;stats_agent.agent are only\ninitialized after mlx5_hv_vhca_agent_create() returns to mlx5e:\n\n    agent = mlx5_hv_vhca_agent_create(...);   /* publish + invalidate */\n    ...\n    priv-\u0026gt;stats_agent.agent = agent;          /* too late */\n    INIT_DELAYED_WORK(\u0026amp;priv-\u0026gt;stats_agent.work, ...); /* too late */\n\nIf the asynchronous control path runs before the two assignments\nabove, it can:\n\n  - Operate on an uninitialized delayed_work whose timer.function is\n    NULL. queue_delayed_work() calls add_timer() unconditionally, so\n    when the timer expires the timer softirq invokes a NULL function\n    pointer.\n  - Re-initialize the timer later through INIT_DELAYED_WORK() while\n    the timer is already enqueued in the timer wheel, corrupting the\n    hlist (entry.pprev cleared while the previous bucket node still\n    points at this entry).\n  - When the worker eventually runs, mlx5e_hv_vhca_stats_work() reads\n    sagent-\u0026gt;agent (NULL) and dereferences it inside\n    mlx5_hv_vhca_agent_write().\n\nFix this by:\n\n  - Initializing priv-\u0026gt;stats_agent.work before invoking\n    mlx5_hv_vhca_agent_create(), so the work is always in a valid\n    state when the control callback observes it.\n  - Adding a struct mlx5_hv_vhca_agent **ctx_update out-parameter\n    to mlx5_hv_vhca_agent_create(). The helper writes the agent\n    pointer to *ctx_update before publishing into hv_vhca-\u0026gt;agents[]\n    and triggering the agents_update flow, so any callback\n    subsequently invoked from that flow already sees a valid\n    priv-\u0026gt;stats_agent.agent. This avoids having the control\n    callback participate in agent initialization.\n\nWhile at it, access priv-\u0026gt;stats_agent.agent with\nREAD_ONCE()/WRITE_ONCE() for the cross-CPU access with the worker, and\nclear priv-\u0026gt;stats_agent.buf on the agent_create() failure path.(CVE-2026-72342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbridge: stp: Fix a potential use-after-free when deleting a bridge\n\nThe three STP timers are not supposed to be armed while the bridge is\nadministratively down. They are synchronously deactivated when the\nbridge is put administratively down and the various call sites check for\n\u0026apos;IFF_UP\u0026apos; before arming them.\n\nThis check is missing from br_topology_change_detection() and it is\npossible to engineer a situation in which the topology change timer is\narmed while the bridge is administratively down, resulting in a\nuse-after-free [1] when the bridge is deleted.\n\nFix by adding the missing check and for good measures synchronously\nshutdown the three timers when the bridge is deleted.\n\n[1]\nODEBUG: free active (active state 0) object: ffff88811662b9b0 object type: timer_list hint: br_topology_change_timer_expired (net/bridge/br_stp_timer.c:120)\nWARNING: lib/debugobjects.c:629 at debug_print_object+0x1bc/0x450, CPU#9: ip/359(CVE-2026-72389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nseg6: validate SRH length before reading fixed fields\n\nseg6_validate_srh() reads fixed SRH fields such as srh-\u0026gt;type and\nsrh-\u0026gt;hdrlen before checking that the supplied length covers the fixed\nstruct ipv6_sr_hdr fields.\n\nThe BPF SEG6 encap path reaches this with a BPF program-supplied pointer\nand length: bpf_lwt_push_encap() and the SEG6 local BPF END_B6 and\nEND_B6_ENCAP actions call bpf_push_seg6_encap(), which forwards the\nlength to seg6_validate_srh() with no minimum-size guard.  A 2-byte SEG6\nencap header can therefore make the validator read srh-\u0026gt;type at offset 2\nbeyond the caller-supplied buffer.\n\nReject lengths shorter than the fixed SRH at the top of\nseg6_validate_srh(), before any field is read.  This fixes the BPF helper\npath and keeps the common validator robust.(CVE-2026-72400)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()\n\nResetting all VFs causes resource leak on VFs with FDIR filters\nenabled as CTRL VSIs are only invalidated and not freed. Fix by using\nice_vf_ctrl_vsi_release() instead of ice_vf_ctrl_invalidate_vsi() which\naligns behavior with the ice_reset_vf() function.\n\nReproduction:\n  echo 1 \u0026gt; /sys/class/net/$pf/device/sriov_numvfs\n  ethtool -N $vf flow-type ether proto 0x9000 action 0\n  echo 1 \u0026gt; /sys/class/net/$pf/device/reset(CVE-2026-72425)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: validate selector family and prefixlen during match\n\nsyzbot reported a shift-out-of-bounds in xfrm_selector_match()\ndue to AF_UNSPEC selector with large prefixlen (e.g. 128) matched\nagainst IPv4 flow (when XFRM_STATE_AF_UNSPEC is set).\n\nFix this by:\n\n- Rejecting mismatched families in xfrm_selector_match.\n- Returning false in addr4_match if prefixlen \u0026gt; 32.\n- Returning false in addr_match if prefixlen \u0026gt; 128 (prevents overflow).(CVE-2026-72450)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: aa_label_alloc use aa_label_free on alloc failure\n\naa_label_alloc() allocates a secid before allocating or taking the label\nproxy. If the later proxy step fails, the error path only freed the label\nmemory, leaking any resources initialized by aa_label_init().\n\nUse aa_label_free() on the failure path so partially initialized labels\nrelease their secid and other label resources before the backing memory is\nfreed.(CVE-2026-72459)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: check label build before no_new_privs test\n\naa_change_profile() builds a replacement label with\nfn_label_build_in_scope() before the no_new_privs subset check. The build\nhelper can fail and return NULL or an ERR_PTR, but the result was passed\nto aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL()\ncheck.\n\nReuse the existing target-label build failure handling immediately after\nthe build. This preserves the current audit handling while preventing the\nsubset helper from dereferencing an invalid label.(CVE-2026-72460)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: Repost Receive buffers for malformed replies\n\nrpcrdma_wc_receive() decrements the transport\u0026apos;s Receive count for\nevery completion before it dispatches a successful Receive to\nrpcrdma_reply_handler(). The handler must post a replacement\nReceive WR before returning unless ownership of the rep has moved\nelsewhere, as on the backchannel path.\n\nCommit 2ae50ad68cd7 (\u0026quot;xprtrdma: Close window between waking RPC\nsenders and posting Receives\u0026quot;) moved the Receive refill out of\nrpcrdma_wc_receive(), where it had run ahead of every reply, into\nrpcrdma_reply_handler() so that the responder\u0026apos;s credit grant could\nbe parsed before reposting. The bad-version and short-reply exits\nnever reach that refill: they recycle the rep and return without\ncalling rpcrdma_post_recvs().\n\nA remote peer can therefore drain the client\u0026apos;s posted Receive\nqueue by sending a sustained stream of replies that are shorter\nthan the fixed transport header or that carry an unrecognized\nRPC/RDMA version. Each such reply consumes one posted Receive\nwithout replacing it. Once the queue empties, the peer\u0026apos;s next\nSend finds no posted Receive and the transport stalls until\nreconnect.\n\nRoute both malformed-reply exits through the shared repost tail\nafter recycling the rep, refilling against buf-\u0026gt;rb_credits, the\nmost recent accepted credit grant. Neither exit updates the\ncongestion window, so RPCs admitted under the previous grant\nremain in flight awaiting replies. A smaller refill target would\nlet a stream of malformed replies ratchet the posted Receive count\ndown to the batch floor while the congestion window still admits\nrb_credits RPCs; a burst of valid replies to those RPCs could then\noverrun the posted Receives, and because the client connects with\nrnr_retry_count of zero, a single RNR NAK terminates the\nconnection. Refilling against rb_credits also restores the target\nthat applied to malformed replies before commit 2ae50ad68cd7\n(\u0026quot;xprtrdma: Close window between waking RPC senders and posting\nReceives\u0026quot;) when rpcrdma_post_recvs() computed it from rb_credits\ninternally. rb_credits is at least one from connection\nestablishment onward, so the repost path always keeps Receives\nposted.(CVE-2026-72464)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: Fix bcall rep leak and unbounded peek\n\nrpcrdma_is_bcall() decodes a reply\u0026apos;s first words to decide whether\nthe frame is a backchannel call. Two issues in that decode path\nlet a short or malformed reply leak the receive buffer and drain\nthe Receive queue.\n\nFirst, the speculative peek\n\n    p = xdr_inline_decode(xdr, 0);\n    /* five p++ reads follow */\n\nasks xdr_inline_decode() for zero bytes, which returns xdr-\u0026gt;p\nwithout consulting xdr-\u0026gt;end. The five subsequent __be32 reads can\nthen walk up to 20 bytes past the wire payload into stale regbuf\ncontents and misclassify the reply as a backchannel call.\n\nSecond, after the post-peek\n\n    p = xdr_inline_decode(xdr, 3 * sizeof(*p));\n    if (unlikely(!p))\n            return true;\n\nthe short-header arm returns true without calling\nrpcrdma_bc_receive_call(). The contract with the caller is that a\ntrue return transfers ownership of rep to the backchannel path:\n\n    rpcrdma_reply_handler()\n      if (rpcrdma_is_bcall(r_xprt, rep))\n              return;        /* bare return, skips out_post */\n      ...\n    out_post:\n      rpcrdma_post_recvs(r_xprt, credits + ...);\n\nBecause rpcrdma_bc_receive_call() never ran, no one took rep, but\nrpcrdma_reply_handler still bare-returns past rpcrdma_rep_put()\nand rpcrdma_post_recvs(). The rep, with its persistently\nDMA-mapped receive buffer, is orphaned on rb_all_reps and freed\nonly at transport teardown. This completion reposts nothing, so\nits slot is reclaimed only when a later forward-channel reply\nreaches out_post and rpcrdma_post_recvs() allocates a fresh rep to\nbackfill; absent that traffic the Receive queue drains and the\npeer\u0026apos;s Sends draw RNR NAKs.\n\nFix by consulting xdr-\u0026gt;end after the zero-length peek so the five\n__be32 reads cannot run unless 20 bytes of wire payload remain. A\nbyte-precise comparison against xdr-\u0026gt;end is required because a\nnon-4-aligned receive rounds the stream\u0026apos;s word count up past the\ntrue payload. Also return false from the short-header arm so the\nreply falls through the normal out_norqst cleanup chain\n(rpcrdma_rep_put() plus rpcrdma_post_recvs()).(CVE-2026-72466)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: Decouple req recycling from RPC completion\n\nrl_kref formerly served two distinct lifetimes through a single\nrefcount: it gated when a Reply could wake its RPC task, and it\ngated when an rpcrdma_req could return to its free pool. The\nmarshal path took the Send-side reference only when SGEs needed\nDMA-unmap (sc_unmap_count \u0026gt; 0), which made a Send carrying only\npre-registered buffers an exception: the Reply handler dropped\nrl_kref from 1 to 0 and freed the req while the HCA might still\nbe DMA-reading from its send buffer.\n\nGive rl_kref a narrower job. The RPC layer takes one reference\nwhen slot allocation hands a req out. rpcrdma_prepare_send_sges()\ntakes a Send-side reference unconditionally after WR preparation\nsucceeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop\nthe RPC-layer reference; rpcrdma_sendctx_unmap() drops the\nSend-side reference. The req returns to its free pool only after\nboth owners have signed off.\n\nThe existing kref_init(\u0026amp;req-\u0026gt;rl_kref) call in\nrpcrdma_prepare_send_sges() is removed. Initialization moves to\nthe slot-allocation paths (xprt_rdma_alloc_slot and\nrpcrdma_bc_rqst_get), and the release callback re-arms rl_kref\nbefore the req returns to a free pool. A re-init in the marshal\npath would discard the RPC-layer reference that already exists\non entry.\n\nThree invariants follow:\n\n  - Any rpcrdma_req held by an rpc_rqst has rl_kref \u0026gt;= 1.\n    xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the\n    backlog-wake branch in xprt_rdma_alloc_slot() each kref_init\n    rl_kref before publishing the req. Without this invariant,\n    an RPC task that aborts between slot allocation and marshal\n    (gss_refresh failure or signal during call_connect, for\n    example) would drive xprt_release() -\u0026gt;\n    xprt_rdma_free_slot() -\u0026gt; kref_put against a refcount of\n    zero, saturating refcount_t and stranding the slot.\n\n  - The Send-side reference is taken only after WR prep\n    succeeds. A mapping failure in rpcrdma_prepare_send_sges()\n    runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx\n    and clears sc_req without touching rl_kref. The sendctx\n    ring walks in rpcrdma_sendctx_put_locked() and\n    rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL,\n    so a burst of -EIO marshal failures cannot hold reqs off\n    rb_send_bufs.\n\n  - The release callback re-arms rl_kref so the next consumer\n    enters with the invariant satisfied.\n\nReplies now complete the RPC directly. rpcrdma_reply_handler()\ncalls rpcrdma_complete_rqst() in place of kref_put on the\nnon-LocalInv branch. The LocalInv branch already completes the\nRPC from frwr_unmap_async() and is unaffected.\n\nBecause Send-side references can now outlive RPC completion,\nconnection teardown drains sendctx entries whose unsignaled\nSends never had a later signaled completion to walk the ring.\nrpcrdma_sendctxs_destroy() walks the active range and runs\nrpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req\nbefore the request buffers are reset, and is moved ahead of\nrpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs\nare still in their pre-reset state when the Send-side refs are\nreleased.\n\nThe drain creates a teardown-ordering hazard on the backchannel\npath. With the new lifetime, releasing a bc_prealloc req from\nrpcrdma_req_release() re-adds it to bc_pa_list. The disconnect\nin xprt_rdma_destroy() runs after xprt_destroy_backchannel() has\nalready emptied bc_pa_list, so the drained reqs would otherwise\nleak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0)\na second time after the disconnect to reclaim them.(CVE-2026-72473)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npower: supply: core: fix supplied_from allocations\n\nIf dts property power-supplies has multiple values, then accessing to\npsy-\u0026gt;supplied_from[i-1] in __power_supply_populate_supplied_from will\noverrun supplied_from array.(CVE-2026-74271)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: require net admin for TIPCv2 netlink mutators\n\nTIPCv2 registers mutating generic-netlink operations without admin\npermission flags. Generic netlink only checks CAP_NET_ADMIN when an\noperation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local\nunprivileged process can currently change TIPC state through commands\nsuch as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and\nbearer enable/disable.\n\nThe legacy TIPC netlink API already checks netlink_net_capable(...,\nCAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators\nthe equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which\nmaps to the same namespace-aware CAP_NET_ADMIN check that\nnetlink_net_capable() performs, so the behaviour matches the legacy\npath and keeps working for CAP_NET_ADMIN holders in a non-initial user\nnamespace (containers).\n\nA QEMU/KASAN repro run as uid/gid 65534 with zero effective\ncapabilities previously succeeded in changing the network id and node\nidentity, setting and flushing key material, and enabling/disabling a\nUDP bearer. With this patch applied the same operations fail with\n-EPERM.(CVE-2026-74283)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate embedded address parameter length\n\nsctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP,\nand SET_PRIMARY parameters against a fixed minimum size of sizeof(struct\nsctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer\nparameter is large enough to contain an embedded address parameter header,\nbut does not verify that the embedded address parameter\u0026apos;s declared length\nfits within the bounds of the outer parameter.\n\nLater, sctp_process_param() and sctp_process_asconf_param() extract the\nembedded address parameter and pass it to af-\u0026gt;from_addr_param(), which uses\nthe address parameter length to parse the variable-length address payload.\nA malformed peer can therefore advertise an embedded address parameter\nlength that exceeds the remaining bytes in the enclosing parameter.\n\nValidate that addr_param-\u0026gt;p.length does not exceed the space available\nafter the sctp_addip_param header before processing the embedded address\nparameter. Reject malformed parameters when the embedded address length\nextends beyond the enclosing parameter bounds.\n\nThis prevents out-of-bounds reads when parsing malformed parameters carried\nin INIT or ASCONF processing paths.(CVE-2026-74287)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Tighten cgroup storage cookie checks for prog arrays\n\nThe fix in commit abad3d0bad72 (\u0026quot;bpf: Fix oob access in cgroup local\nstorage\u0026quot;) is still incomplete. The prog-array compatibility check\ntreats a program with no cgroup storage as compatible with any stored\nstorage cookie. This allows a storage-less program to bridge a tail\ncall chain between an entry program and a storage-using callee even\nthough cgroup local storage at runtime still follows the caller\u0026apos;s\ncontext, that is, A -\u0026gt; B(no storage) -\u0026gt; C(storage) path.\n\nRequiring exact cookie equality would break the legitimate case of a\nstorage-less leaf program being tail called from a storage-using one.\nInstead, only accept a zero storage cookie if the program cannot\nperform tail calls itself. This keeps A -\u0026gt; B(no storage) working\nwhile rejecting the A -\u0026gt; B(no storage) -\u0026gt; C(storage) bridge.(CVE-2026-74305)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Copy WQE to local buffer in non-SRQ receive path\n\nFor non-SRQ QPs, the responder reads WQE fields directly from the\nshared queue buffer mapped into userspace. This allows a malicious\nuser to modify fields like num_sge or sge entries while the kernel\nis processing the WQE, leading to out-of-bounds reads in\nrxe_resp_check_length() and copy_data().\n\nIntroduce get_recv_wqe() that validates num_sge and copies the WQE\nto a kernel-local buffer before processing, matching the approach\nalready used for SRQ WQEs in get_srq_wqe(). The srq_wqe buffer is\nreused since SRQ and non-SRQ paths are mutually exclusive per QP.(CVE-2026-74377)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe\n\nget_srq_wqe() reads wqe-\u0026gt;dma.num_sge from the shared receive queue\nbuffer, which is mapped into userspace. It validates num_sge against\nmax_sge, but then re-reads the same field to calculate the memcpy\nsize. A concurrent userspace thread can modify num_sge between\nvalidation and use, causing a heap buffer overflow when copying the\nWQE into qp-\u0026gt;resp.srq_wqe.\n\nRead num_sge into a local variable and use it for both the bounds\ncheck and the size calculation.(CVE-2026-74378)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/srpt: fix integer overflow in immediate data length check\n\nimm_buf-\u0026gt;len is a user-controlled uint32_t received from the network.\nAdding it to imm_data_offset without overflow checking allows a\nmalicious initiator to send len=0xFFFFFFFF, causing req_size to wrap\naround to a small value, bypassing the bounds check, and subsequently\npassing a ~4GB length to sg_init_one().\n\nUse check_add_overflow() to detect wrapping before the comparison.(CVE-2026-74394)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier\n\nmlx5_ib_alloc_transport_domain() allocates a transport domain and then\nmay fail in mlx5_ib_enable_lb(). In that case, the allocated TD is leaked.\n\nFix this by deallocating the TD when mlx5_ib_enable_lb() returns an\nerror. Also return 0 explicitly in the no-loopback-capability success\nbranch, and move dev-\u0026gt;lb.mutex initialization to mlx5_ib_stage_init_init().(CVE-2026-74397)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD\n\naddrconf_dad_failure() transitions ifp-\u0026gt;state from DAD to POSTDAD\nvia addrconf_dad_end(), which drops ifp-\u0026gt;lock on return.  The lock\nis re-acquired after net_info_ratelimited().  A concurrent\nipv6_del_addr() can take the lock in that window, set ifp-\u0026gt;state\nto DEAD and run list_del_rcu(\u0026amp;ifp-\u0026gt;if_list).\n\naddrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad:\nand schedules a new dad_work.  The work calls ipv6_del_addr()\nagain, hitting the already-poisoned list entry:\n\n  general protection fault: 0000 [#1] SMP NOPTI\n  CPU: 4 PID: 217 Comm: kworker/4:1\n  Workqueue: ipv6_addrconf addrconf_dad_work\n  RIP: 0010:ipv6_del_addr+0xe9/0x280\n  RAX: dead000000000122\n  Call Trace:\n   addrconf_dad_stop+0x113/0x140\n   addrconf_dad_work+0x28c/0x430\n   process_one_work+0x1eb/0x3b0\n   worker_thread+0x4d/0x400\n   kthread+0x104/0x140\n   ret_from_fork+0x35/0x40\n\nFold the addrconf_dad_end() logic into addrconf_dad_failure() under\na single ifp-\u0026gt;lock critical section.  The STABLE_PRIVACY branch\ntemporarily drops ifp-\u0026gt;lock around address regeneration, so at\nlock_errdad: verify the state is still POSTDAD before transitioning\nto ERRDAD; bail out otherwise to avoid overwriting a state set by\nanother path while the lock was released.(CVE-2026-74398)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().\n\nudp_tunnel_sock_release() could set sk-\u0026gt;sk_user_data to NULL\nwhile vxlan_gro_prepare_receive() is running.\n\nLet\u0026apos;s check if rcu_dereference_sk_user_data() is NULL after\nskb_gro_remcsum_init().(CVE-2026-74406)",
  "id": "OESA-2026-3703",
  "modified": "2026-09-05T15:04:07Z",
  "published": "2026-09-05T15:04:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3703"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37979"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38736"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43078"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46028"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63912"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68476"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68477"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72021"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72049"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72052"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72053"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72054"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72061"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72072"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72129"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72135"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72136"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72157"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72172"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72217"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72221"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72222"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72235"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72282"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72310"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72316"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72317"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72318"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72319"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72330"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72339"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72342"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72389"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72400"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72425"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72450"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72459"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72460"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72464"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72466"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72473"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74271"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74283"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74287"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74305"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74377"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74378"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74394"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74397"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74398"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74406"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2025-37979",
    "CVE-2025-38736",
    "CVE-2026-43078",
    "CVE-2026-46028",
    "CVE-2026-63912",
    "CVE-2026-68476",
    "CVE-2026-68477",
    "CVE-2026-72021",
    "CVE-2026-72049",
    "CVE-2026-72052",
    "CVE-2026-72053",
    "CVE-2026-72054",
    "CVE-2026-72061",
    "CVE-2026-72072",
    "CVE-2026-72129",
    "CVE-2026-72135",
    "CVE-2026-72136",
    "CVE-2026-72157",
    "CVE-2026-72172",
    "CVE-2026-72217",
    "CVE-2026-72221",
    "CVE-2026-72222",
    "CVE-2026-72235",
    "CVE-2026-72282",
    "CVE-2026-72310",
    "CVE-2026-72316",
    "CVE-2026-72317",
    "CVE-2026-72318",
    "CVE-2026-72319",
    "CVE-2026-72330",
    "CVE-2026-72339",
    "CVE-2026-72342",
    "CVE-2026-72389",
    "CVE-2026-72400",
    "CVE-2026-72425",
    "CVE-2026-72450",
    "CVE-2026-72459",
    "CVE-2026-72460",
    "CVE-2026-72464",
    "CVE-2026-72466",
    "CVE-2026-72473",
    "CVE-2026-74271",
    "CVE-2026-74283",
    "CVE-2026-74287",
    "CVE-2026-74305",
    "CVE-2026-74377",
    "CVE-2026-74378",
    "CVE-2026-74394",
    "CVE-2026-74397",
    "CVE-2026-74398",
    "CVE-2026-74406"
  ]
}

OESA-2026-3704 (CVE-2025-71112)

Vulnerability from osv_openeuler – Published: 2026-09-05 15:04 – Updated: 2026-09-05 15:04 – Source website

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net: hns3: add VLAN id validation before using

Currently, the VLAN id may be used without validation when receive a VLAN configuration mailbox from VF. The length of vlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may cause out-of-bounds memory access once the VLAN id is bigger than or equal to VLAN_N_VID.

Therefore, VLAN id needs to be checked to ensure it is within the range of VLAN_N_VID.(CVE-2025-71112)

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

ext4: fix string copying in parse_apply_sb_mount_options()

strscpy_pad() can't be used to copy a non-NUL-term string into a NUL-term string of possibly bigger size. Commit 0efc5990bca5 ("string.h: Introduce memtostr() and memtostr_pad()") provides additional information in that regard. So if this happens, the following warning is observed:

strnlen: detected buffer overflow: 65 byte read of buffer size 64 WARNING: CPU: 0 PID: 28655 at lib/string_helpers.c:1032 __fortify_report+0x96/0xc0 lib/string_helpers.c:1032 Modules linked in: CPU: 0 UID: 0 PID: 28655 Comm: syz-executor.3 Not tainted 6.12.54-syzkaller-00144-g5f0270f1ba00 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__fortify_report+0x96/0xc0 lib/string_helpers.c:1032 Call Trace: <TASK> __fortify_panic+0x1f/0x30 lib/string_helpers.c:1039 strnlen include/linux/fortify-string.h:235 [inline] sized_strscpy include/linux/fortify-string.h:309 [inline] parse_apply_sb_mount_options fs/ext4/super.c:2504 [inline] __ext4_fill_super fs/ext4/super.c:5261 [inline] ext4_fill_super+0x3c35/0xad00 fs/ext4/super.c:5706 get_tree_bdev_flags+0x387/0x620 fs/super.c:1636 vfs_get_tree+0x93/0x380 fs/super.c:1814 do_new_mount fs/namespace.c:3553 [inline] path_mount+0x6ae/0x1f70 fs/namespace.c:3880 do_mount fs/namespace.c:3893 [inline] __do_sys_mount fs/namespace.c:4103 [inline] __se_sys_mount fs/namespace.c:4080 [inline] __x64_sys_mount+0x280/0x300 fs/namespace.c:4080 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x64/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Since userspace is expected to provide s_mount_opts field to be at most 63 characters long with the ending byte being NUL-term, use a 64-byte buffer which matches the size of s_mount_opts, so that strscpy_pad() does its job properly. Return with error if the user still managed to provide a non-NUL-term string here.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-71123)

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

RDMA/umad: Reject negative data_len in ib_umad_write

ib_umad_write computes data_len from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, data_len can become negative and reach ib_create_send_mad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in alloc_send_rmpp_list().

Add an explicit check to reject negative data_len before creating the send buffer.

KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102 [ 211.365867] ib_create_send_mad+0xa01/0x11b0 [ 211.365887] ib_umad_write+0x853/0x1c80(CVE-2026-23243)

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

nvme: fix memory allocation in nvme_pr_read_keys()

nvme_pr_read_keys() takes num_keys from userspace and uses it to calculate the allocation size for rse via struct_size(). The upper limit is PR_KEYS_MAX (64K).

A malicious or buggy userspace can pass a large num_keys value that results in a 4MB allocation attempt at most, causing a warning in the page allocator when the order exceeds MAX_PAGE_ORDER.

To fix this, use kvzalloc() instead of kzalloc().

This bug has the same reasoning and fix with the patch below: https://lore.kernel.org/linux-block/(CVE-2026-23244)

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

media: dvb-core: fix wrong reinitialization of ringbuffer on reopen

dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty.

Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}.

The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions.

Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock.(CVE-2026-23253)

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

apparmor: fix unprivileged local user can do privileged policy management

An unprivileged local user can load, replace, and remove profiles by opening the apparmorfs interfaces, via a confused deputy attack, by passing the opened fd to a privileged process, and getting the privileged process to write to the interface.

This does require a privileged target that can be manipulated to do the write for the unprivileged process, but once such access is achieved full policy management is possible and all the possible implications that implies: removing confinement, DoS of system or target applications by denying all execution, by-passing the unprivileged user namespace restriction, to exploiting kernel bugs for a local privilege escalation.

The policy management interface can not have its permissions simply changed from 0666 to 0600 because non-root processes need to be able to load policy to different policy namespaces.

Instead ensure the task writing the interface has privileges that are a subset of the task that opened the interface. This is already done via policy for confined processes, but unconfined can delegate access to the opened fd, by-passing the usual policy check.(CVE-2026-23268)

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

perf: Fix __perf_event_overflow() vs perf_remove_from_context() race

Make sure that __perf_event_overflow() runs with IRQs disabled for all possible callchains. Specifically the software events can end up running it with only preemption disabled.

This opens up a race vs perf_event_exit_event() and friends that will go and free various things the overflow path expects to be present, like the BPF program.(CVE-2026-23271)

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

drm/vmwgfx: Return the correct value in vmw_translate_ptr functions

Before the referenced fixes these functions used a lookup function that returned a pointer. This was changed to another lookup function that returned an error code with the pointer becoming an out parameter.

The error path when the lookup failed was not changed to reflect this change and the code continued to return the PTR_ERR of the now uninitialized pointer. This could cause the vmw_translate_ptr functions to return success when they actually failed causing further uninitialized and OOB accesses.(CVE-2026-23317)

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

bpf: Fix a UAF issue in bpf_trampoline_link_cgroup_shim

The root cause of this bug is that when 'bpf_link_put' reduces the refcount of 'shim_link->link.link' to zero, the resource is considered released but may still be referenced via 'tr->progs_hlist' in 'cgroup_shim_find'. The actual cleanup of 'tr->progs_hlist' in 'bpf_shim_tramp_link_release' is deferred. During this window, another process can cause a use-after-free via 'bpf_trampoline_link_cgroup_shim'.

Based on Martin KaFai Lau's suggestions, I have created a simple patch.

To fix this: Add an atomic non-zero check in 'bpf_trampoline_link_cgroup_shim'. Only increment the refcount if it is not already zero.

Testing: I verified the fix by adding a delay in 'bpf_shim_tramp_link_release' to make the bug easier to trigger:

static void bpf_shim_tramp_link_release(struct bpf_link link) { / ... */ if (!shim_link->trampoline) return;

msleep(100); WARN_ON_ONCE(bpf_trampoline_unlink_prog(&shim_link->link, shim_link->trampoline, NULL)); bpf_trampoline_put(shim_link->trampoline); }

Before the patch, running a PoC easily reproduced the crash(almost 100%) with a call trace similar to KaiyanM's report. After the patch, the bug no longer occurs even after millions of iterations.(CVE-2026-23319)

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

bpf: Fix stack-out-of-bounds write in devmap

get_upper_ifindexes() iterates over all upper devices and writes their indices into an array without checking bounds.

Also the callers assume that the max number of upper devices is MAX_NEST_DEV and allocate excluded_devices[1+MAX_NEST_DEV] on the stack, but that assumption is not correct and the number of upper devices could be larger than MAX_NEST_DEV (e.g., many macvlans), causing a stack-out-of-bounds write.

Add a max parameter to get_upper_ifindexes() to avoid the issue. When there are too many upper devices, return -EOVERFLOW and abort the redirect.

To reproduce, create more than MAX_NEST_DEV(8) macvlans on a device with an XDP program attached using BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS. Then send a packet to the device to trigger the XDP redirect path.(CVE-2026-23359)

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

bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing

struct bpf_plt contains a u64 target field. Currently, the BPF JIT allocator requests an alignment of 4 bytes (sizeof(u32)) for the JIT buffer.

Because the base address of the JIT buffer can be 4-byte aligned (e.g., ending in 0x4 or 0xc), the relative padding logic in build_plt() fails to ensure that target lands on an 8-byte boundary.

This leads to two issues: 1. UBSAN reports misaligned-access warnings when dereferencing the structure. 2. More critically, target is updated concurrently via WRITE_ONCE() in bpf_arch_text_poke() while the JIT'd code executes ldr. On arm64, 64-bit loads/stores are only guaranteed to be single-copy atomic if they are 64-bit aligned. A misaligned target risks a torn read, causing the JIT to jump to a corrupted address.

Fix this by increasing the allocation alignment requirement to 8 bytes (sizeof(u64)) in bpf_jit_binary_pack_alloc(). This anchors the base of the JIT buffer to an 8-byte boundary, allowing the relative padding math in build_plt() to correctly align the target field.(CVE-2026-23383)

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

Squashfs: check metadata block offset is within range

Syzkaller reports a "general protection fault in squashfs_copy_data"

This is ultimately caused by a corrupted index look-up table, which produces a negative metadata block offset.

This is subsequently passed to squashfs_copy_data (via squashfs_read_metadata) where the negative offset causes an out of bounds access.

The fix is to check that the offset is within range in squashfs_read_metadata. This will trap this and other cases.(CVE-2026-23388)

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

crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl

When page reassignment was added to af_alg_pull_tsgl the original loop wasn't updated so it may try to reassign one more page than necessary.

Add the check to the reassignment so that this does not happen.

Also update the comment which still refers to the obsolete offset argument.(CVE-2026-43078)

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

crypto: algif_aead - snapshot IV for async AEAD requests

Snapshot the IV into per-request storage when preparing the AEAD request, so in-flight operations no longer depend on mutable socket state.(CVE-2026-46028)

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

sched/fair: Clear rel_deadline when initializing forked entities

A yield-triggered crash can happen when a newly forked sched_entity enters the fair class with se->rel_deadline unexpectedly set.

The failing sequence is:

A task is forked while se->rel_deadline is still set.
__sched_fork() initializes vruntime, vlag and other sched_entity state, but does not clear rel_deadline.
On the first enqueue, enqueue_entity() calls place_entity().
Because se->rel_deadline is set, place_entity() treats se->deadline as a relative deadline and converts it to an absolute deadline by adding the current vruntime.
However, the forked entity's deadline is not a valid inherited relative deadline for this new scheduling instance, so the conversion produces an abnormally large deadline.
If the task later calls sched_yield(), yield_task_fair() advances se->vruntime to se->deadline.
The inflated vruntime is then used by the following enqueue path, where the vruntime-derived key can overflow when multiplied by the entity weight.
This corrupts cfs_rq->sum_w_vruntime, breaks EEVDF eligibility calculation, and can eventually make all entities appear ineligible. pick_next_entity() may then return NULL unexpectedly, leading to a later NULL dereference.

A captured trace shows the effect clearly. Before yield, the entity's vruntime was around:

9834017729983308

After yield_task_fair() executed:

se->vruntime = se->deadline

the vruntime jumped to:

19668035460670230

and the deadline was later advanced further to:

19668035463470230

This shows that the deadline had already become abnormally large before yield_task_fair() copied it into vruntime.

rel_deadline is only meaningful when se->deadline really carries a relative deadline that still needs to be placed against vruntime. A freshly forked sched_entity should not inherit or retain this state. Clear se->rel_deadline in __sched_fork(), together with the other sched_entity runtime state, so that the first enqueue does not interpret the new entity's deadline as a stale relative deadline.(CVE-2026-52980)

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

crypto: hisilicon/sec2 - prevent req used-after-free for sec

During packet transmission, if the system is under heavy load, the hardware might complete processing the packet and free the request memory (req) before the transmission function finishes. If the software subsequently accesses this req, a use-after-free error will occur. The qp_ctx memory exists throughout the packet sending process, so replace the req with the qp_ctx.(CVE-2026-53055)

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

sctp: validate cached peer INIT chunk length in COOKIE_ECHO processing

When a listening SCTP server processes a COOKIE_ECHO chunk, the cached peer INIT chunk embedded after the cookie is parsed and its parameters are later walked by sctp_process_init() using sctp_walk_params().

However, the chunk header length of this cached INIT chunk was not validated against the remaining buffer in the COOKIE_ECHO payload. If the length field is inflated, the parameter walk can run beyond the actual received data, leading to out-of-bounds reads and potential memory corruption during later parameter handling (e.g. STATE_COOKIE processing and kmemdup() copies).

Add a bounds check in sctp_unpack_cookie() to ensure the cached INIT chunk length does not exceed the available data in the COOKIE_ECHO buffer before it is used.(CVE-2026-53246)

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

serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails

dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard.

Unregister the port on the clk_notifier_register() error path.(CVE-2026-53384)

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

pNFS: Fix use-after-free in pnfs_update_layout()

When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields.

Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).(CVE-2026-63800)

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

net: skmsg: preserve sg.copy across SG transforms

The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages.

Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache.

Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.(CVE-2026-63830)

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

scsi: target: iscsi: Validate CHAP_R length before base64 decode

chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output.

chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the "0b" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes.

The length check at line 344 fires after the write has already happened.

The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder.

Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged.

The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.(CVE-2026-63886)

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

scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf

iscsi_encode_text_output() concatenates "key=value\0" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity:

*length += sprintf(output_buf, &quot;%s=%s&quot;, er-&gt;key, er-&gt;value);
*length += 1;
output_buf = textbuf + *length;

The 8192-byte ceiling at iscsi_target_check_login_request() bounds the input Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte "a=b\0" pairs, each unknown key expanding to a 16-byte "a=NotUnderstood\0" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab.

The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)(CVE-2026-63887)

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

scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd()

Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1"):

1) DataDigest CRC buffer overread (4 bytes past text_in).

text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf():

   if (conn-&gt;conn_ops-&gt;DataDigest) {
           ...
           rx_size += ISCSI_CRC_LEN;
   }
   ...
   if (conn-&gt;conn_ops-&gt;DataDigest) {
           data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL);

iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C.

Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc().

2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop.

On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap:

           kfree(text_in);
           return 0;

cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does

   kfree(cmd-&gt;text_in_ptr);
   cmd-&gt;text_in_ptr = NULL;

freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives.

On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats:

   BUG: KASAN: double-free in iscsit_setup_text_cmd+0x??
   BUG: KASAN: double-free in iscsit_release_cmd+0x??

showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist.

Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together.

Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.(CVE-2026-63888)

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

scsi: scsi_transport_fc: Widen FPIN pname walker counter to u32

An adjacent Fibre Channel fabric actor that can deliver an FPIN ELS frame to an lpfc or qla2xxx Linux initiator can trigger a non-return in the generic FC transport. This is not a local userspace or IP network path; the attacker must be able to inject fabric traffic, for example as a compromised switch or fabric controller, or as a same-zone N_Port on a fabric that permits source spoofing.

The Link-Integrity and Peer-Congestion FPIN walkers used a u8 loop counter against the 32-bit on-wire pname_count field, and did not bound pname_count by the descriptor body already validated by the TLV walker. A pname_count of 256 therefore wraps the counter and keeps the loop condition true indefinitely.

Factor the shared pname_list[] walk into one helper, widen the counter to u32, and clamp pname_count against the entries that fit in the descriptor body before iterating.(CVE-2026-63889)

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

thunderbolt: property: Cap recursion depth in __tb_property_parse_dir()

A DIRECTORY entry's value field is used as the dir_offset for a recursive call into __tb_property_parse_dir() with no depth counter. A crafted peer that chains DIRECTORY entries into a back-reference loop drives the parser until the kernel stack is exhausted and the guard page fires. Any untrusted XDomain peer (cable, dock, in-line inspector, adjacent host) that reaches the PROPERTIES_REQUEST control-plane exchange can trigger this without authentication.

Thread a depth counter through tb_property_parse() and __tb_property_parse_dir(), and reject blocks that exceed TB_PROPERTY_MAX_DEPTH = 8. That is comfortably larger than any observed legitimate XDomain layout.

Operators who do not need XDomain host-to-host discovery can disable the path entirely with thunderbolt.xdomain=0 on the kernel command line.(CVE-2026-63891)

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

USB: serial: mct_u232: fix memory corruption with small endpoint

The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint.

Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.(CVE-2026-63898)

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

USB: serial: mxuport: fix memory corruption with small endpoint

Make sure that the bulk-out endpoint max packet size is at least eight bytes to avoid user-controlled slab corruption should a malicious device report a smaller size.(CVE-2026-63899)

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

USB: serial: digi_acceleport: fix memory corruption with small endpoints

Add the missing bulk-out buffer size sanity checks to avoid out-of-bounds memory accesses or slab corruption should a malicious device report smaller buffers than expected.(CVE-2026-63901)

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

xfrm: esp: restore combined single-frag length gate

Restore this combined-length page gate for both IPv4 and IPv6.(CVE-2026-63912)

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

ip6: vti: Use ip6_tnl.net in vti6_changelink().

ip netns add ns1 ip netns add ns2 ip -n ns1 link add vti6_test type vti6 remote ::1 local ::2 key 7 ip -n ns1 link set vti6_test netns ns2 ip -n ns2 link set vti6_test type vti6 remote ::3 local ::4 key 9 ip netns del ns2 ip netns del ns1 [ 132.495484] ------------[ cut here ]------------ [ 132.497609] kernel BUG at net/core/dev.c:12376!

Commit 61220ab34948 ("vti6: Enable namespace changing") dropped NETIF_F_NETNS_LOCAL from vti6 devices. A vti6 tunnel can then move through IFLA_NET_NS_FD. After the move dev_net(dev) points at the new netns while t->net stays at the creation netns.

vti6_changelink() and vti6_update() still use dev_net(dev) and dev_net(t->dev). They unlink from one per netns hash and relink into another. The creation netns is left with a stale entry. cleanup_net() of that netns later walks freed memory.

Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). Cross tenant scope on container hosts.(CVE-2026-63917)

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

xfrm: input: hold netns during deferred transport reinjection

Transport-mode reinjection stores a struct net pointer in skb->cb and uses it later from xfrm_trans_reinject(). That pointer must stay valid until the deferred callback runs.

Take a netns reference when queueing deferred reinjection work and drop it after the callback completes. Use maybe_get_net() so the queueing path does not revive a namespace that is already being torn down.

This keeps the existing workqueue design and fixes the netns lifetime handling in one place for all users of xfrm_trans_queue_net().(CVE-2026-63919)

In the Linux kernel, ip6_datagram_recv_specific_ctl() builds IPV6_{HOPOPTS,DSTOPTS,RTHDR} cmsgs (and their IPV6_2292* legacy counterparts) by trusting the on-wire hdrlen byte (ptr[1]) when computing the put_cmsg() length. The length was validated only at parse time (ipv6_parse_hopopts(), etc.). An nftables payload-write expression can rewrite hdrlen after parsing and before the skb reaches recvmsg; the write itself is in-bounds but put_cmsg() then reads up to ((hdrlen+1) << 3) = 2040 bytes from an 8-byte header. nftables is reachable from an unprivileged user namespace, so this is an unprivileged slab-out-of-bounds read.(CVE-2026-63920)

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

ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().

After patch 1/2 in this series, vti6_update() unlinks and relinks the tunnel through t->net. vti6_siocdevprivate() still uses dev_net(dev) for the collision lookup. For a tunnel moved through IFLA_NET_NS_FD, dev_net(dev) is the new netns, not t->net.

SIOCCHGTUNNEL on a migrated tunnel then runs:

net = dev_net(dev) / migrated netns / t = vti6_locate(net, &p1, false) / misses target in t->net / ... t = netdev_priv(dev) vti6_update(t, &p1, false) / mutates t->net's hash /

A caller in the migrated netns picks params that match a tunnel in the creation netns. The lookup in dev_net(dev) finds nothing. vti6_update() prepends the migrated tunnel at the head of the creation netns hash bucket for those params. Later lookups in the creation netns resolve to the migrated device. xfrm receive delivers the matched packets through a device the caller controls.

Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). Cross tenant scope on container hosts.

Switch the SIOCCHGTUNNEL path on a non fallback device to use t->net for the lookup. The lookup now matches the netns vti6_update() operates on.

Also add ns_capable(self->net->user_ns, CAP_NET_ADMIN) before the lookup. The check at the top of the case is against dev_net(dev)->user_ns, which after migration is the attacker's netns. A caller there can pick params absent from self->net, the lookup returns NULL, t becomes self, and vti6_update() inserts the device into the creation netns hash. The new check requires CAP_NET_ADMIN in the creation netns user_ns too.

SIOCADDTUNNEL and SIOCCHGTUNNEL on the fallback device keep dev_net(dev), which equals init_net there.(CVE-2026-63921)

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

ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()

ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.(CVE-2026-63924)

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

bpf: sockmap: fix tail fragment offset in bpf_msg_push_data

When bpf_msg_push_data() inserts data in the middle of a scatterlist entry, it splits the original entry into a left fragment and a right fragment.

The right fragment offset is page-local, but the code advances it with start, which is the message-global insertion point. For inserts into a non-first SG entry, this over-advances the offset and leaves the split layout inconsistent.

Advance the right fragment offset by the fragment-local delta, start - offset, which matches the length removed from the front of the original entry.(CVE-2026-63926)

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

USB: serial: omninet: fix memory corruption with small endpoint

Make sure that the bulk-out buffers are at least as large as the hardcoded transfer size to avoid user-controlled slab corruption should a malicious device report a smaller endpoint max packet size than expected.(CVE-2026-63928)

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

Bluetooth: hci_sync: fix UAF in hci_le_create_cis_sync

hci_le_create_cis_sync() dereferences conn->conn_timeout after releasing both rcu_read_lock() and hci_dev_lock(hdev). The conn pointer was obtained from an RCU-protected iteration over hdev->conn_hash.list and is not valid once these locks are dropped. A concurrent disconnect can free the hci_conn between the unlock and the dereference, causing a use-after-free read.

The cancellation mechanism in hci_conn_del() cannot prevent this because hci_le_create_cis_pending() queues hci_create_cis_sync with data=NULL:

hci_cmd_sync_queue(hdev, hci_create_cis_sync, NULL, NULL);

While hci_conn_del() dequeues with data=conn:

hci_cmd_sync_dequeue(hdev, NULL, conn, NULL);

Since NULL != conn, the lookup in _hci_cmd_sync_lookup_entry() never matches, and the pending work item is not cancelled.

Fix this by saving conn->conn_timeout into a local variable while the locks are still held, so the stale conn pointer is never dereferenced after unlock.

This is the same class of bug as the one fixed by commit 035c25007c9e ("Bluetooth: hci_sync: Fix UAF on le_read_features_complete") which addressed the identical pattern in a different function.

This vulnerability was identified using 0sec.ai, an open-source automated security auditing platform (https://github.com/0sec-labs).(CVE-2026-63944)

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

Bluetooth: ISO: serialize iso_sock_clear_timer with socket lock

iso_sock_close() calls iso_sock_clear_timer() before acquiring lock_sock(sk).

iso_sock_clear_timer() reads iso_pi(sk)->conn twice without the socket lock held:

if (!iso_pi(sk)-&gt;conn)
    return;
cancel_delayed_work(&amp;iso_pi(sk)-&gt;conn-&gt;timeout_work);

Concurrently, iso_conn_del() executes under lock_sock(sk) and calls iso_chan_del(), which sets iso_pi(sk)->conn to NULL and may result in the final reference to the connection being dropped:

CPU0                         CPU1
----                         ----
iso_sock_clear_timer()
  if (conn != NULL) ...      lock_sock(sk)
                               iso_chan_del()
                               iso_pi(sk)-&gt;conn = NULL
  cancel_delayed_work(conn)  /* NULL deref or UAF */

iso_pi(sk)->conn is not stable across the unlock window, causing a NULL pointer dereference or use-after-free.

Serialize iso_sock_clear_timer() with the socket lock by moving it inside lock_sock()/release_sock(), matching the pattern used in iso_conn_del() and all other call sites.(CVE-2026-63945)

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

Bluetooth: ISO: fix UAF in iso_recv_frame

iso_recv_frame reads conn->sk under iso_conn_lock but releases the lock before using sk, with no reference held. A concurrent iso_sock_kill() can free sk in that window, causing use-after-free on sk->sk_state and sock_queue_rcv_skb().

Fix by replacing the bare pointer read with iso_sock_hold(conn), which calls sock_hold() while the spinlock is held, atomically elevating the refcount before the lock drops. Add a drop_put label so sock_put() is called on all exit paths where the hold succeeded.(CVE-2026-63946)

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

memfd: deny writeable mappings when implying SEAL_WRITE

When SEAL_EXEC is added, SEAL_WRITE is implied to make W^X. But the implied seal is set after the check that makes sure the memfd can not have any writable mappings. This means one can use SEAL_EXEC to apply SEAL_WRITE while having writeable mappings.

This breaks the contract that SEAL_WRITE provides and can be used by an attacker to pass a memfd that appears to be write sealed but can still be modified arbitrarily.

Fix this by adding the implied seals before the call for mapping_deny_writable() is done.(CVE-2026-63952)

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

USB: serial: cypress_m8: fix memory corruption with small endpoint

Make sure that the interrupt-out endpoint max packet size is at least eight bytes to avoid user-controlled slab corruption or NULL-pointer dereference should a malicious device report a smaller size.(CVE-2026-63956)

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

ipv6: fix possible infinite loop in fib6_select_path()

Found while auditing the same pattern Sashiko reported in rt6_fill_node() [1]. Apply the same fix as commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6_info_uses_dev()").

Writers holding tb6_lock can list_del_rcu(&first->fib6_siblings) without waiting for RCU readers; first->fib6_siblings.next then still points into the old ring and this softirq-side walker never reaches &first->fib6_siblings as its terminator. fib6_purge_rt() always WRITE_ONCE()s first->fib6_nsiblings to 0 before list_del_rcu(), so an inside-loop check is a reliable detach signal.

[1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev(CVE-2026-63968)

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

sctp: fix race between sctp_wait_for_connect and peeloff

sctp_wait_for_connect() drops and re-acquires the socket lock while waiting for the association to reach ESTABLISHED state. During this window, another thread can peeloff the association to a new socket via getsockopt(SCTP_SOCKOPT_PEELOFF), changing asoc->base.sk. After re-acquiring the old socket lock, sctp_wait_for_connect() returns success without noticing the migration — the caller then accesses the association under the wrong lock in sctp_datamsg_from_user().

Add the same sk != asoc->base.sk check that sctp_wait_for_sndbuf() already has, returning an error if the association was migrated while we slept.(CVE-2026-63971)

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

Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close

Since hci_dev_close_sync() can now be called during the reset path, we should also set HCI_CMD_DRAIN_WORKQUEUE. This avoids queuing timeouts while the hdev workqueue is being drained.(CVE-2026-63974)

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

Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp

If dcid is received for an already-assigned destination CID the spec requires that both channels to be discarded, but calling l2cap_chan_del may invalidate the tmp cursor created by list_for_each_entry_safe and in fact it is the wrong procedure as the chan->dcid may be assigned previously it really needs to be disconnected.

Calling l2cap_chan_clone directly may still lead to l2cap_chan_del so instead schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously.(CVE-2026-63975)

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

Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success

l2cap_ecred_reconf_rsp() returns early on success without clearing chan->ident. Every other L2CAP response handler (l2cap_ecred_conn_rsp, l2cap_le_connect_rsp, l2cap_config_rsp) clears chan->ident after a successful transaction to prevent the channel from matching subsequent responses with the recycled ident value.

A remote attacker that completed a reconfiguration as the peer can replay a failure response with the stale ident, causing the kernel to match and destroy the already-established channel via l2cap_chan_del(chan, ECONNRESET).

Clear chan->ident for all matching channels on success, and harden the failure path by using l2cap_chan_hold_unless_zero() consistent with other L2CAP handlers (l2cap_le_command_rej, __l2cap_get_chan_by_ident).(CVE-2026-63976)

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

ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()

ipv6_rpl_srh_decompress() computes:

outhdr-&gt;hdrlen = (((n + 1) * sizeof(struct in6_addr)) &gt;&gt; 3);

hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16):

(128 * 16) &gt;&gt; 3 = 256, truncated to 0 as __u8

The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet.

The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit.

Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.(CVE-2026-63984)

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

ethtool: eeprom: add more safeties to EEPROM Netlink fallback

The Netlink fallback path for reading module EEPROM (fallback_set_params()) validates that offset < eeprom_len, but does not check that offset + length stays within eeprom_len. The ioctl equivalent (ethtool_get_any_eeprom() in ioctl.c) has always enforced both bounds:

if (eeprom.offset + eeprom.len > total_len) return -EINVAL;

This could lead to surprises in both drivers and device FW. Add the missing offset + length validation to fallback_set_params(), mirroring the ioctl.

Similarly - ethtool core in general, and ethtool_get_any_eeprom() in particular tries to zero-init all buffers passed to the drivers to avoid any extra work of zeroing things out. eeprom_fallback() uses a plain kmalloc(), change it to zalloc.(CVE-2026-63985)

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

tunnels: do not assume transport header in iptunnel_pmtud_check_icmp()

In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set.

This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535.

Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part.

Note that iptunnel_pmtud_check_icmpv6()) is fine.(CVE-2026-63992)

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

vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()

skb_tunnel_check_pmtu() can change skb->head.

Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF.

Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c.

Found by Sashiko.(CVE-2026-63993)

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

tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmpv6

Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head.

Fix this possible UAF by initializing the local variables after the skb_cow() call.

Remove skb_reset_network_header() calls which were not needed.(CVE-2026-63994)

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

ipv4: free net->ipv4.sysctl_local_reserved_ports after unregister_net_sysctl_table()

ipv4_sysctl_exit_net() is currently freeing net->ipv4.sysctl_local_reserved_ports too soon.

Only after unregister_net_sysctl_table() we can be sure no threads can possibly use the sysctls, including /proc/sys/net/ipv4/ip_local_reserved_ports.(CVE-2026-64002)

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

scsi: core: Run queues for all non-SDEV_DEL devices from scsi_run_host_queues

While a SCSI host is in a recovery state, scsi_mq_requeue_cmd() will not set the requeue list for a requeued command to be kicked in the future. The expectation is a call to scsi_run_host_queues() will kick all SCSI devices once the recovery state is cleared.

However, scsi_run_host_queues() uses shost_for_each_device() which uses scsi_device_get() and so will ignore devices in a partially removed state like SDEV_CANCEL. But these devices may also have requeued requests, leaving their requests stuck from not being kicked and causing the removal process of the device to hang.

scsi_run_host_queues() needs to run against more devices than the macro shost_for_each_device() allows. Instead of using the too limiting scsi_device_get() state checks, only ignore devices in SDEV_DEL state or when unable to acquire a reference. Attempt to run the queues for all other devices when scsi_run_host_queues() is called.(CVE-2026-64003)

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

security/keys: fix missed RCU read section on lookup

Nicholas Carlini reports that the keyring code calls assoc_array_find() in find_key_to_update() without holding the RCU read lock, while the assoc_array_gc() code really is designed around removing the node from the tree and then freeing it after an RCU grace-period.

The regular key handling doesn't see this because holding the keyring semaphore hides any lifetime issues, but the persistent key handling uses a different model.

Instead of extending the keyring locking, just do the simple RCU locking that the assoc_array was designed for.(CVE-2026-64015)

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

bpf, skmsg: fix verdict sk_data_ready racing with ktls rx

sk_psock_strp_data_ready() already checks tls_sw_has_ctx_rx() and defers to psock->saved_data_ready when a TLS RX context is present, avoiding a conflict with the TLS strparser's ownership of the receive queue (commit e91de6afa81c, "bpf: Fix running sk_skb program types with ktls").

sk_psock_verdict_data_ready() has no equivalent guard. When a socket is inserted into a sockmap (BPF_SK_SKB_VERDICT) before TLS RX is configured, tls_sw_strparser_arm() saves sk_psock_verdict_data_ready as rx_ctx->saved_data_ready. On data arrival:

tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready -> saved_data_ready() = sk_psock_verdict_data_ready() -> tcp_read_skb() drains sk_receive_queue via __skb_unlink() without calling tcp_eat_skb(), so copied_seq is not advanced.

tls_strp_msg_load() then finds tcp_inq() >= full_len (stale), calls tcp_recv_skb() on the now-empty queue, hits WARN_ON_ONCE(!first), and returns with rx_ctx->strp.anchor.frag_list pointing at a psock-owned (potentially freed) skb. tls_decrypt_sg() subsequently walks that frag_list: use-after-free.

Apply the same fix as sk_psock_strp_data_ready(): if a TLS RX context is present, call psock->saved_data_ready (sock_def_readable) to wake recv() waiters and return immediately, leaving the receive queue untouched. TLS retains sole ownership of the queue and decrypts the record normally through tls_sw_recvmsg().(CVE-2026-64025)

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

bridge: mcast: Fix a possible use-after-free when removing a bridge port

When per-VLAN multicast snooping is enabled, the bridge iterates over all the bridge ports, disables the per-port multicast context on each port and enables the per-{port, VLAN} multicast contexts instead. The reverse happens when per-VLAN multicast snooping is disabled.

When global multicast snooping is enabled, the bridge iterates over all the bridge ports and enables the per-port multicast context on each port. The reverse happens when multicast snooping is disabled.

The above scheme can result in a situation where both types of contexts (per-port and per-{port, VLAN}) are enabled on a single bridge port:

# ip link add name br1 up type bridge mcast_snooping 1 mcast_querier 1 vlan_filtering 1 # ip link add name dummy1 up master br1 type dummy # ip link set dev br1 type bridge mcast_vlan_snooping 1 # ip link set dev br1 type bridge mcast_snooping 0 # ip link set dev br1 type bridge mcast_snooping 1

This is not intended and it is a problem since the commit cited below. Prior to this commit, when removing a bridge port, br_multicast_disable_port() would disable the per-port multicast context and the per-{port, VLAN} multicast contexts would get disabled when flushing VLANs.

After this commit, br_multicast_disable_port() only disables the per-port multicast context if per-VLAN multicast snooping is disabled. If both types of contexts were enabled on the port when it was removed, the per-port multicast context would remain enabled when freeing the bridge port, leading to a use-after-free [1].

Fix by preventing the bridge from enabling / disabling the per-port multicast contexts when toggling global multicast snooping if per-VLAN multicast snooping is enabled.

[1] ODEBUG: free active (active state 0) object: ffff88810f8bda78 object type: timer_list hint: br_ip6_multicast_port_query_expired (net/bridge/br_multicast.c:1927) WARNING: lib/debugobjects.c:629 at debug_print_object+0x1b1/0x3e0, CPU#5: swapper/5/0 [...] Call Trace: <IRQ> __debug_check_no_obj_freed (lib/debugobjects.c:1116) kfree (mm/slub.c:2620 mm/slub.c:6250 mm/slub.c:6565) kobject_cleanup (lib/kobject.c:689) rcu_do_batch (kernel/rcu/tree.c:2617) rcu_core (kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) __irq_exit_rcu (kernel/softirq.c:656 kernel/softirq.c:496 kernel/softirq.c:735) irq_exit_rcu (kernel/softirq.c:752) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1061 (discriminator 47) arch/x86/kernel/apic/apic.c:1061 (discriminator 47)) </IRQ>(CVE-2026-64032)

In the Linux kernel, the following vulnerability has been resolved: net: tls: prevent chain-after-chain in plain text SG. Sashiko points out that if end = 0 (start != 0) the current code will create a chain link to content type right after the wrap link. This would create a chain where the wrap link points directly to another chain link. The scatterlist API sg_next iterator does not recursively resolve consecutive chain links, meaning this is illegal input to crypto. The wrapping link is unnecessary if end = 0. TLS 1.3 can use the "wrapping slot" for its chaining if end = 0, which avoids the chain-after-chain.(CVE-2026-64046)

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

net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring

When an sk_msg scatterlist ring wraps (sg.end < sg.start), tls_push_record() chains the tail portion of the ring to the head using sg_chain(). An extra entry in the sg array is reserved for this:

struct sk_msg_sg { [...] / The extra two elements: * 1) used for chaining the front and sections when the list becomes * partitioned (e.g. end < start). The crypto APIs require the * chaining; * 2) to chain tailer SG entries after the message. / struct scatterlist data[MAX_MSG_FRAGS + 2];

The current code uses MAX_SKB_FRAGS + 1 as the ring size:

sg_chain(&amp;msg_pl-&gt;sg.data[msg_pl-&gt;sg.start],
         MAX_SKB_FRAGS - msg_pl-&gt;sg.start + 1,
         msg_pl-&gt;sg.data);

This places the chain pointer at

sg_chain(data[start], (MAX_SKB_FRAGS - msg_start + 1) .. = &data[start] + (MAX_SKB_FRAGS - msg_start + 1) - 1 = data[start + (MAX_SKB_FRAGS - start + 1) - 1] = data[MAX_SKB_FRAGS]

instead of the true last entry. This is likely due to a "race" of the commit under Fixes landing close to commit 031097d9e079 ("bpf: sk_msg, zap ingress queue on psock down")

Convert to ARRAY_SIZE and drop the data[start] / - start (as suggested by Sabrina).(CVE-2026-64047)

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

irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT

On PREEMPT_RT, non-HARD irq_work runs in per-CPU kthreads via run_irq_workd(), so irq_work_sync() uses rcuwait() to wait for BUSY==0.

After irq_work_single() clears BUSY via atomic_cmpxchg(), it still dereferences @work for irq_work_is_hard() and rcuwait_wake_up().

An irq_work_sync() caller on another CPU that enters after BUSY is cleared can observe BUSY==0 immediately, return, and free the work before those accesses complete — causing a use-after-free.

Fix this by wrapping run_irq_workd() in guard(rcu)() so that the entire irq_work_single() execution is within an RCU read-side critical section. Then add synchronize_rcu() in irq_work_sync() after rcuwait_wait_event() to ensure the caller waits for the RCU grace period before returning, preventing premature frees.(CVE-2026-64073)

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

netfilter: bridge: eb_tables: close module init race

sashiko reports for unrelated patch: Does the core ebtables initialization in ebtables.c suffer from a similar race? Once nf_register_sockopt() completes, the sockopts are exposed globally.

sockopt has to be registered last, just like in ip/ip6/arptables.(CVE-2026-64076)

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

netfilter: ebtables: move to two-stage removal scheme

Like previous patches for x_tables, follow same pattern in ebtables. We can't reuse xt helpers: ebt_table struct layout is incompatible.

table->ops assignment is now done while still holding the ebt mutex to make sure we never expose partially-filled table struct.(CVE-2026-64077)

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

batman-adv: tt: fix negative tt_buff_len

batadv_orig_node::tt_buff_len was declared as s16, but the field is never intended to hold a negative value. When a value greater than 32767 is assigned, it wraps to a negative signed integer.

In batadv_send_other_tt_response(), tt_buff_len is temporarily widened to s32. The incorrectly negative s16 value propagates into the s32, causing batadv_tt_prepare_tvlv_global_data() to allocate a full sized buffer but populates only a small portion of it with the collected changeset. All remaining bits are kept uninitialized.

Using an u16 avoids this type confusion and ensures that no (negative) sign extension is performed in batadv_send_other_tt_response().(CVE-2026-64088)

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

batman-adv: tt: fix negative last_changeset_len

batadv_piv_tt::last_changeset_len len was declared as s16, but the field is never intended to hold a negative value. When a value greater than 32767 is assigned, it wraps to a negative signed integer.

In batadv_send_my_tt_response(), last_changeset_len is temporarily widened to s32. The incorrectly negative s16 value propagates into the s32, causing batadv_tt_prepare_tvlv_local_data() to allocate a full sized buffer but populates only a small portion of it with the collected changeset. All remaining bits are kept uninitialized.

Using an u16 avoids this type confusion and ensures that no (negative) sign extension is performed in batadv_send_my_tt_response().(CVE-2026-64089)

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

batman-adv: bla: avoid double decrement of bla.num_requests

The bla.num_requests is increased when no request_sent was in progress. And it is decremented in various places (announcement was received, backbone is purged, periodic work). But the check if the request_sent is actually set to a specific state and the atomic_dec/_inc are not safe because they are not atomic (TOCTOU) and multiple such code portions can run concurrently.

At the same time, it is necessary to modify request_sent (state) and bla.num_requests atomically. Otherwise batadv_bla_send_request() might set request_sent to 1 and is interrupted. batadv_handle_announce() can then set request_sent back to 0 and decrement num_requests before batadv_bla_send_request() incremented it.

The two operations must therefore be locked. And since state (request_sent) and wait_periods are only accessed inside this lock, they can be converted to simpler datatypes. And to avoid that the bla.num_requests is touched by a parallel running context with a valid backbone_gw reference after batadv_bla_purge_backbone_gw() ran, a third state "stopped" is required to correctly signal that a backbone_gw is in the state of being cleaned up.(CVE-2026-64095)

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

drm/amd/display: Validate GPIO pin LUT table size before iterating

[Why&How] The GPIO pin table parsers in get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() derive an element count from the VBIOS table_header.structuresize field, then iterate over gpio_pin[] entries. However, GET_IMAGE() only validates that the table header itself fits within the BIOS image. If the VBIOS reports a structuresize larger than the actual mapped data, the loop reads past the end of the BIOS image, causing an out-of-bounds read.

Fix this by calling bios_get_image() to validate that the full claimed structuresize is accessible within the BIOS image before entering the loop in both functions.

(cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3)(CVE-2026-64097)

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

drm/virtio: use uninterruptible resv lock for plane updates

virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock the framebuffer BO's dma_resv via virtio_gpu_array_lock_resv() and ignore its return value. The function can fail with -EINTR from dma_resv_lock_interruptible() (signal during lock wait) or with -ENOMEM from dma_resv_reserve_fences() (fence slot allocation), leaving the resv lock not held. The queue path then walks the object array and calls dma_resv_add_fence(), which requires the lock held; with lockdep enabled this trips dma_resv_assert_held():

WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840 Call Trace: virtio_gpu_array_add_fence virtio_gpu_queue_ctrl_sgs virtio_gpu_queue_fenced_ctrl_buffer virtio_gpu_cursor_plane_update drm_atomic_helper_commit_planes drm_atomic_helper_commit_tail commit_tail drm_atomic_helper_commit drm_atomic_commit drm_atomic_helper_update_plane __setplane_atomic drm_mode_cursor_universal drm_mode_cursor_common drm_mode_cursor_ioctl drm_ioctl __x64_sys_ioctl

Beyond the WARN, mutating the dma_resv fence list without the lock races with concurrent readers/writers and can corrupt the list.

Both call sites run inside the .atomic_update plane callback, which DRM atomic helpers do not allow to fail (by the time it runs, the commit has been signed off to userspace and there is no clean rollback path). Moving the lock acquisition to .prepare_fb was rejected because the broader lock scope deadlocks against other BO locking paths in the same atomic commit.

Introduce virtio_gpu_lock_one_resv_uninterruptible() that uses dma_resv_lock() instead of dma_resv_lock_interruptible(). This eliminates the -EINTR failure mode -- the realistic syzbot trigger -- without extending the lock hold across the commit. The helper locks a single BO and rejects nents > 1 with -EINVAL; both fix sites lock exactly one BO.

Use it from virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush(); check the return value to handle the remaining -ENOMEM case from dma_resv_reserve_fences() by freeing the objs and skipping the plane update for that frame. The framebuffer BOs touched here are not shared with other contexts and lock contention is expected to be brief, so the loss of signal-interruptibility is acceptable.

Other callers of virtio_gpu_array_lock_resv() (the ioctl paths) continue to use the interruptible variant.

The bug was reported by syzbot, triggered via fault injection (fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the -ENOMEM branch in dma_resv_reserve_fences().(CVE-2026-64098)

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

KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits

Userspace can restore an ITS Device Table Entry whose Size field encodes more EventID bits than the virtual ITS supports. The live MAPD path rejects that state, but vgic_its_restore_dte() accepts it and stores the out-of-range value in dev->num_eventid_bits.

Reject restored DTEs with num_eventid_bits > VITS_TYPER_IDBITS before allocating the device. This mirrors the MAPD check and prevents the restored state from reaching vgic_its_restore_itt(), where the unchecked value can be converted into an oversized scan_its_table() range.(CVE-2026-64106)

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

af_unix: Fix UAF read of tail->len in unix_stream_data_wait()

unix_stream_data_wait() does skb_peek_tail(&sk->sk_receive_queue) without holding any lock that prevents SKBs on that queue from being dequeued and freed. This has been the case since commit 79f632c71bea ("unix/stream: fix peeking with an offset larger than data in queue"). The first consequence of this is that the pointer comparison tail != last can be false even if last semantically refers to an already-freed SKB while tail is a new SKB allocated at the same address; which can cause unix_stream_data_wait() to wrongly keep blocking after new data has arrived, but only in a weird scenario where a peeking recv() and a normal recv() on the same socket are racing, which is probably not a real problem.

But since commit 2b514574f7e8 ("net: af_unix: implement splice for stream af_unix sockets"), tail is actually dereferenced, which can cause UAF in the following race scenario (where test_setup() runs single-threaded, and afterwards, test_thread1() and test_thread2() run concurrently in two threads:

static int socks[2];
void test_setup(void) {
  socketpair(AF_UNIX, SOCK_STREAM, 0, socks);
  send(socks[1], &quot;A&quot;, 1, 0);
  int peekoff = 1;
  setsockopt(socks[0], SOL_SOCKET, SO_PEEK_OFF, &amp;peekoff, sizeof(peekoff));
}
void test_thread1(void) {
  char dummy;
  recv(socks[0], &amp;dummy, 1, MSG_PEEK);
}
void test_thread2(void) {
  char dummy;
  recv(socks[0], &amp;dummy, 1, 0);
  shutdown(socks[1], SHUT_WR);
}

when racing like this:

thread1                       thread2
unix_stream_read_generic
  mutex_lock(&amp;u-&gt;iolock)
  skb_peek(&amp;sk-&gt;sk_receive_queue)
  skb_peek_next(skb, &amp;sk-&gt;sk_receive_queue)
  mutex_unlock(&amp;u-&gt;iolock)
                              unix_stream_read_generic
                                unix_state_lock(sk)
                                skb_peek(&amp;sk-&gt;sk_receive_queue)
                                unix_state_unlock(sk)
  unix_stream_data_wait
    unix_state_lock(sk)
    tail = skb_peek_tail(&amp;sk-&gt;sk_receive_queue)
                                spin_lock(&amp;sk-&gt;sk_receive_queue.lock)
                                __skb_unlink(skb, &amp;sk-&gt;sk_receive_queue)
                                spin_unlock(&amp;sk-&gt;sk_receive_queue.lock)
                                consume_skb(skb) [frees the SKB]
    `tail != last`: false
    `tail`: true
    `tail-&gt;len != last_len` ***UAF***

Fix the UAF by removing the read of tail->len; checking tail->len would only make sense if SKBs in the receive queue of a UNIX socket could grow, which can no longer happen.

Kuniyuki explained:

> When commit 869e7c62486e ("net: af_unix: implement stream sendpage > support") added sendpage() support, data could be appended to the last > skb in the receiver's queue. > > That's why we needed to check if the length of the last skb was changed > while waiting for new data in unix_stream_data_wait(). > > However, commit a0dbf5f818f9 ("af_unix: Support MSG_SPLICE_PAGES") and > commit 57d44a354a43 ("unix: Convert unix_stream_sendpage() to use > MSG_SPLICE_PAGES") refactored sendmsg(), and now data is always added > to a new skb.

That means this fix is not suitable for kernels before 6.5.(CVE-2026-64109)

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

rbd: eliminate a race in lock_dwork draining on unmap

Given how rbd_lock_add_request() and rbd_img_exclusive_lock() are written, lock_dwork may be (re)queued more than it's actually needed: for example in case a new I/O request comes in while we are in the middle of rbd_acquire_lock() on behalf of another I/O request. This is expected and with rbd_release_lock() preemptively canceling lock_dwork is benign under normal operation.

A more problematic example is maybe_kick_acquire():

if (have_requests || delayed_work_pending(&amp;rbd_dev-&gt;lock_dwork)) {
        dout(&quot;%s rbd_dev %p kicking lock_dwork\n&quot;, __func__, rbd_dev);
        mod_delayed_work(rbd_dev-&gt;task_wq, &amp;rbd_dev-&gt;lock_dwork, 0);
}

It's not unrealistic for lock_dwork to get canceled right after delayed_work_pending() returns true and for mod_delayed_work() to requeue it right there anyway. This is a classic TOCTOU race.

When it comes to unmapping the image, there is an implicit assumption of no self-initiated exclusive lock activity past the point of return from rbd_dev_image_unlock() which unlocks the lock if it happens to be held. This unlock is assumed to be final and lock_dwork (as well as all other exclusive lock tasks, really) isn't expected to get queued again. However, lock_dwork is canceled only in cancel_tasks_sync() (i.e. later in the unmap sequence) and on top of that the cancellation can get in effect nullified by maybe_kick_acquire(). This may result in rbd_acquire_lock() executing after rbd_dev_device_release() and rbd_dev_image_release() run and free and/or reset a bunch of things. One of the possible failure modes then is a violated

rbd_assert(rbd_image_format_valid(rbd_dev-&gt;image_format));

in rbd_dev_header_info() which is called via rbd_dev_refresh() from rbd_post_acquire_action().

Redo exclusive lock task draining to provide saner semantics and try to meet the assumptions around rbd_dev_image_unlock().(CVE-2026-64112)

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

ixgbevf: fix use-after-free in VEPA multicast source pruning

ixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF's own address (VEPA multicast workaround) by freeing the skb and continuing to the next descriptor:

dev_kfree_skb_irq(skb);
continue;

The skb pointer is declared outside the while loop and persists across iterations. Because the continue skips the "skb = NULL" reset at the bottom of the loop, the next iteration enters the "else if (skb)" path and calls ixgbevf_add_rx_frag() on the freed skb, dereferencing skb_shinfo(skb)->nr_frags - a use-after-free in NAPI softirq context.

The sibling driver iavf already handles this correctly by nulling the pointer before continuing. Apply the same pattern here.

I do not have ixgbevf hardware; the bug was found by static analysis (scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool corroboration with the highest score in the scan). The UAF was confirmed under KASAN by loading a test module that reproduces the exact code pattern (alloc skb, kfree_skb, then read skb_shinfo(skb)->nr_frags):

BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000 Read of size 8 at addr 000000006163ae78 by task insmod/30 freed 208-byte region [000000006163adc0, 000000006163ae90)

QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF driver does not include the VEPA source pruning path, so a full end-to-end reproduction with emulated hardware was not possible.(CVE-2026-64113)

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

ipv4: raw: reject IP_HDRINCL packets with ihl < 5

raw_send_hdrinc() validates that the caller-supplied IPv4 header fits within the message length:

iphlen = iph-&gt;ihl * 4;
err = -EINVAL;
if (iphlen &gt; length)
    goto error_free;

if (iphlen &gt;= sizeof(*iph)) {
    /* fix up saddr, tot_len, id, csum, transport_header */
}

It does not, however, reject ihl < 5. For such a packet the "if (iphlen >= sizeof(*iph))" branch is skipped, leaving the crafted iphdr untouched, but the packet is still handed to __ip_local_out() and onward. Downstream consumers that read iph->ihl assume a sane value: net/ipv4/ah4.c:ah_output() in particular subtracts sizeof(struct iphdr) from top_iph->ihl * 4 and passes the (signed-int-negative, then cast to size_t) result to memcpy(), producing an OOB access of length close to SIZE_MAX and a host kernel panic.

An IPv4 header with ihl < 5 is malformed by definition (RFC 791: "Internet Header Length is the length of the internet header in 32 bit words ... Note that the minimum value for a correct header is 5."). The kernel should not be willing to inject such a packet into its own output path.

Reject "iphlen < sizeof(*iph)" alongside the existing "iphlen > length" check. This matches the principle that locally constructed packets that re-enter the IP stack must pass the same basic sanity tests that a foreign packet would be subjected to.

Once this lands, the "if (iphlen >= sizeof(*iph))" wrapper around the fixup branch becomes redundant; left in place to keep the patch minimal and backport-friendly. A follow-up can unwrap it.

Note that commit 86f4c90a1c5c ("ipv4, ipv6: ensure raw socket message is big enough to hold an IP header") ensures the message buffer is large enough to hold an iphdr, but does not constrain the self-reported iph->ihl.

Reachability: the malformed packet source is any caller with CAP_NET_RAW, including an unprivileged process in a user+net namespace on a kernel with CONFIG_USER_NS=y. The reproduced AH crash also requires a matching xfrm AH policy on the outgoing route; a container granted CAP_NET_ADMIN can install that state and policy in its netns. Loopback bypasses xfrm_output, so the trigger uses a real netdev.

Reproduced on UML + KASAN: kernel-mode fault at addr 0x0 with memcpy_orig at the crash site. Same shape reproduces inside a rootless Docker container with --cap-add NET_ADMIN on a stock distro kernel.(CVE-2026-64114)

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

qed: fix double free in qed_cxt_tables_alloc()

If one of the later PF or VF CID bitmap allocations fails, qed_cid_map_alloc() jumps to cid_map_fail and frees the previously allocated CID bitmaps before returning an error. qed_cxt_tables_alloc() then calls qed_cxt_mngr_free(), which invokes qed_cid_map_free() again.

Fix this by setting each CID bitmap pointer to NULL after bitmap_free() to avoid double free.

The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc3.

Runtime reproduction was not attempted because exercising the failing allocation path requires device-specific setup.(CVE-2026-64118)

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

Bluetooth: MGMT: validate Add Extended Advertising Data length

MGMT_OP_ADD_EXT_ADV_DATA is registered as a variable-length command, with MGMT_ADD_EXT_ADV_DATA_SIZE as the fixed header size. The handler then uses cp->adv_data_len and cp->scan_rsp_len to validate and copy cp->data, but it never checks that those bytes are part of the mgmt command payload.

A short command can therefore make add_ext_adv_data() pass an out-of-bounds pointer into tlv_data_is_valid(). If the bytes beyond the command buffer are addressable, they can also be copied into the advertising instance as scan response data, where the caller can read them back via MGMT_OP_GET_ADV_INSTANCE. The trigger requires CAP_NET_ADMIN in the initial user namespace; KASAN reports an 8-byte slab-out-of-bounds read.

Reject commands whose length does not match the fixed header plus both advertising data lengths before parsing cp->data.(CVE-2026-64126)

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

smb: client: protect tc_count increment in smb2_find_smb_sess_tcon_unlocked()

Commit 96c4af418586 ("cifs: Fix locking usage for tcon fields") refactored cifs code to change cifs_tcp_ses_lock for tc_lock around tc_count changes.

There was missing lock around tc_count increment inside smb2_find_smb_sess_tcon_unlocked().(CVE-2026-64136)

In the Linux kernel, an out-of-bounds read vulnerability exists in the i2c-stub driver. The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() function (drivers/i2c/i2c-stub.c) uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer. A local user with access to /dev/i2c-* devices can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer, resulting in a stack out-of-bounds access. This vulnerability affects confidentiality, integrity, and availability.(CVE-2026-64191)

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

drm/amd/display: Validate payload length and link_index in dc_process_dmub_aux_transfer_async

[Why&How] dc_process_dmub_aux_transfer_async() copies payload->length bytes into a 16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which is a no-op in release builds. If a caller ever passes length > 16 this results in a stack buffer overflow via memcpy.

Additionally, link_index is used to dereference dc->links[] without bounds checking against dc->link_count, risking an out-of-bounds access.

Replace the ASSERT with a hard runtime check that returns false when payload->length exceeds the destination buffer size, and add a bounds check for link_index before it is used.

(cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881)(CVE-2026-64219)

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

octeontx2-pf: avoid double free of pool->stack on AQ init failure

otx2_pool_aq_init() frees pool->stack when mailbox sync or retry allocation fails, but leaves the pointer unchanged. Later, otx2_sq_aura_pool_init() unwinds the partial setup through otx2_aura_pool_free(), which frees pool->stack again. The CN20K-specific cn20k_pool_aq_init() implementation has the same bug in its corresponding error path.

Set pool->stack to NULL immediately after the local free so the shared cleanup path does not free the same stack again while cleaning up partially initialized pool state.

Runtime validation was not performed because reproducing this path requires OcteonTX2/CN20K hardware.(CVE-2026-64222)

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

Input: elan_i2c - validate firmware size before use

Ensure that the firmware file is large enough to contain the expected number of pages and the signature (which resides at the end of the firmware blob) before accessing them to prevent potential out-of-bounds reads.(CVE-2026-64237)

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

KVM: x86: hyper-v: Bound the bank index when querying sparse banks

When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096.

Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU.

================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802

CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf </TASK>

The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint

Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask.

sean: add KASAN splat, drop comment, add assert, massage changelog

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

NFSv4: include MAY_WRITE in open permission mask for O_TRUNC

POSIX requires write permission to truncate a file, so an open() that specifies O_TRUNC must be authorized for write access regardless of the O_ACCMODE access mode.

nfs_open_permission_mask() builds the access mask passed to nfs_may_open(), which is the local authorization gate for OPENs the client serves itself from a cached write delegation via the can_open_delegated() path in nfs4_try_open_cached(). The mask is derived from O_ACCMODE alone, so an open(O_RDONLY | O_TRUNC) against a file the caller cannot write requests only MAY_READ and passes the local check. The OPEN is then satisfied locally and the truncation is issued to the server as a SETATTR(size=0) over the delegation stateid, which the server accepts under standard write-delegation semantics. POSIX requires that this open fail with EACCES.

Include MAY_WRITE in the mask whenever O_TRUNC is set so the local check matches the access the server would have enforced.(CVE-2026-64298)

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

tracing: Prevent out-of-bounds read in glob matching

String event fields are not necessarily NUL-terminated, so the filter predicate functions (filter_pred_string(), filter_pred_strloc() and filter_pred_strrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it.

regex_match_glob() was the exception: it ignored the length and called glob_match(), which scans the string until it hits a NUL byte. Some string fields are not NUL-terminated. One example is the dynamic char array of the xfs_* namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in glob_match(), reached via regex_match_glob() and filter_match_preds() from the xfs_lookup tracepoint.

Add a length-bounded glob_match_len() and use it from regex_match_glob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so glob_match() keeps its behaviour.(CVE-2026-64299)

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

crypto: qat - validate RSA CRT component lengths

The generic RSA key parser (rsa_helper.c) bounds each CRT component (p, q, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt() allocates half-size DMA buffers (key_sz / 2) and right-aligns each component with:

memcpy(dst + half_key_sz - len, src, len)

When a CRT component is larger than half_key_sz the subtraction underflows and memcpy writes past the DMA buffer, causing memory corruption.

Add a len > half_key_sz check next to the existing !len check for each of the five CRT components so the driver falls back to the non-CRT path instead of writing out of bounds.(CVE-2026-64304)

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

crypto: qat - protect service table iterations with service_lock

The service_table list is protected by service_lock when entries are added or removed (in adf_service_add() and adf_service_remove()), but several functions iterate over the list without holding this lock.

A concurrent adf_service_register() or adf_service_unregister() call could modify the list during traversal, leading to list corruption or a use-after-free.

Fix this by holding service_lock across all list_for_each_entry() iterations of service_table in adf_dev_init(), adf_dev_start(), adf_dev_stop(), adf_dev_shutdown(), adf_dev_restarting_notify(), adf_dev_restarted_notify(), and adf_error_notifier().

The lock ordering is safe: callers of the static helpers (adf_dev_up() and adf_dev_down()) acquire state_lock before service_lock, and no event_hld callback or service_lock holder ever acquires state_lock in the reverse order.(CVE-2026-64305)

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

crypto: drbg - Fix returning success on failure in CTR_DRBG

drbg_ctr_generate() sometimes returns success when it fails, leaving the output buffer uninitialized. Fix it.(CVE-2026-64306)

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

crypto: pcrypt - restore callback for non-parallel fallback

pcrypt installs pcrypt_aead_done() on the child AEAD request before trying to submit it through padata. If padata_do_parallel() returns -EBUSY, pcrypt falls back to calling the child AEAD directly.

That fallback must not keep the padata completion callback. Otherwise an asynchronous completion runs pcrypt_aead_done() even though the request was never enrolled in padata.

Restore the original request callback and callback data before calling the child AEAD directly. This keeps the fallback path aligned with a direct AEAD request while leaving the parallel path unchanged.(CVE-2026-64312)

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

crypto: ecc - Fix carry overflow in vli multiplication

The carry flag calculation fails when r01.m_high is saturated (0xFFFFFFFFFFFFFFFF) and addition of lower bits overflows.

The condition (r01.m_high < product.m_high) doesn't handle the case where r01.m_high == product.m_high and an additional carry exists from lower-bit overflow.

When commit 3c4b23901a0c ("crypto: ecdh - Add ECDH software support") introduced crypto/ecc.c, it split the muladd() function in the micro-ecc library into separate mul_64_64() and add_128_128() helpers. It seems the check got lost in translation.

Add proper handling for this boundary by accounting for the carry from the lower addition.(CVE-2026-64313)

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

isofs: bound Rock Ridge symlink components to the SL record

get_symlink_chunk() and the SL handling in parse_rock_ridge_inode_internal() walk the variable-length components of a Rock Ridge "SL" (symbolic link) record. Each component is a two-byte header (flags, len) followed by len bytes of text, so it occupies slp->len + 2 bytes. Both loops read slp->len and advance to the next component, and get_symlink_chunk() additionally does memcpy(rpnt, slp->text, slp->len), but neither checks that the component lies within the SL record before dereferencing it.

A crafted SL record whose component declares a len that runs past the record (rr->len) therefore triggers an out-of-bounds read of up to 255 bytes. When the record sits at the tail of its backing buffer - for example a small kmalloc()ed continuation block reached through a CE record - the read crosses the allocation; get_symlink_chunk() then copies the out-of-bounds bytes into the symlink body returned to user space by readlink(), disclosing adjacent kernel memory.

ISO 9660 images are routinely mounted from untrusted removable media - desktop environments auto-mount them (e.g. via udisks2) without CAP_SYS_ADMIN - so the record contents are attacker-controlled.

Reject any component that does not fit in the remaining record bytes before using it. In get_symlink_chunk() return NULL, like the existing output-buffer (plimit) checks, so a malformed record makes readlink() fail with -EIO rather than silently returning a truncated target; in parse_rock_ridge_inode_internal() stop the inode-size walk.(CVE-2026-64317)

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

nvmet-auth: validate reply message payload bounds against transfer length

nvmet_auth_reply() accesses the variable-length rval[] array using attacker-controlled hl (hash length) and dhvlen (DH value length) fields without verifying they fit within the allocated buffer of tl bytes.

A malicious NVMe-oF initiator can craft a DHCHAP_REPLY message with a small transfer length but large hl/dhvlen values, causing out-of-bounds heap reads when the target processes the DH public key (rval + 2*hl) or performs the host response memcmp.

With DH authentication configured, the OOB pointer is passed directly to sg_init_one() and read by crypto_kpp_compute_shared_secret(), reaching up to 526 bytes past the buffer. This is exploitable pre-authentication.

Add bounds validation ensuring sizeof(data) + 2hl + dhvlen <= tl before any access to the variable-length fields.

Discovered by Atuin - Automated Vulnerability Discovery Engine.(CVE-2026-64319)

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

nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page

nvmet_execute_disc_get_log_page() validates only the dword alignment of the host-supplied Log Page Offset (lpo). The 64-bit offset is then added to a small kzalloc'd buffer that holds the discovery log page and the result is passed straight to nvmet_copy_to_sgl(), which memcpy()s data_len bytes out to the host with no source-side bound check:

u64 offset      = nvmet_get_log_page_offset(req-&gt;cmd);  /* 64-bit host */
size_t data_len = nvmet_get_log_page_len(req-&gt;cmd);     /* 32-bit host */
...
if (offset &amp; 0x3) { ... }                               /* only check */
...
alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req);
buffer = kzalloc(alloc_len, GFP_KERNEL);
...
status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len);

The Discovery controller is unauthenticated -- nvmet_host_allowed() returns true unconditionally for the discovery subsystem -- so the call is reachable pre-authentication by any TCP/RDMA/FC peer that can reach the nvmet target. With a discovery log page of ~1 KiB, an attacker requesting up to 4 KiB starting at offset == alloc_len reads the next slab page out and gets its content returned over the fabric (an empirical run on a default nvmet-tcp loopback target leaked 81 canonical kernel pointers in one Get Log Page response). Pointing the offset at unmapped kernel memory faults the in-kernel memcpy and crashes (or panics, on panic_on_oops=1) the target host instead.

The attacker-controlled source-side offset pattern "nvmet_copy_to_sgl(req, 0, buffer + ATTACKER_OFFSET, ...)" is unique to nvmet_execute_disc_get_log_page in the entire nvmet codebase: every other Get Log Page handler in admin-cmd.c either ignores lpo (and silently starts every response at offset 0) or tracks a local destination offset with a fixed source pointer.

Validate the host-supplied offset against the log page size, cap the copy length to what is actually available, and zero-fill any remainder of the host transfer buffer. The zero-fill matches the existing short-response pattern in nvmet_execute_get_log_changed_ns() (admin-cmd.c) and prevents leaking transport SGL contents when the host asks for more bytes than the log page contains.(CVE-2026-64320)

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

udf: validate sparing table length as an entry count, not a byte count

udf_load_sparable_map() accepts a sparing table when

sizeof(*st) + le16_to_cpu(st-&gt;reallocationTableLen) &gt; sb-&gt;s_blocksize

is false, i.e. it treats reallocationTableLen as a number of BYTES that must fit in the block. But the table is walked as an array of 8-byte sparingEntry elements:

for (i = 0; i &lt; le16_to_cpu(st-&gt;reallocationTableLen); i++) {
    struct sparingEntry *entry = &amp;st-&gt;mapEntry[i];
    ... entry-&gt;origLocation ...
}

in udf_get_pblock_spar15() and udf_relocate_blocks(). A reallocationTableLen of N therefore passes the check whenever sizeof(st) + N <= blocksize, yet the consumers index sizeof(st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the block. On a crafted UDF image this is an out-of-bounds read in udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the same length to udf_update_tag(), whose crc_itu_t() reads far past the block, and its memmove() through st->mapEntry[] is an out-of-bounds write.

Validate reallocationTableLen as the entry count it is, with struct_size().(CVE-2026-64322)

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

udf: validate VAT header length against the VAT inode size

udf_load_vat() takes the virtual partition's start offset straight from the on-disk VAT 2.0 header without checking it against the VAT inode size:

map-&gt;s_type_specific.s_virtual.s_start_offset =
    le16_to_cpu(vat20-&gt;lengthHeader);
map-&gt;s_type_specific.s_virtual.s_num_entries =
    (sbi-&gt;s_vat_inode-&gt;i_size -
        map-&gt;s_type_specific.s_virtual.s_start_offset) &gt;&gt; 2;

lengthHeader is a fully attacker-controlled 16-bit value. If it exceeds the VAT inode size, the s_num_entries subtraction underflows to a huge count, which defeats the "block > s_num_entries" bound in udf_get_pblock_virt15(); and on the ICB-inline path that function reads

((__le32 *)(iinfo-&gt;i_data + s_start_offset))[block]

so a large s_start_offset indexes past the inode's in-ICB data. Mounting a crafted UDF image with a virtual (VAT) partition then triggers an out-of-bounds read.

Reject a VAT whose header length does not leave room for at least one entry within the VAT inode.(CVE-2026-64323)

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

udf: validate free block extents against the partition length

udf_free_blocks() checks the logical block number and count against the partition length, but drops the extent offset from that final bound. A crafted extent can pass the guard while logicalBlockNum + offset + count points past the partition, which later indexes past the space bitmap array.

A single ftruncate(2) on a file backed by such an extent reliably panics the kernel. This is a local availability issue. On desktop systems where UDisks/polkit allows the active user to mount removable UDF media without CAP_SYS_ADMIN, an unprivileged local user can supply the crafted filesystem and trigger the panic by truncating a writable file on it. Systems that require root or CAP_SYS_ADMIN to mount the image have a higher prerequisite.

No confidentiality or integrity impact is claimed: the reproduced primitive is an out-of-bounds read of a bitmap pointer slot followed by a kernel panic.

Use the already computed logicalBlockNum + offset + count value for the partition length check. Also make load_block_bitmap() reject an out-of-range block group before indexing s_block_bitmap[], so corrupted callers cannot walk past the flexible array.(CVE-2026-64324)

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

bpf: Reject fragmented frames in devmap

Devmap broadcast redirects clone the packet for all but the last destination.

For native XDP, that clone path copies only the linear xdp_frame data, while fragmented frames keep skb_shared_info in tailroom outside the linear area. Cloning such a frame leaves XDP_FLAGS_HAS_FRAGS set but without valid frag metadata, and the later free path can interpret uninitialized tail data as skb_shared_info, leading to an out-of-bounds access during frame return.

Reject fragmented native XDP frames in dev_map_enqueue_clone().

Add the same restriction to the generic XDP clone path in dev_map_redirect_clone(). Generic XDP represents fragmented packets as nonlinear skbs, and rejecting them here keeps clone-based broadcast support aligned between native and generic XDP.(CVE-2026-64355)

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

HID: multitouch: fix out-of-bounds bit access on mt_io_flags

mt_io_flags is a single unsigned long, but mt_process_slot(), mt_release_pending_palms() and mt_release_contacts() use it as a per-slot bitmap indexed by the slot number. That slot number is only bounded by td->maxcontacts, which is taken from the device's ContactCountMaximum feature report and can be up to 255, not by BITS_PER_LONG.

As a result, a multitouch device that advertises a large contact count makes set_bit()/clear_bit() operate past the mt_io_flags word and corrupt the adjacent members of struct mt_device. The sticky-fingers release timer is the easiest way to reach this. mt_release_contacts() runs

for (i = 0; i &lt; mt-&gt;num_slots; i++)
    clear_bit(i, &amp;td-&gt;mt_io_flags);

with num_slots == maxcontacts. For maxcontacts around 250 the loop clears the bits that overlap td->applications.next, zeroing that list head, and the list_for_each_entry() that immediately follows then dereferences NULL. The kernel panics from timer (softirq) context. On a KASAN build this shows up as a general protection fault in mt_release_contacts() with a null-ptr-deref at offset 0x58, which is offsetof(struct mt_application, num_received).

The state is reachable from an untrusted USB or Bluetooth HID multitouch device; no local privileges are required.

Store the per-slot active state in a separately allocated bitmap sized for maxcontacts, the same pattern already used for pending_palm_slots, and keep only MT_IO_FLAGS_RUNNING in mt_io_flags. The two "mt_io_flags & MT_IO_SLOTS_MASK" arming checks become bitmap_empty(td->active_slots, td->maxcontacts).

Move MT_IO_FLAGS_RUNNING back to bit 0. It was bumped to bit 32 by the same commit to leave the low byte for the slot bits; with the slot bits gone it fits in bit 0 again, which also keeps it within the unsigned long on 32-bit.(CVE-2026-64364)

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

sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT

RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead.

Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task.

This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow.

The solution to that was to create an RT_PUSH_IPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue lock of the overloaded CPU, it would start by sending an IPI to the overloaded CPU, and that IPI handler would have the CPU with the waiting RT task do a push instead. Then that handler would send an IPI to the next CPU with overloaded RT tasks, and so on. Note, after the first CPU starts this process, if another CPU wanted to do a pull, it would see that the process has already begun and would only increment a counter to have the IPIs continue again.

The RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause a new issue with non PREEMPT_RT. Namely, softirqs run in a threaded context on PREEMPT_RT but they can run in an interrupt context in non-RT.

If an IPI lands on a CPU that has just woken up multiple RT tasks and the current CPU is running a non RT or a low priority RT task, instead of doing a push, it would simply do a schedule on that CPU. But if a softirq was also executing on this CPU, the schedule would need to wait until the softirq finished. Until then, the CPU would still be considered overloaded as there are RT tasks still waiting to run on it.

A live lock occurred on a workload that was doing heavy networking traffic on a large machine where the softirqs would run 500us out of 750us. And it would also be waking up RT tasks, causing the RT pull logic to be constantly executed.

When a softirq triggered on a CPU with RT tasks queued but not running yet, and the other CPUs would see this CPU as being overloaded, they would send an IPI over to it. The CPU would notice that the waiting RT tasks are of higher priority than the currently running task and simply schedule that CPU instead. But because the softirq was executing, before it could schedule, it would receive another IPI to do the same. The amount of IPIs would slow down the currently running softirq so much that before it could return back to task context, it would execute another softirq never allowing the CPU to schedule. This live locked that CPU.

As RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if PREEMPT_RT is not enabled.(CVE-2026-64374)

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

writeback: fix race between cgroup_writeback_umount() and inode_switch_wbs()

When a container exits, the following BUG_ON() is occasionally triggered:

================================================================== VFS: Busy inodes after unmount of sdb (ext4) ------------[ cut here ]------------ kernel BUG at fs/super.c:695! CPU: 3 PID: 6 Comm: containerd-shim Tainted: G OE K 6.6 #1 pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : generic_shutdown_super+0xf0/0x100 lr : generic_shutdown_super+0xf0/0x100 Call trace: generic_shutdown_super+0xf0/0x100 kill_block_super+0x20/0x48 ext4_kill_sb+0x28/0x60 deactivate_locked_super+0x54/0x130 deactivate_super+0x84/0xa0 cleanup_mnt+0xa4/0x140 __cleanup_mnt+0x18/0x28 task_work_run+0x78/0xe0 do_notify_resume+0x204/0x240 ==================================================================

The root cause is a race between cgroup_writeback_umount() and inode_switch_wbs()/cleanup_offline_cgwb(). There is a window between inode_prepare_wbs_switch() returning true and the subsequent wb_queue_isw() call. Following is the process that triggers the issue:

  CPU A (umount)           |          CPU B (writeback)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ inode_switch_wbs/cleanup_offline_cgwb atomic_inc(&isw_nr_in_flight) inode_prepare_wbs_switch -> passes SB_ACTIVE check __iget(inode) generic_shutdown_super sb->s_flags &= ~SB_ACTIVE cgroup_writeback_umount(sb) smp_mb() atomic_read(&isw_nr_in_flight) rcu_barrier() -> no pending RCU callbacks flush_workqueue(isw_wq) -> nothing queued, returns evict_inodes(sb) -> Inode skipped as isw still holds a ref. sop->put_super(sb) / destroys percpu counters / -> VFS: Busy inodes after unmount! wb_queue_isw() queue_work(isw_wq, ...) / later in work function / inode_switch_wbs_work_fn process_inode_switch_wbs iput() -> evict percpu_counter_dec() // UAF!

Fix this by extending the RCU read-side critical section in inode_switch_wbs() and cleanup_offline_cgwb() to cover from inode_prepare_wbs_switch() through wb_queue_isw(). Since there is no sleep in this window, rcu_read_lock() can be used. Then add a synchronize_rcu() in cgroup_writeback_umount() before the existing rcu_barrier(), so that all in-flight switchers that have passed the SB_ACTIVE check have completed queue_work() before flush_workqueue() is called.

The existing rcu_barrier() is intentionally retained so this fix can be backported unchanged to stable kernels (5.10.y, 6.6.y, ...) that still queue switches via queue_rcu_work(). It is a no-op on current mainline (since commit e1b849cfa6b6 ("writeback: Avoid contention on wb->list_lock when switching inodes")) and is removed in a follow-up patch.(CVE-2026-64378)

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

smb: client: mask server-provided mode to 07777 in modefromsid

When modefromsid is active, parse_dacl() applies the server-provided sub_auth[2] value from the NFS mode SID to cf_mode without masking to 07777. Apply the correct masking, same as in the read path.(CVE-2026-64379)

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

smb: client: harden POSIX SID length parsing

posix_info_sid_size() reads sid[1] to obtain the subauthority count, but its existing boundary check still accepts buffers with only one remaining byte. Require two bytes before reading sid[1] so all client paths that reuse the helper reject truncated POSIX SIDs safely.(CVE-2026-64380)

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

smb: client: fix double-free in SMB2_open() replay

A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_open_init() fails before the next send, cleanup retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64382)

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

smb: client: fix double-free in SMB2_flush() replay

SMB2_flush() keeps its response buffer bookkeeping across replay attempts. If a replayable flush response is received and the retry then fails before cifs_send_recv() stores a replacement response, flush_exit will free the stale response pointer a second time.

Reinitialize resp_buftype and rsp_iov at the top of the replay loop so cleanup only acts on response state produced by the current attempt. This fixes a double-free without changing replay handling for successful requests.(CVE-2026-64383)

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

smb: client: fix change notify replay double-free

A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_notify_init() fails before the next send, cleanup retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64384)

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

smb: client: fix double-free in SMB2_ioctl() replay

A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_ioctl_init() fails before the next send, cleanup retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64385)

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

smb: client: fix query_info() replay double-free

A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_query_info_init() fails before the next send, cleanup retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64386)

In the Linux kernel, an out-of-bounds read vulnerability exists in the SMB client. smb2_check_message() has a long-standing quirk that accepts a response whose calculated length is one byte larger than the bytes actually received ("server can return one byte more due to implied bcc[0]"). This was introduced to accommodate servers that omit the trailing bcc[0] overlap byte when no data area is present. However, the exemption is applied unconditionally, regardless of whether the command actually carries a data area (has_smb2_data_area[]). When a response with a data area is subject to the +1 exemption, the reported data can extend one byte beyond the bytes actually received, causing the subsequent decoder to read past the end of the receive buffer. This is reachable during NEGOTIATE and SESSION_SETUP, before the session is established. The resulting out-of-bounds reads are visible under KASAN when mounting against a non-conforming server, affecting both the SPNEGO/negTokenInit and the NTLMSSP challenge decoders.(CVE-2026-64448)

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

hwrng: virtio: clamp device-reported used.len at copy_data()

random_recv_done() stores the device-reported used.len directly into vi->data_avail. copy_data() then indexes vi->data[] using vi->data_idx (advanced by previous copy_data() calls) and issues a memcpy() without re-validating either value against the posted buffer size sizeof(vi->data) (SMP_CACHE_BYTES bytes, typically 32 or 64).

A malicious or buggy virtio-rng backend can set used.len beyond sizeof(vi->data), steering the memcpy() past the end of the inline array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes those bytes into the guest RNG, and guest root can also observe them directly via /dev/hwrng.

Concrete impact is inside the guest:

Memory-safety / hardening: any virtio-rng backend that over-reports used.len causes the driver to read past vi->data into unrelated slab contents. hwrng_fillfn() is a kernel thread that runs as soon as the device is probed; no guest userspace interaction is required to first-trigger the OOB.
Cross-boundary leak (confidential-compute threat model): a malicious hypervisor cooperating with a malicious or compromised guest root userspace can use /dev/hwrng as a leak channel for guest-kernel heap data. The host sets a large used.len, guest root reads /dev/hwrng, and the returned bytes contain guest kernel slab contents that were adjacent to vi->data. In practice, confidential-compute guests (SEV-SNP, TDX) usually disable virtio-rng entirely, so this path is narrow, but the fix is still worth carrying because the underlying memory-safety bug contaminates the guest RNG on any host.

KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend has been patched to report used.len = 0x10000:

BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0 Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52 Call Trace: __asan_memcpy+0x23/0x60 virtio_read+0x394/0x5d0 hwrng_fillfn+0xb2/0x470 kthread+0x2cc/0x3a0 Allocated by task 1: probe_common+0xa5/0x660 virtio_dev_probe+0x549/0xbc0 The buggy address belongs to the object at ffff88800ae0b800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes to the right of allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20)

Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), which hardened usb9pfs_rx_complete() against unchecked device-reported length in the USB 9p transport.

With the clamp at point of use and array_index_nospec() in place, the same harness boots cleanly: copy_data() returns zero for the bogus report, the device-supplied bytes after data_idx are discarded, and the driver issues a fresh request.(CVE-2026-64456)

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

ALSA: hda/cs35l41: Fix firmware load work teardown

cs35l41_hda creates ALSA controls whose private data points at the cs35l41_hda object. The firmware load control can also queue fw_load_work.

Those controls are not removed on component unbind, and device remove only cancels fw_load_work through cs35l41_remove_dsp(). That helper is skipped when halo_initialized is false. With firmware_autostart disabled, a firmware load can be requested before the DSP has been initialized. If the component or device is removed before the queued work runs, the worker can run after teardown and dereference driver state that is no longer valid.

Track the created controls and remove them on unbind so no new control callback can reach the driver data or queue more work. Then cancel fw_load_work to drain any request that was already queued. Also cancel the work unconditionally during device remove before runtime PM teardown.(CVE-2026-64481)

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

iio: event: Fix event FIFO reset race

iio_event_getfd() creates the event file descriptor with anon_inode_getfd(), which allocates a new fd, creates the anonymous file and installs it in the process fd table before returning to the caller.

The IIO code resets the event FIFO after anon_inode_getfd() has returned, but before IIO_GET_EVENT_FD_IOCTL has copied the fd number to userspace. But since fd tables are shared between threads, another thread can guess the newly allocated fd number and issue a read() on it as soon as the fd has been installed.

This means the kfifo_to_user() in iio_event_chrdev_read() can run in parallel with the kfifo_reset_out() in iio_event_getfd().

The kfifo documentation says that kfifo_reset_out() is only safe when it is called from the reader thread and there is only one concurrent reader. Otherwise it is dangerous and must be handled in the same way as kfifo_reset().

If that happens, kfifo_to_user() can advance the FIFO out index based on state from before the reset, after the reset has already moved the out index to the current in index. That can leave the FIFO with an out index past the in index. A later read() can then see an underflowed FIFO length and copy more data than the event FIFO buffer contains. This can result in an out-of-bounds read and leak adjacent kernel memory to userspace.

Move the FIFO reset before anon_inode_getfd(). At that point the event fd is marked busy, but the new fd has not been installed yet, so userspace cannot access it while the FIFO is reset.(CVE-2026-64496)

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

net: openvswitch: reject oversized nested action attrs

Open vSwitch stores generated flow actions as nlattrs, whose nla_len field is u16. Commit a1e64addf3ff ("net: openvswitch: remove misbehaving actions length check") allowed the total sw_flow_actions stream to grow beyond 64 KiB, which is valid, but also removed the last guard preventing a generated nested action attribute from exceeding U16_MAX.

An oversized generated container can thus be closed with a truncated nla_len. A later dump or teardown then walks a structurally different stream than the one that was validated. In particular, an oversized nested CLONE/CT action may cause subsequent bytes in the generated stream to be interpreted as independent actions.

Keep the larger total-action-stream behavior, but make nested action close reject generated containers that do not fit in nla_len, and return the error through all callers. For recursive SAMPLE, CLONE, DEC_TTL, and CHECK_PKT_LEN builders, trim resource-owning action-list tails in reverse construction order before discarding failed wrappers, so resources copied into the rejected tails are released before the wrappers are removed.

Most failed outer wrappers are discarded by truncating actions_len after child resources have been released. CHECK_PKT_LEN also trims its parent after branch resources are gone. SET/TUNNEL close failures unwind their known tun_dst ownership directly, and SET_TO_MASKED has no external ownership and truncates on close failure.(CVE-2026-64531)

In the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Detach event groups during remove_on_exec\n\nperf_event_remove_on_exec() removes events by calling\nperf_event_exit_event(). For top-level events, this removes the event from\nthe context with DETACH_EXIT only.\n\nThis can leave inconsistent group state when a removed event is a group\nleader and the group contains siblings without remove_on_exec. If the group\nwas active, the surviving siblings can remain active and attached to the\nremoved leader's sibling list, but are no longer represented by a valid\ngroup leader on the PMU context active lists.\n\nA later close of the removed leader uses DETACH_GROUP and can promote the\nstill-active siblings from this stale group state. The next schedule-in can\nthen add an already-linked active_list entry again, corrupting the PMU\ncontext active list.\n\nWith DEBUG_LIST enabled, this is caught as a list_add double-add in\nmerge_sched_in().\n\nFix this by detaching group relationships when remove_on_exec removes an\nevent. This preserves the existing task-exit and revoke behavior, while\nensuring surviving siblings are ungrouped before the removed event leaves\nthe context.(CVE-2026-64556)

In the Linux kernel, a use-after-free (UAF) vulnerability exists caused by a non-leader exec() race condition in posix-cpu-timers. When sys_timer_delete() observes the old leader, while de_thread() executes switch_leader() and releases the old leader, a race condition occurs. Specifically, posix_cpu_timer_del() in sys_timer_delete() obtains the old leader via pid_task(), while de_thread() is executing release_task(old_leader) and setting old_leader->sighand = NULL. When lock_task_sighand() returns NULL, sys_timer_delete() frees the posix timer object. However, if the timer was armed and enqueued in p->signal (a TGID targeted timer is inherited on exec()), run_posix_cpu_timers() or other timerqueue add/delete operations will access the freed object's timerqueue node, resulting in a use-after-free. This issue similarly affects posix_cpu_timer_set() and posix_cpu_timer_rearm(). The history of this vulnerability goes back to the early days of posix CPU timers implementation.(CVE-2026-64560)

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Check for invalid/obsolete root after making MMU pages available\n\nCheck for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages.\n\nNote, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages.\n\nNote #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.(CVE-2026-64561)

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

smb: client: fix double-free in SMB2_close() replay

A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_close_init() fails before the next send, cleanup retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64597)